Login at Kodi Home

SteveG787 · 2016-09-08, 21:36

I have a library of flac files that I am trying to import and use in Kodi and have hit a bit of a snag. If somebody would be kind enough to point me in the right direction I would be grateful.

My library is about 750 albums so manual editing is not possible. All of the files have Genres, nearly all have Styles, and about half have Moods, these are all in flac tags with individual entries for multiple Genres etc. Most of this was read from AllMusic years ago when they were less restrictive and I am happy about the values. When I read this into Kodi, with the online information switched off, the Genres get read but no Styles or Moods. I looked in the database and the strStyles and the strMoods fields are null.

I have searched the Wiki and Forum and have come up with the information that these fields are only read from online sources or .nfo files and not direct from the files. Is this correct ? If so does anybody know an automatic way of extracting the information from the flac files into .nfo files ?

Thanks.

**DaveBlake** · 2016-09-09, 09:55

Kodi (V16 onwards) reads the GENRE and MOOD tags from FLAC files. It does not process "style" in any tag format (note it is not part of the ID3 standard). Earlier versions of Kodi didn't cover mood in FLAC, you don't say what version you use. These get stored as the genre and mood of the song in the database.

Albums can also have separate genre, mood and style values. The treatment of genre is confusing but I will try to explain. Initially the album genre is taken from the genre of the first song of that album, this has genre table entries and is applied (along with the other song genres) when navigating down to albums from the genre node. But just the string (as shown on album info dialog) can be set using an NFO file. This will show on the dialog, but has not impact on navigation or filtering results.

