multiple values in ID3v2.x tags not splitted

[snx888]

Bug description
Multiple values for fields like Artist, AlbumArtist, Composer, Genre, .. are not splitted.
Even in the common tag section, which seems to be prepared handling multiple values, the ID3v2 is not splitted.

native: { ID3v2.3: [ { id: "TPE1", value: "2 UnlimitedRayAnita" } ] }, common: { artists: [ "2 UnlimitedRayAnita" ] }

Expected behavior
As ID3v2.x supports multiple values separated by null byte i'd expect e.g. TPE1 to be an array or at least occur multiple times within ID3v2 tag.

native: { ID3v2.3: [ { id: "TPE1", value: "2 UnlimitedRayAnita" } ] }, common: { artists: [ "2 Unlimited", "Ray", "Anita" ] }

In addition to the common.artists there is also the common.artist attribute set. I guess it would make sense to fill this using common.artists.join(', ')

Additional Info
Right now i'm bypassing this using something like:
artists=[metadata.common.artists.forEach(item=>artists.push(...item.split('\u0000')))]

Audio file demonstrating the problem
2 Unlimited - Get Ready For This (Live @ Amsterdam).zip

[snx888]

It's already working for multiple comment values, but not for artist, albumartist or composer...

This file also contains multiple comment values:
2 Unlimited - Get Ready For This (Live @ Amsterdam).zip

[Borewit]

music-metadata does support multiple values in ID3v2.3 tags, the reason it does not wok for this file is because the values are encoded incorrect:

ID3 tag version 2.3.0:

TPE1
The 'Lead artist(s)/Lead performer(s)/Soloist(s)/Performing group' is used for the main artist(s). They are seperated with the "/" character.

Version id3v2.4 however does split multiple values with a $00. But tag header should then say it version 2.4 and not 2.3.

So the real problem is caused be the application which wrote these these tags. Let's be very clear about that.

Let me investigate how other applications handle this odd value split.

[Borewit]

Related:

• Possible issue with ID3 titles containing a forward slash #52 Possible issue with ID3 titles containing a forward slash

[Borewit]

MP3tag seems to ignore everything beyond the $00:

Foobar2000 does support the $00 splitting:

Picard (using mutagen) supports the split as well:

As most applications handle this deviation, I will follow.

[snx888]

ok, i guess you're much more into all those specifications. i'm using Mp3tag for years and read some things about this multi value topic. i guess Mp3tag uses the 0-byte splitter for ID3v2.3 and ID3v2.4 even it may not be correct.

your screenshot of Mp3tag is interesting. i think you get those values cause you/it prefers APE. In my case ID3v2.3 is preferred and it looks lie this:

But using Mp3tag you're able to set a multi-value splitting separator for each column ( i guess it's set for artist and albumartist by default and i added this for comment, genre and composer). Interesting that this separator is tag-type independent, but i don't know how it is handled in the background (maybe it always uses 0-byte even the tag doesn't support it?:-/)

[Borewit]

i think you get those values cause you/it prefers APE

You maybe right, in that case, your settings are better, ID3v2.3 makes sense to be the preferred tag type for MP3. APEv2 headers do not belong in ID3v2.3. The other way around for APE. I think if you re-write the tags with mp3tag it will use / for id3v2.3. I am pretty sure Picard will.

[Borewit]

Resolved in v6.3.3

[snx888]

Thank you. Some words on the APE vs ID3 topic...

I played around and figured out that Mp3tag:

• changed only ID3v2 and ID3v1, APE stays untouched (old/wrong data)
• only creates ID3v2 and ID3v1 after removing all tags first
  In Mp3tag options we can say which tag to save and which tags to remove, but it's not possible to remove specific tag at "normal" save.

This may be the reason I got a lot of files with (maybe old/incorrect) APE tags.
Those will show wrong results using music-metadata cause APE is preferred in settings.
Right now I'm changing the priority in MetaDataCollector.js -> Maybe this would be a nice option to control via options from outside.

I'll try to figure out how many files are affected and how to easy/safe get rid of APE tags.

[Borewit]

APE is preferred in settings

That is correct:

music-metadata/lib/common/MetadataCollector.ts

Line 17 in 13a090f

const TagPriority: TagType[] = ['matroska', 'APEv2', 'vorbis', 'ID3v2.4', 'ID3v2.3', 'ID3v2.2', 'exif', 'asf', 'iTunes', 'ID3v1'];

Main purpose of this is to let ID3v2.3 or APEv2 override ID3v1.

This may be the reason I got a lot of files with (maybe old/incorrect) APE tags.

That is probably a good idea, I would go for ID3v2.4 only for MP3.

I tag my audio files with Picard. If you know which release to pick corresponding release, it is very powerful tagger. You can customize the tag headers. As music-metadata is greatly inspired with the way Picard](https://picard.musicbrainz.org/) map audio data, you will notice they are made for each-other.

It attach the MusicBrainz identifiers to the audio files, so if updates are available, or you change your mind on the tag format, you can quit easily update all of your files.

[binyamin]

@Borewit I tagged some files using Picard, and I can't seem to get multiple album-artists. I tried ID3v2.4, and ID3v2.3 with "/", "; ", and " / " separators. With ID3v2.4, the results.native value does show multiple "TPE2" header values. But music-metadata only uses the last one.