[black_eagle]

Well, thanks a lot for even wanting to spend some time looking into this niche of a niche. Much appreciated.

I have some stuff in my library which would benefit from this, so it's purely selfish!!

Anyway, I have already found some limitations.  the matroska spec allows for multiple tags for the same thing, eg you can have multiple "Composer" tags, with each set to a single composer.  mp3tag can read and write those correctly, but ffmpeg, and therefore Kodi, only reads one tag and ignores the others.

This means that for multiple composers, the tag has to have a value of "composer1;composer2;composer3" etc.  Current valid separators are ";", "/", ",", "&", " and ".  As there is no standard as such as to how Kodi expects these tags to be formatted, we will, between us all, invent one!

So, what I have at the moment will accept one tag named "Composer" (case is irrelevant) with a value of one or more of

• Richard Wright;Clare Torry
  
• Richard Wright/Clare Torry
  
• Richard Wright,Clare Torry
  
• Richard Wright & Clare Torry
  
• Richard Wright and Clare Torry
  

Same goes for the INSTUMENTS tag, which needs to contain a comma separated list of instrument,performer.  This is how tags are handled at a low level, but usually, your tagging software formats it all up correctly.




It works, but the code is currently not pretty at all. It's certainly not something I would PR right now, but as a POC, it does what it should. You can't see them in the screenshot but the correct Artist, album and track musicbrainz ID's are in the db.

[black_eagle]

With Omega so close to a release is it possible for you to change the MKA = audiobook issue ASAP. That stops cues from working when an MKA has chapters (that was a fairly recent change in Kodi I think - we never had to strip chapters out previously)

I don't think anything has actually changed in this regard at all.  Certainly I don't recall making any changes before in this area and I don't remember @DaveBlake doing so either.......

Omega is in beta2, beta3 is overdue so I doubt I could get any changes in now anyway.

The version that I initially used was indeed Omega, but I'm pretty sure Nexus can read at least some tags from MKA files.

How does Kodi get the song titles. Is it from the MusicBrainz Release ID? (That file only has tags for one song)

Song titles are actually chapter titles.

Maybe these screenshots will help.

[HomerJau]

Thanks. (but your original screen shot of your mka file in mediainfo has no Chapter Titles that match the Song Titles...

Anyway I can experiment with your info in v21 and see what I can do.

[black_eagle]

Grrr, once again (as I've been here before!!) changing the handling of mka files necessarily means changing the handling of m4b files which really means looking at audiobooks in their entirety and fixing up stuff for mp3/flac/someformat for audiobooks whilst retaining better processing for mka files.  Meh!!

[HomerJau]

Thanks for looking at this @black_eagle

[HomerJau]

Thinking about a mka tagging workaround for Kodi (TagLib and ffmpeg tag readers can’t read all Matroska tags):

For Kodi’s music library we really need MusicBrainz IDs as well as song ‘tags’ (track, song artists if not same as AlbumArtist, song title). The @black_eagle mka works if the artist and album tags are found in MusicBrainz (so an exact match is critical), that may not always happen.

Edit: The real issue is the lack of Matroska tag support in Kodi’s two standard libraries: TagLib and ffmpeg. I’ve been waiting for nearly 6 years now for that to change. So here’s a solution that could be implemented immediately without changes to 3rd party libraries: @black_eagle @DaveBlake

Getting all the required tag data could be achieved with an expanded album.nfo definition:

Proposed Album NFO changes:
Add the Album MusicBrainzIDs for AlbumArtist, Album, Release

Add a new multi Song definition: (similar to the Actor node in a Movie nfo)

Code:

<song>
<track>1</track>
<title>The First Track Song Title</title>
<start>00:00:00</start>  - offset like a cue file
<duration></duration>  - optional but if the last track has this Kodi’s last song in song db can be populated - it does not now with a cue
<songartist>see below</songartist> (allow multiples per song node)
</song>

One Song node per album track

The songartist child node above should be similar to the current albumArtistCredits node, with multiple definitions per song allowed

Code:

<songartist>
<artist></artist>
<musicBrainzArtistID></musicBrainzArtistID>
</songartist>

Using these new nodes, an album nfo could be read and all the data required in the music database would be available (just like ‘normal’ tags from a FLAC etc)

 
Music scanning would need to change to read each of these new album nfo nodes, but that should be straight forward (as that code exists).

Questions: Should this new album nfo reading/loading only operate on Matroska files or are there other multi song files that need to be supported? Some users use mpa to store Atmos. So maybe it’s if a chaptered format look for an album.nfo and if it has album MusicBrainzIDs or new Song nodes scan those into the library and don’t read tags directly from the media file?

Comments encouraged please. Is there another way? But no more waiting for TagLib/ffmpeg support please.

I can do the code changes required and test locally (if no one else is interested). Maybe this would be accepted in Kodi v22?

Using nfo means it will be supported on all Kodi platforms.