2019-11-26, 15:45
Thanks for files @Uatschitchun - I should have asked for track 3 not 2, but interesting tag data anyway and track 5 demonstrated what I suspected could be the case.
For starters Mp3tag can only see the APEv2 tags in thoses files (MP3GAIN/REPLAYGAIN data) and not the ID3v2.4 values, that looks most odd (no artyist, tittle etc.) but is a Mp3tag issue. Looking in Picard I can see all the expected ID3v2.4 tag values (and not the APEv2 ones, were you even aware they were there?). What matters of course is what the taglib library reads, and it sees the ID3v2.4 ones.
The issue is the contents of the COMPOSERSORT tag compared to the COMPOSER tag - the order of artists in these need to match. In track 5 you have:
COMPOSER = Göran Walger; Klaus Lage; Rolf Klein; Martin Engelien; Wolf Simon
COMPOSERSORT = Engelien, Martin; Klein, Rolf; Lage, Klaus; Simon, Wolf; Walger, Göran
When Kodi decoded this it would pair up the wrong artist and sortnames. As it happens it probably gets the sortname values for Klaus Lage and Martin Engelien when processing track 3, but I expect that has a similar mis-match.
If I read the current Musicbrainz values for track 5 all the tag values match those that you have saved except for COMPOSER.
COMPOSER = Martin Engelien; Rolf Klein; Klaus Lage; Wolf Simon; Göran Walger
Matching the artist name order in the COMPOSERSORT tag
I don't use any Picard plugins, never found any need, but I can't from plugin name alone see why those you listed would cause this. However something has caused the COMPOSER tag value to be in a different order from that given by default now by Picard v2.1.3 and, most significanltly, different from the artist order in COMPOSERSORT. Any ideas what caused that?
If you lookup this album again at Musicbrainz using Picard does it return different COMPOSER tag values to those saved in the files?
The solution lies in tagging with order of artist in COMPOSERSORT and COMPOSER tags matching. Yes another fussy detail, but I don't see how else Kodi could make sense of the data in these tags, and matching artist order in these tags is the deafult behaviour of Picard. Try not to grumble too much!
I am really interested to know how the tag values got the way they are, obviously if we can advise others to avoid the issue that would be good.
For starters Mp3tag can only see the APEv2 tags in thoses files (MP3GAIN/REPLAYGAIN data) and not the ID3v2.4 values, that looks most odd (no artyist, tittle etc.) but is a Mp3tag issue. Looking in Picard I can see all the expected ID3v2.4 tag values (and not the APEv2 ones, were you even aware they were there?). What matters of course is what the taglib library reads, and it sees the ID3v2.4 ones.
The issue is the contents of the COMPOSERSORT tag compared to the COMPOSER tag - the order of artists in these need to match. In track 5 you have:
COMPOSER = Göran Walger; Klaus Lage; Rolf Klein; Martin Engelien; Wolf Simon
COMPOSERSORT = Engelien, Martin; Klein, Rolf; Lage, Klaus; Simon, Wolf; Walger, Göran
When Kodi decoded this it would pair up the wrong artist and sortnames. As it happens it probably gets the sortname values for Klaus Lage and Martin Engelien when processing track 3, but I expect that has a similar mis-match.
If I read the current Musicbrainz values for track 5 all the tag values match those that you have saved except for COMPOSER.
COMPOSER = Martin Engelien; Rolf Klein; Klaus Lage; Wolf Simon; Göran Walger
Matching the artist name order in the COMPOSERSORT tag
I don't use any Picard plugins, never found any need, but I can't from plugin name alone see why those you listed would cause this. However something has caused the COMPOSER tag value to be in a different order from that given by default now by Picard v2.1.3 and, most significanltly, different from the artist order in COMPOSERSORT. Any ideas what caused that?
If you lookup this album again at Musicbrainz using Picard does it return different COMPOSER tag values to those saved in the files?
The solution lies in tagging with order of artist in COMPOSERSORT and COMPOSER tags matching. Yes another fussy detail, but I don't see how else Kodi could make sense of the data in these tags, and matching artist order in these tags is the deafult behaviour of Picard. Try not to grumble too much!
I am really interested to know how the tag values got the way they are, obviously if we can advise others to avoid the issue that would be good.