Album mood and style can only be loaded using NFO files (I guess that could also be scrapped from online sources, but I don't know if any of the audio databases we scarpe provide that)

Now it could make sense for Kodi in the future to populate album mood from the song mood tag, as it does for genre. The other approach would be providing the means to select those albums with songs with a certain mood. Style is just an album thing, needs to come from NFO.

Quote: If so does anybody know an automatic way of extracting the information from the flac files into .nfo files ?

There may be people that could write some Python to do this, not my field I'm afraid..

SteveG787 · 2016-09-09, 16:39

Thanks for the reply. I'm using v16.1 under Windows for now with a NAS box for media and database and intending to roll out to Android boxes on TV's about the house. From your reply and further examination of the database structure it appears that the way Kodi handles Genres, Styles and Moods does not fit with my usage and thoughts on the matter which basically originate from AllMusic and are somewhat echoed by Discogs and AudioDB.

I use Genre as a broad category (Rock, Pop, Folk etc), I use Style as a sub-genre (so, Heavy Metal, Punk etc under Rock), Mood would be Happy, Sad, etc as applies, independant of Genre or Style. These should all be per Song rather than per Album as an album could contain many different Genres, Styles and Moods (in particular Compilations). The Album tags would be multiple entries where required, so an album would have genre entries for Pop and Rock if songs on the album had either. Similarly the Artist entry would be accumulations of the Album entries for that Artist.

This all becomes very useful thanks to the advent of Smart Playlists so that one can devise a playlist using all three fields to suit the mood of the moment. This is my intention.

From your mention of ID3 tags I assume that historically Kodi worked with MP3 files and has been expanded to other formats over the years. I don't know anything much about MP3 other than what it sounds like, I've use FLAC files since I started ripping LP's and CD's (at least 12 years) but it seems to me that a larger set of tags should be allowed than are available in ID3 where they are useful. I realise that is easy for me to say who isn't doing the work but it wouldn't be too much of a stretch to add and would not affect the MP3 usage at all.

What I can and will do is look for a 3rd party tag extractor to .nfo and report back here as to how it all works for future reference of interested parties.

**DaveBlake** · 2016-09-09, 18:11

I only have FLAC files in my music collection too, I am more interested in "high fidelity" than portable devices. Smile

Vorbis/Xiph tagging does not have a standard per se, and ID3 v2.4 allows for TXXX custom tags so yes you could add any named of tag you wanted to the files. I have not analysed the history, but I would expect that Kodi started with using the most common tags in any format, nothing to do with being limited to mp3 or the ID3 standard. BTW the ID3 v2.4 standard of tags is quite a long list, just doesn't include "style".

Kodi could be changed to process extra tags - I've done a fair bit of that. Adding those most likely to already be in people's music files, with a common use, makes the most sense. Another approach would be to store any and every tag found (standard and custom), but that generic approach would need a major redesign throughout the library and UI. Storing TXXX/custom tags data in the music library wouldn't be too hard at all, but making them usable by the user for searching and playlist filters etc. is non-trivial starting from where we currently are.

Genre and mood are per song, and you can use them in smart playlist rules. It is "song style" or sub-genre that Kodi does not have. Persoanlly I have just used multiple values in GENRE tag for a all personal categorisation of my music, and that is all I can suggest at the moment as a way to get what you want.

SteveG787 · 2016-09-11, 17:37

Dave, I am in the middle of exporting tags to .nfo files using MP3Tag which I have sort of got working but then I noticed something strange with compilation albums, which ties in to another thread you started so I thought I'd bring it up.

Whether the <compilation> element for the album is true or false or 1 or 0 or anything else I can think of it gets set to false in the database when importing a .nfo. Is this deliberate and something to do with the tests mentioned on the other thread ? Surely the information in the .nfo should be taken at value and not subject to tests ? I am testing with an Eagles Greatest Hits album so there is only one artist.

I looked at the SQL in the log and it's false at that point so it's something to do with the reading of the .nfo file. If I set the flag directly in the database and export the .nfo it shows compilation as true so it works ok in that direction.

Also it appears that the only nfo files exported are for where the album info has been refreshed and not where it has been read directly from the tags. This was actually useful as I'm testing and only wanted a couple of albums worth but seems a wierd way to do it, can this be switched by an option of some sort ?

**DaveBlake** · (This post was last modified: 2016-09-11, 20:36 by DaveBlake.)

Going to take your last point first.

(2016-09-11, 17:37)SteveG787 Wrote: Also it appears that the only nfo files exported are for where the album info has been refreshed and not where it has been read directly from the tags. This was actually useful as I'm testing and only wanted a couple of albums worth but seems a wierd way to do it, can this be switched by an option of some sort ?

Ah yes it is weird and something I hope to change. Export only exports those artists and albums that you have previously scraped extra information for, despite the fact that some of the exported data for albums is derrived from music file tags. It means that you can never just export everything and use the files as NFO templates for editing. Basically export ignores anything with a null lastscraped date. For now one way around this without scraping is to set the lastscraped field to something in the database directly (does not have to be a date).

Quote:Dave, I am in the middle of exporting tags to .nfo files using MP3Tag which I have sort of got working but then I noticed something strange with compilation albums, which ties in to another thread you started so I thought I'd bring it up.

Whether the <compilation> element for the album is true or false or 1 or 0 or anything else I can think of it gets set to false in the database when importing a .nfo. Is this deliberate and something to do with the tests mentioned on the other thread ? Surely the information in the .nfo should be taken at value and not subject to tests ? I am testing with an Eagles Greatest Hits album so there is only one artist.

I looked at the SQL in the log and it's false at that point so it's something to do with the reading of the .nfo file. If I set the flag directly in the database and export the .nfo it shows compilation as true so it works ok in that direction.

Because the album compilation flag is one of those things initially derrived from music file tags, the database only gets populated with the value in the NFO on import when the "Prefer online information" setting is enabled. I have not tested recently but I am pretty sure that is your issue.

SteveG787 · 2016-09-11, 21:49

Ok I've done a few more tests and this doesn't work at all the way I thought it did.

If I remove the album.nfo, set the prefer online info option then refresh the album info I get the info from MusicBrainz apart from the bCompilation field is still not setting correctly despite MusicBrainz returning the release-group type as "Compilation".

However..

If I reinstate the album.nfo, leave prefer online info on then refresh the album info I get the correct true setting for bCompilation. But the wierd bit is other values are also taken from the nfo rather than online. When album.nfo wasn't there the Label was set as "Asylum Records" (from MusicBrainz) but when it was there the field was empty as in the nfo. So by setting "Prefer online information" I actually get the nfo information preferred !

I need to test this a lot more but it appears to do what I need to get the tag info into the database via an nfo file but right now my head hurts so I'm going to watch the telly.

On a related note and referencing the other compilation thread is there any reason I can't use the type field to indicate a compilation, or indeed an anthology, and hence use that in a Smart Playlist.

**DaveBlake** · (This post was last modified: 2016-09-12, 10:13 by DaveBlake.)

Sorry your head hurts Smile

Yes it is yet another settings misname. "Prefer Online Information" actually means "override album data derrived from music file tags with that scraped from NFO files or online sources". Note I didn't design that, I am just reporting my observations.

If NFO exist then they take precedence to scraping online. If you don't want to use NFO when you scrape (I know that you do, but maybe change your mind) then you have to delete or rename the NFO or Kodi will find it and use it.But scraping is also optional, you can disable "fetch additional information on update" and never click "query info for all".

Thanks I'll checkout release group type tag processing, but as I said on the other thread I know there are inconsistencies.

Quote:On a related note and referencing the other compilation thread is there any reason I can't use the type field to indicate a compilation, or indeed an anthology, and hence use that in a Smart Playlist.

Yes you could! Smile

I had not thought of that, in fact I had never noticed the type field or what goes in it. As I am a tags guy, not NFO because they are such a faff to make and manage, and since this is only provided by scraping I have generally ignored it - my bad.

Going to mention that on the other thraed, what a great idea.

SteveG787 · 2016-09-12, 10:36

I've cobbled together an MP3Tag script that creates the NFO files so that end of it works ok. This means the nfo is (fairly) quick to make and any management is done in the flac tags or in the script. This also means I can put whatever I like in the fields of the NFO file based on string comparisons of any of the flac tags (or whatever). I am keen to keep all the information relating to the music inside the flac files and have anything required by the program generated from that information rather than scraped online into the programs database. This keeps me independant of any particular program, not reliant on online database accuracy, which is variable, and mostly just seems the right way to do it.

I've just tested it using "Anthology" in the nfo type field and a Smart Playlist with "Type contains anthology" as the rule and it works fine. My initial thought is to still set the compilation field if the flac file is set thus, and to use the type field to signal "Various Artists", "Anthology" and whatever else occurs to me later as a means to select with in a Smart Playlist.

I'll post the MP3Tag script when I get it fit to be seen in public.

SteveG787 · 2016-09-12, 13:02

Ok for anybody interested here is my script to generate a kodi nfo file with MP3Tag. Credit to gagnedj for the basis http://forum.kodi.tv/showthread.php?tid=197283

It still needs some work, it's skewed to my requirements and I need to do an Artists one as well but it works ok so here you go. It should be modifiable easily enough to suit your own usage.

I have added another RELEASETYPE field to the existing Album and Compilation ones on a couple of test albums and set them to Anthology and Various. These all get imported into the Kodi database album.strType field as "Album, Compilation, Anthology" for example. Adding a Smart Playlist with simple Contains rules can then distinguish between various compilation types.

I have only run this script with "one file per directory" checked and on three test albums so use with care. It will overwrite any pre-existing album.nfo files so save these first if you're bothered.

Code:
$filename(%_folderpath%album.nfo,utf-8)

$loop(%album%)

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<album>

    <title>%ALBUM%</title>

    <artist>%ALBUMARTIST%</artist>

    <genre>$meta_sep(GENRE,/)</genre>

    <style>$meta_sep(STYLE,/)</style>

    <mood>$meta_sep(MOOD,/)</mood>

    <theme></theme>

    <musicBrainzAlbumID>%MUSICBRAINZ_ALBUMID%</musicBrainzAlbumID>

    <compilation>$if($grtr($strstr($meta(RELEASETYPE),Compilation),0),true,false)</compilation>

    <review>%COMMENT%</review>

    <type>$meta(RELEASETYPE)</type>

    <releasedate>%ORIGINALDATE%</releasedate>

    <label>%LABEL%</label>

    <thumb>smb:%_folderpath%folder.jpg</thumb>

    <path>smb:%_folderpath%</path>

    <rating></rating>

    <year>%ORIGINALYEAR%</year>

    <albumArtistCredits>

        <artist>%ALBUMARTIST%</artist>

        <musicBrainzArtistID>%MUSICBRAINZ_ALBUMARTISTID%</musicBrainzArtistID>

        <joinphrase></joinphrase>

        <featuring>%ARTIST%</featuring>

    </albumArtistCredits>

$loop(%track%)

    <track>

        <musicBrainzTrackID>%MUSICBRAINZ_TRACKID%</musicBrainzTrackID>

        <title>%TITLE%</title>

        <position>%TRACK%</position>

        <duration>%_length%</duration>

    </track>

$loopend()

</album>

$loopend()

**DaveBlake** · (This post was last modified: 2016-10-04, 19:36 by DaveBlake.)

Thanks for sharing Steve.

I would add a couple of notes for future reference for others.

1) This is using the mbid tag names in FLAC files. It is crazy but they are slightly different in each tag format
e.g. "TXXX MUSICBRAINZ ARTIST ID" in id3, "MUSICBRAINZ_ARTISTID" in FLAC and APE, "MusicBrainz/Artist Id" in ASF

