[Cybermutant]

As this is my first post in the Music Support forum, I should first of all thank DaveBlake and all the other contributors for developing Kodi's Music section into what it is today.

I have been a user since v16, and with the latest Beta 2 release of Kodi v19 I decided to take the plunge and upgrade from v18.9. While doing that, I also thought this is a good time to re-check and update my music library tagging for consistency and in order to make use of the newly added features in v19. My library consists of FLAC files with standard Vorbis tags and MP3 files with only APEv2 tags. I don't use/need any ID3v1 or ID3v2 tags for my MP3 files. I'm using Mp3tag (v3.04a) for all MusicBrainz ID queries and tagging.

Adding FLAC files to the Kodi library works very well but I had a few minor issues when scanning my MP3 albums:

• I have to set the <prioritiseapetags> option in advancedsettings.xml  to be able to scan my MP3 files into the library although they don't have any other tags except APEv2. Looking through the relevant Kodi sources on GtHub I found this piece of code in TagLoaderTagLib.cpp
  

  cpp:
  if (ape && (!id3v2 || CServiceBroker::GetSettingsComponent()->GetAdvancedSettings()->m_prioritiseAPEv2tags)) // ape tags override id3v2 if we're prioritising them
  
    ParseTag(ape, art, tag);

  which I read as "Parse APEv2 tags if the file does not also have ID3v2 tags, regardless of the <prioritiseapetags> setting". Is that not so? Kodi debug log shows a message like
  Code:

  DEBUG <general>: MUSIC_INFO::CMusicInfoScanner::ScanTags - No tag found for: smb://servername/...filepath.../filename.mp3
  for each MP3 file in my library.
  
  
• I am updating all my music with full ISO "Release Date" and "Original Release Date" tags (where applicable, and possible). Since I'm saving full dates I'd prefer to use the DATE variants of these tags instead of the YEAR ones. When I checked the Wiki entry on music tags read by Kodi I was glad to see that Kodi supports both DATE and YEAR in Vorbis and APEv2 tags, so I started using DATE in all my FLAC and MP3 files. However, when I scanned these into the library I realized that Kodi in fact does not recognize DATE (and ORIGINALDATE) while parsing APEv2 tags. All my MP3 albums showed up in Kodi Music "Artists" view without any release date and were all sorted to the top of the album list for each artist.
  Again in TagLoaderTagLib.cpp I saw that, in the case of Vorbis tags, you are checking for both DATE and YEAR variants of these tags:
  

  cpp:
  else if (it->first == "YEAR" || it->first == "DATE")
  
  ...
  
  else if (it->first == "ORIGINALYEAR" || it->first == "ORIGINALDATE")

  Would you consider adding the same dual support for APEv2 tags as well?
  
  
• This one is more of a cosmetic issue that affects both MP3 and FLAC files:
  I have quite a few songs whose artist tag has the form "Artist Name ft. Vocalist Name", sometimes with more that one vocalist even. I have tagged all these files using multiple "Artist MBID" fields in Vorbis and APEv2 tags, one for each artist or vocalist and in the correct order. While going through Kodi's debug log I saw messages like
  
  Code:

  Mis-match in song file tags: 2 mbid 1 names...
...
Mis-match in song file tags: 4 mbid 1 names...
  for these songs. As far as I knew, " ft. " was one of the default artist separators so I was surprised that it didn't work. I then looked in the MusicDB with SQLite DB Browser and saw that these artist names have in fact been correctly split and each artist assigned the appropriate Artist MBID. It seems the debug log message gets printed before artist separator processing.
  
  

And one final piece of advice please: Some of the albums in my library are not yet listed in the MusicBrainz DB although their artists do have entries. For such albums (and also individual songs) I manually enter the Artist and AlbumArtist MBIDs, leaving Album and Track MBIDs blank, thinking that it would still help Kodi to at least assign these to the correct artists, especially in the case of compilation albums with many different song artists. Is this a correct approach? It seems to work well for me so far, but can you foresee any problems down the road? I can live with having to re-scan these albums/songs once they finally get added to the MusicBrainz DB and I update their tags accordingly.

