Borewit / music-metadata

Stream and file based music metadata parser for node. Supporting a wide range of audio and tag formats.
MIT License
898 stars 90 forks source link

multiple values in ID3v2.x tags not splitted #432

Closed snx888 closed 4 years ago

snx888 commented 4 years ago

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.artistattribute 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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Related:

Borewit commented 4 years ago

MP3tag seems to ignore everything beyond the $00: image

Foobar2000 does support the $00 splitting:

image

Picard (using mutagen) supports the split as well: image

As most applications handle this deviation, I will follow.

snx888 commented 4 years ago

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: Mp3tag v2 91

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 commented 4 years ago

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 commented 4 years ago

Resolved in v6.3.3

snx888 commented 4 years ago

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

I played around and figured out that Mp3tag:

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 commented 4 years ago

APE is preferred in settings

That is correct:

https://github.com/Borewit/music-metadata/blob/13a090f55514a14f317e38279861c09972227d40/lib/common/MetadataCollector.ts#L17

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 commented 1 year ago

@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.