2) Steve has added a custom tag called RELEASETYPE to his music files. Kodi (< v17) does not process this tag when it scans songs into the library. However in the library the album table does have a strReleaseType field that gets populated by either "album" or "single" depending on if the songs without an album title have been scanned. Do not confuse these different items!

The Mp3tag script takes this custom tag and translates it into a <type> element in an NFO file. When the NFO is scraped the type value is written to the album table strType field. This is the field that is queried by the type rule in album smart playlists. It has no specific use elsewhere in Kodi, so really can be used in whatever way the user wants to categorize albums.

**zag** · (This post was last modified: 2016-09-14, 23:33 by zag.)

i am also FLAC all the way, don't forget you can use the scrapers to download mood and style info Wink

Thats how I do it.

If you update those fields on TADB, it benefits everyone in the future.

Example album with info filled in: http://www.theaudiodb.com/album/2263200

**DaveBlake** · (This post was last modified: 2016-10-04, 19:38 by DaveBlake.)

It is worth noting that v17 now scans what in Picard this is called "release type" tag that appears in the various formats respectively as TXXX:MusicBrainz Album Type (Id3 v2.4), RELEASETYPE (Vorbis/Xiphe/FLAC), MUSICBRAINZ_ALBUMTYPE (APE), MusicBrainz/Album (ASF) Type, ----:com.apple.iTunes:MusicBrainz Album Type (mp4/iTunes)

The data is stored as the album type, although the contents can be later overwritten by values in NFO files etc.