[DaveBlake]

I have never tested MP3 files with only APEv2 tags so I will try to find time to do so (I'm all FLAC in own use). Meanwhile I think @scott967 may have more practical experience with APEv2 tags. Any reason for using APEv2 rather than ID3 v2.4 tag format?

No Kodi does not recognize DATE and ORIGINALDATE while parsing APEv2 tags. I'll admit that the tag names used in various formats is more than a little haphazzard, it is partly historic based on specificatuions (where they exist), partly based on community use and partly what tools like Picard do by default. I would consider adding the support for these tags in APE, the code is easy enough. But what tools are creating these tag by default, where are they in common use or are they bespoke and added by you using Mp3tag (which will add any tag name you choose)?

Yes Kodi will split "Artist Name ft. Vocalist Name" into two artists and match to 2 mbid tag values, the message in the debug log is just to say it has done this. It is deliberate because this kind of parsing is not fool-proof and did not exist in earlier versions of Kodi, so leaving a footprint in the log can be helpful.

Musicbrainz id tagging is either do it all or don't. Kodi looks for MUSICBRAINZ_ALBUMID tag value and if it finds that assumes all the other mbids are there too and uses them to create the library entires for album, artists and songs, otherwise it uses names and titles. Manually entering just artist mbid tag values does no harm, but isn't really helping either, at  least from memory I don't think it is. I don't see any problem doing that, however I would suggest that you contribute to Musicbrainz by adding those missing releases to their database. Musicbrainz is a great free resource and deserves community support

[scott967]

Sorry for late response, but i remembered some issue when original release date was first added so I wanted to do come detailed checking.

.All my mp3 have both id3v2.3 tags and APEv2 tags.  This is due to issues with multiple entries in 2.3 tags (fixed I believe in 2.4 but I need 2.3 for other players).  So for Kodi only I use mp3tag to read all the ID3v2.3 tags and write them to APE tags.  I use the prioritizeape setting and as a result I get the ID3 tags if they are missing in APE (happens with comments as I don't think mp3tag allows long comments) and also for the original year frame.

In my ID3 tagger (MediaMonkey 4) I use year-month-day format for the dates.  MediaMonkey creates 2 tag frames, TYER with just the year and TDRL with year-month-day (this is a 2.4 tag and probably MediaMonkey shouldn't be doing this).

Mp3tag will internally create 2 YEAR tags and this is what is written as the APE tag (YEAR year/00/year-month-day) note that a null (00) is written as the separator.

Some thing happens for original release date.  MM writes ID3 TORY with the year and TDOR with year-month-day.

Mp3tag creates 2 ORIGYEAR tags and this is what is written as the APE TAG (same data format as YEAR).

Kodi will pick up the APE YEAR and ID3 TDOR for me (database stores year-month-day).

Haven't tested with only APE tags, but I assume if you create an mp3tag action for ORIGINALYEAR with format field

Code:

Format value "ORIGINALYEAR":$meta_sep(origyear,\\)

that will create ORIGINALYEAR APE tag that Kodi should read.

Note that if you want Kodi to read tagged album cover art it needs to be in ID3 APIC tag frame.

I make extensive use of ARTIST ID only tags along with ARTISTS when needed and it works well in Kodi for disambiguating artists and also scraping.  But if you need ALBUMARTIST ID you also need ALBUM ID (for example 2 identical strings for name you need an ID for each occurrence of the string to get proper song and album artist db entries).  RELEASE ID is also standalone (good for scraping).

scott s.
.

[Cybermutant]

Hello Dave,
Thank you for your detailed reply, and apologies for not being able to write back earlier (typical year-end overload at work).

Any reason for using APEv2 rather than ID3 v2.4 tag format?

It dates back to the times when ID3v2 and APE tags in MP3 were newly introduced. Using ID3v1, I did feel the need for another tag format that supported longer text in Artist, Title, and Album fields, and also international characters. I liked APEv2 more technically: its placement at the end of the file (some utilities choked on ID3v2 tagged files then, thinking the file had a corrupt header), the ability to store arbitrary tags including embedded cuesheet support (although I'm moving away from single-file albums now), human-readable field names... Once foobar2000 started reading APEv2 tags I exclusively used them, with the addition of ID3v1 only for the odd MP3 player or car stereo. Nowadays I just use APEv2 for MP3s.

But what tools are creating these tag by default, where are they in common use or are they bespoke and added by you using Mp3tag (which will add any tag name you choose)?

I did realize how convoluted the tagging situation has become as I was recently reading the wikis of Kodi, MusicBrainz Picard, Mp3tag, foobar2000 and HydrogenAudio forums, trying to settle on a tagging standard for my music library. I liked that Vorbis and APEv2 field names are almost identical; it's a pity DATE and ORIGINALDATE are two of the few that differ. However, as I mentioned, the Kodi wiki does say that DATE is parsed from APEv2 tags (since v16 it says). So, in my idealism to use the same field names across all my files, I changed the tag mappings for APEv2 in Mp3tag so that they exactly match with Vorbis field names. This way, for example when I select all songs from all albums of an artist with a mix of FLAC and MP3 files and then open the "Extended Tags" view, I could see a consistent list with only one tag per info item, instead of a jumble of "ALBUMARTIST", "ALBUM ARTIST", "DISCNUMBER", "DISC", "DATE", "YEAR", "ORIGINALDATE", "ORIGINALYEAR", etc.

So, as you've guessed quite correctly, it's a bespoke scheme entirely based on personal preference and a humble attempt at bringing some order to the chaos. I hope you deem it worthy enough to merit an exception in the tag reading code.

Yes Kodi will split "Artist Name ft. Vocalist Name" into two artists and match to 2 mbid tag values, the message in the debug log is just to say it has done this. It is deliberate because this kind of parsing is not fool-proof and did not exist in earlier versions of Kodi, so leaving a footprint in the log can be helpful.

Good to know that I shouldn't worry about it then. Thanks.

Musicbrainz id tagging is either do it all or don't. Kodi looks for MUSICBRAINZ_ALBUMID tag value and if it finds that assumes all the other mbids are there too and uses them to create the library entires for album, artists and songs, otherwise it uses names and titles. Manually entering just artist mbid tag values does no harm, but isn't really helping either, at  least from memory I don't think it is. I don't see any problem doing that, however I would suggest that you contribute to Musicbrainz by adding those missing releases to their database. Musicbrainz is a great free resource and deserves community support

I resorted to using partial MBIDs to solve a problem I had when an artist has both individual songs tagged as "Artist" and collaborations tagged as "Artist ft. Vocalist". In such cases, whichever tag gets scanned first into the library sticks as the artist's name, despite ALBUMARTIST being also set as "Artist". Kodi then shows "Artist ft. Vocalist" in the Artists view of the Music section and the artist picture cannot be fetched correctly from the Artist Info folder. Adding Artist MBIDs solved this issue quite nicely, and looking into MyMusic82.db I can see that Artist MBIDs have been properly recorded in the database even from albums without Album MBIDs, including those of multiple artists split by " ft. " separators.

I do have a MusicBrainz account and I have Picard installed, but contributing wouldn't be so straightforward for me, I guess. I tend to deviate a lot from the MusicBrainz style guide; for instance, I capitalize titles differently, I use square brackets "[ ]" to denote remix names instead of the MB standard parentheses... Then there's the issue of entering correct track lengths: with some continuous DJ mixes and some consecutive gapless tracks in albums, I moved the cue points around before splitting into individual tracks so that songs change at a better instance during the transition and exactly on the beat. Hence I can't point Picard to my library and directly upload album data.

I am a difficult case, indeed And that's why I love and am grateful for Kodi, foobar2000, Mp3tag and the like: they can accommodate these quirks of mine without much hassle.

You are absolutely right about MusicBrainz deserving support, though. I'll look into the process once more. Actually, I just wish MusicBrainz and Discogs merged, or MusicBrainz auto-imported data from Discogs. Most of the songs in my library that are missing full MBIDs are rips of obscure singles and EPs from my vinyl collection, or tracks bought from Beatport, Traxsource, et al. and Discogs lists most of them. It is much more comprehensive when it comes to electronic music. Maybe that's an area I can contribute to; let me see...

[Cybermutant]

Hello Scott,
Thank you for providing further technical insight and your experience in the matter. As I mentioned in my reply to Dave, I was just trying to do some things in a bit of a non-standard way. Following the points you've touched on, I'll elaborate a little more:

I don't utilize any online scrapers in Kodi; all media sources (audio and video) are set to "Local information only". For movies and TV series I use tinyMediaManager to create NFO files. For my music library I use Mp3tag to query MusicBrainz. In case of missing information I then check Discogs and fill in the info manually, also entering MBIDs for artists that are already available in the MusicBrainz database even if the album itself is not. I keep album artwork as separate image files in the album folder; I don't embed cover art into audio file tags.

I only save APEv2 tags into MP3 files as I don't require compatibility with any ID3v2.x-only software. I'm all set with Kodi on HTPC, foobar2000 on desktop, and AIMP or foobar2000 mobile for my Android gadgets. I was surprised that Kodi still required the <prioritiseapetags> option although my files didn't contain any other tag format, which led me to write my initial post.

Whenever I can find the information I enter full ISO dates (yyyy-mm-dd) for releases, just like you do. And since these are dates and not just years, I preferred to use the DATE and ORIGINALDATE tags thinking Kodi would support them with APEv2 format too. It turned out that it doesn't, and I'll revert to using YEAR and ORIGINALYEAR if Dave decides against supporting xxxDATE tags in APEv2. I'm hopeful, though, seeing how the existing APEv2 parser already checks for and accepts several other Vorbis tag names

[scott967]

Hello Scott,
Thank you for providing further technical insight and your experience in the matter. As I mentioned in my reply to Dave, I was just trying to do some things in a bit of a non-standard way. Following the points you've touched on, I'll elaborate a little more:

I don't utilize any online scrapers in Kodi; all media sources (audio and video) are set to "Local information only". For movies and TV series I use tinyMediaManager to create NFO files. For my music library I use Mp3tag to query MusicBrainz. In case of missing information I then check Discogs and fill in the info manually, also entering MBIDs for artists that are already available in the MusicBrainz database even if the album itself is not. I keep album artwork as separate image files in the album folder; I don't embed cover art into audio file tags.

I only save APEv2 tags into MP3 files as I don't require compatibility with any ID3v2.x-only software. I'm all set with Kodi on HTPC, foobar2000 on desktop, and AIMP or foobar2000 mobile for my Android gadgets. I was surprised that Kodi still required the <prioritiseapetags> option although my files didn't contain any other tag format, which led me to write my initial post.

Whenever I can find the information I enter full ISO dates (yyyy-mm-dd) for releases, just like you do. And since these are dates and not just years, I preferred to use the DATE and ORIGINALDATE tags thinking Kodi would support them with APEv2 format too. It turned out that it doesn't, and I'll revert to using YEAR and ORIGINALYEAR if Dave decides against supporting xxxDATE tags in APEv2. I'm hopeful, though, seeing how the existing APEv2 parser already checks for and accepts several other Vorbis tag names

Everything you are doing makes sense as you need things to work for you.  For my part, I have an extensive collection of Korean trot music (kind of an old-school pop genre), which never shows up in MusicBrainz (or anywhere else really) and my Korean isn't where I feel able to just add a lot of data into the MB database.  (60% or so of distribution for Korean pop music is digital and digital only releases are increasingly common so getting a lot of the deeper data Musicbrainz wants is hard).  So I play around with "MB IDs" just to keep my Kodi data straight.  It would be nice if APE and Vorbis had one-to-one correspondence, as I have plenty of FLACs too.  MP3tag does have a tag mapping feature so the same column in the display can be used for tags with different names from different tag specs.  So  you can use the same column for DATE or ORIGINALDATE for both and Mp3tag will convert to the native tag name when writing.

scott s.
.

[Cybermutant]

Everything you are doing makes sense as you need things to work for you.  For my part, I have an extensive collection of Korean trot music (kind of an old-school pop genre), which never shows up in MusicBrainz (or anywhere else really) and my Korean isn't where I feel able to just add a lot of data into the MB database.  (60% or so of distribution for Korean pop music is digital and digital only releases are increasingly common so getting a lot of the deeper data Musicbrainz wants is hard).  So I play around with "MB IDs" just to keep my Kodi data straight.

Nice to read that I'm not alone in "playing around with MBIDs". I'll admit to one more sin and hope it won't get me banished I had to enter dummy MBIDs for some files in my library to help Kodi distinguish between similarly named artists who aren't yet included in the MusicBrainz database. I keep a list of those dummy IDs in a text file in my library folder and I will either try to add them to the MusicBrainz database myself, or periodically check for updates if they are already pending for inclusion.

It would be nice if APE and Vorbis had one-to-one correspondence, as I have plenty of FLACs too. MP3tag does have a tag mapping feature so the same column in the display can be used for tags with different names from different tag specs.  So  you can use the same column for DATE or ORIGINALDATE for both and Mp3tag will convert to the native tag name when writing.

I'm aware of that feature. I had actually removed the default APEv2 mappings from MP3tag so that the raw tag data in the file also matches, and no conversion needs to be done behind the scenes. I could then, say, do a binary "grep" (a Linux command that can recursively search file contents in a directory hierarchy) for "YEAR" in files of type *.mp3 in a specific part of my music library and see if I've missed any songs during my "tag standardization overhaul".

Another gripe I had was seeing multiple variants of the same tag in Mp3tag's "Extended Tags" view for a mixed selection of MP3 and FLAC files, even when the tag mappings were in place. At least that's how I remember it was: the main list view matches user intent (as all columns can actually be customized using built-in scripting functions and variables) but "Extended Tags" always shows the raw field names. However, after reading your post I tested that again, mapping TRACK to TRACKNUMBER, and it worked as it should! "Extended Tags" now shows TRACKNUMBER while the MP3 file has the tag written as TRACK. Could be that I remembered wrong, or maybe Mp3tag behaviour changed in the meantime. Anyway... It will then work equally well for DATE and ORIGINALDATE too, so thanks for prompting me to try this again.

[Cybermutant]

I have never tested MP3 files with only APEv2 tags so I will try to find time to do so (I'm all FLAC in own use).

I forgot to ask: Shall I create an Issue on Kodi's Github repo about this as a reminder? And what is Kodi devs' preference for user bug reports? Post in the forum first and confirm that it's actually a bug, or create an Issue on Github directly?

[DaveBlake]

Kodi's devs are notrious for ignoring bug reports wherever they are reported
Seriously, there are so few of us actively working on Kodi at the moment that with millions of users bug reports build up faster than we can clear them (or even triage them). Anything is just as likley to get "forgotten" on Github as it is the forum.

It depends on the problem but generally it does no harm to try the forum first, confirm what you experience is a bug. The forum has a wider audience of expert users too than Github, and they can help by reproducing and suggesting work arounds etc. You now have my attention, and as a muisc lib/tagging related issue I am the dev most likely to do something about it, so Github issue isn't needed.  For bugs in other areas some of the devs concerned prefer Github issues as a means to collect details about the problem etc., and never look at the forum. But Github issues can lurk even longer than forum posts - there is no fast track.

BTW I am happy for users to make Kodi work for them in any way they like. Using dummy MBIDs to allow Kodi to distinguish between similarly named artists is fine as long as you don't try to scrape additional info or art for those artists remotely.

[Cybermutant]

Kodi's devs are notrious for ignoring bug reports wherever they are reported

Ah-hah-ha Thank you for this honest statement