#musicbrainz

sentriz: for the tag usage player support is the most authorative answer you'll usually get. Most of the best practices was essentially defined by the popular players

But all tag standards in some way define a field for the artist name. Except for the xiph page none explicitly mentions it to be multi-valued. And the vast majority of players does not support multi values there

The multi-valued ARTISTS was essentially introduced by Picard on request of users, and I think first adapted by Kodi

But the separation as it is makes sense.

None of the tagging standards does support a structure like MB's Artist Credits, with multiple values and join phrases for rich rendering

So having a display string is useful

I think we have a scripting example in the docs on how to make ARTIST multi-valued, but that way definitely is badly supported by players

multi-valued ARTISTS is actually part of the vorbis tagging thing, IIRC, mutagen only added it a few years ago tho

derwin: it isn't. Vorbis has only very thin tag specs, the closest you get is the docs sentriz linked above. And it only defines ARTIST

But it describes it to allow multiple values (but which most players did not support)

Also mutagen itself does not have any explicit support for ARTISTS. It just allows to write arbitrary tags, and both beets and Picard use it

sentriz: You could make prioritizing multi-field ARTIST over ARTISTS an option, or alternatively, you could check if ARTIST is multi-valued and ARTISTS does not exist and then handle it appropriately.

Most music players that I have tried only recognizes the first field in ARTIST, so that is what discouraged me from putting the individual artists into ARTIST as separate fields. At one point, I even formatted ARTIST like ["X ft. Y", "X", "Y"] but ARTISTS is definitely better supported so I gave up on that quickly.

I only know the ID3 spec so maybe this is not the case with other formats but there is a very significant lack of paired or delimited data types, only lists (with the exception of TMCL and TIPL as of 3v2.4). Of course, you could treat the lists as delimited or paired internally, but you have to just hope that the tagger didn't do it in a different way.

And even then, you're bound to common practices. For example, TLEN, the length of the track, is _supposed_ to be in milliseconds, but you always find it in a [HH:][M]M:SS format.

thuna`: the main reason the ARTISTS tag often doesn’t work is that if you read the ID3 spec strictly, it doesn’t allow multiple values for TXXX frames

mutagen goes beyond the spec, but quite a few other implementations do not (eg gstreamer doesn’t)

elomatreb: for ID3v2.4 TXXX frames explicitly support multiple null separated strings (according to spec, not supported by all players). But extending this to non-TXXX frames is I think beyond the spec

outsidecontext: I believe you have that the wrong way around

some tools also use the same approach then for ID3v2.3, e.g. MP3Tag does. but v2.3 explicitly says to ignore data beyond the null

^ This is from id3v2.4-frames

thuna`: yes, exactly. that says "All text information frames supports multiple strings, stored as a null separated list, where null is reperesented by the termination code for the charater encoding." . that's multiple values

thuna`: ah, I see what you mean. yes, you're right. it's only non TXXX text frames that are explicitly defined like that.

outsidecontext: According to the spec, TXXX supports exactly one encoded string as the value, and no two TXXX frames may have the same description. So, neither multiple ARTISTS frames nor a single ARTISTS frame with multiple strings is valid, and I guess the authors expected the descriptions to be indexed as well

Since that's not going to happen, you might as well allow multi-valued TXXX frames

The ID3 spec is terrible in any case

so many overengineered features while basic ones are neglected