[randallspicher]

In v19, we now have ListItem.SampleRate,  ListItem.MusicChannels, and ListItem.BitRate available for our skinning needs.  Thank You!

I'd like to request that the song Codec, and BitsPerSample also be stored in the database and made available for skins.
eg, so we can display things like  "24bit 96khz DTS-HD" in the list view.

Currently, those are only available while playing the song.  It would be nice to be able to present the same data from a list view without needing to actually play the song first.  

MusicPlayer.BitsPerSample
MusicPlayer.Codec

I'd like to note that samplerate, channels, and bitrate currently appear to only be available for flac and mp3.  I've got a lot of bluray, dvda, an sacd rips which are either in mka, dts wav, or dsf.  None of which are returning any channel, samplerate, or bitrate info in the list view  (not sure if that's because the codecs are DSD, DTS, or Atmos, or if it's because the file container being used)  Those all show the data from MusicPlayer when played, just not when scanned in.

I assume since this request is for a DB change, it would have to wait until v20.   The missing info for non flac/mp3 formats wold be nice to see fixed in a v19 update though.

It would also be nice if there were a clean way to flag the source format/version of an album in some way.  (for example an album was ripped from BDA, or from SACD, or from a Quad Reel (quadraphonic reel-to-real) to help identify it.  (for example when you have multiple copies of Dark Side Of The Moon), and have it show up under the Album info (so you can display it when listing the albums)  "Album_Type" seems to be used for other purposes (special edition, etc)

For that matter, it would be nice to display Channels, and Bitrate at the album level as well.  (even if it was by pulling the info from the first track in the album directory, and assuming all files in the directory are the same).

[HomerJau]

I did a Aeon Nox Silvo skin mod that does some of what you are asking for. It reads the album folder name and other info to workout the original codec. I convert most everything to FLAC but wanted to know the original source (BDA, SACD, DVDA, DTS-CD etc) while a song was playing.

You can get codec info into Kodi views by tagging the Album Name to include codec info but you should also add MusicBrainz IDs to tags to limit scraping hits to MusicBrainz server. 

DVD Audio converted to FLAC:


DTS-CD converted to FLAC:



Check out this post and read the thread to see more:
https://www.quadraphonicquad.com/forums/...ost-442130

I recently reorganised my music sources to get Kodi menu navigation into grouping by:
Surround (5.1)
Quad
Upmixes
Atmos
Stereo

That works pretty well. For albums with multiple codec releases (Dark Side of the Moon: BDA 5.1, BDA Quad, Original Quad) I used Kodi music’s new ‘Disc’ support to group tracks by disc. That’s nice too.

[black_eagle]

Those all show the data from MusicPlayer when played, just not when scanned in.

That's because Kodi uses the taglib library to read the tags and some associated audio data (sample rate, bitrate etc).  If taglib doesn't return those values when scanning your files then they aren't saved into the db.  See https://taglib.org/api/classTagLib_1_1Au...0c6bc57f4e

If you dig further you will find that bits per sample is available for FLAC and Wavpack, but not for MP3 or Vorbis.  It was therefore decided to only implement reading of audio properties at scan time that are available for all filetypes.

When you see that data in the music player, the information comes directly from the decoded stream not the db.

[randallspicher]

You can get codec info into Kodi views by tagging the Album Name to include codec info but you should also add MusicBrainz IDs to tags to limit scraping hits to MusicBrainz server. 

I actually did the same thing for my music library.   Setting the album names to things like "Dark Side Of The Moon (Quad Q4)" or the like.  (and updates to my skin to parse out and display that info with the relevant icons).   Changing the album name is just a clunky way to do it though, and one more thing to remember whenever I open things up with picard.  Would be easier if I could just run a shell script to blindly set some tag on all of them based on the directory.

[randallspicher]

Those all show the data from MusicPlayer when played, just not when scanned in.

That's because Kodi uses the taglib library to read the tags and some associated audio data (sample rate, bitrate etc).  If taglib doesn't return those values when scanning your files then they aren't saved into the db.  See https://taglib.org/api/classTagLib_1_1Au...0c6bc57f4e

If you dig further you will find that bits per sample is available for FLAC and Wavpack, but not for MP3 or Vorbis.  It was therefore decided to only implement reading of audio properties at scan time that are available for all filetypes.

When you see that data in the music player, the information comes directly from the decoded stream not the db.

Well, perhaps someone could write a plugin that uses libmediainfo instead of taglib to gather data, but that can't happen unless the DB supports it.
Seems odd that the decision would be to not implement bits-per-sample because taglib doesn't provide it for all file types, when neither bitrate nor channels are available for all filetypes, yet those were still implemented for Flac and MP3.  (neither dsf, mka, nor dts wav are showing it)  I would have gone with the "Better then nothing" option... in the hopes that taglib (or some other library) would later be updated to provide it for the others.

What library does the video parser use to gather things like codec data?  That has no problem seeing all the info.

[black_eagle]

What library does the video parser use to gather things like codec data?  That has no problem seeing all the info.

Video is completely different and totally unrelated to music.

According to the taglib documentation here the only items that should be returned for any audio format are

• length
  
• length in seconds
  
• length in milliseconds
  
• bitrate
  
• samplerate
  
• channels
  

If you don't get that info for some file formats then it's either a bug with Kodi, or a bug with taglib. Those fields however are the only ones that are meant to be generic across all file types. Other fields are available for some file types however the current core code only reads the generic ones as by the time we reach that code, all the other (codec specific) tag handling stuff has been done.

Sure we could add some specific handling related to codec type but I'm not convinced that (apart from showing a fancy flag) it would actually add much value. I think there may be other ways that already exist such as differing sources, smart playlists with rules for "filename contains" or "filename endswith" etc that can be used to divide up your content.

With that said I'm happy to look at it for v20 and onwards if  you can convince me there is a really good reason to add it (bearing in mind that if you do we will both have to convince @DaveBlake as well!)

[DaveBlake]

Sure we could add some specific handling related to codec type but I'm not convinced that (apart from showing a fancy flag) it would actually add much value. I think there may be other ways that already exist such as differing sources, smart playlists with rules for "filename contains" or "filename endswith" etc that can be used to divide up your content.

With that said I'm happy to look at it for v20 and onwards if  you can convince me there is a really good reason to add it (bearing in mind that if you do we will both have to convince DaveBlake as well!)

In many ways I am netural about this this idea if others want to do all the work. From a data and database point of view there is no problem with more fields, but because of basic historic design of Kodi there is a cost elsewhere and that needs to be considered against user benefits.

If Kodi GUI was based on lazy just-in-time reading of only the data it was displaying more specialist data fields would be fine, but it isn't. The songs nodes fetch all the data for all the songs from the db into local memory, and that write to local memory is why users with larger music collections will see lots of whirling "busy" cursor. Every time we add a field it gets a bit slower.

Then there is also the need for forced rescan of all files on version upgrade to fetch the data from files. It isn't easy to make that optional i.e. just those users that what to use the new facility, without running into user confusion over why something isn't working later on. Sure we have done this enough times, adding features only some users will ever use, but need to be mindful of it.

Users are very diverse in their needs, e.g. I care about composers, someone else its BPM another wants to see codec etc. the list is endless. That's great and I am happy to try to make Kodi as versatile as possible, but I believe that is best done by making Kodi as customisable as possible, and adding generic features rather than specific data fields because no matter what you add there will always be something missing that someone wants. Of course that is harder than just add a field and making song table wider and wider.
 
It was one reason why I added the music source filtering facility. That gives users the ultimate flexibility on how their music gets split up, based only any criteria they like, and no need to tag the files in any special way simply arrange them in folders. As mentioned there is also using smart playlist filtering based on filename or path.

I guess I would prefer that work went into making more generic features and performance improvement to fundamental design than flirt at the edges adding yet another field. But I'm only boss of me