MusicBrainz Picard "v2.9 Beta 1" with new default settings to use ID3v2.4 instead of v2.3

I just read that the new released MusicBrainz Picard (tagging software) switches to ID3 v2.4 as default setting.

From the MB blog about the changes:

Among the more visible changes are a new application icon for macOS, several new scripting variables for file creation dates, series details and lyricist / writer sort and a new tag releasedate which maps to ID3 v2.4 TDRL.

Also with this release Picard changes the default settings to use ID3 v2.4 instead of v2.3 and also enables the option “Use standardized artist names” by default. These changes of default configuration values only affects new installations, existing installations retain the existing configuration settings.

It could be that we will see increased support questions for Mp3tag about this change in MB Picard.

1 Like

This should also be harmonized between Picard and Mp3tag in the future.

In what respect?
Even today you can set MP3tag to write ID3V2.4 tags (and read and delete them).
The question is: which player is happy to support that change? Or, in other words, what is the point in this if the rest of the world still sticks to ID3V2.3?

Oh, I mean the upcoming version of Picard maps RELEASEDATE to TDRL (according to their announcement, I haven't tested yet) and Mp3tag currently maps RELEASETIME to TDRL.
This is not the same e.g. regarding to MusicBee.
Wouldn't it be better to get harmonized?

Or would help some Mp3tag custom mapping, e.g. VorbisComment RELEASEDATE RELEASETIME ?

Wouldn't it be a mistake on Picard's side to map a user-defined field to an existing one?

Anyway: if they obey the rules for RELEASETIME, they can call the field whatever they like in their user-interface.

1 Like

One important difference, and one that was a major reason to finally change the default in Picard, is the proper support for multi-value tags in ID3v2.4. For Picard we had a couple of support cases regarding this which were solved by changing from v2.3 to v2.4.

Also player support for ID3v2.4 has (finally) improved. In recent times I have seen less issues reported were poeple struggled with ID3v2.4 not being supported by their player (which used to be the reason for sticking with v2.3 for so long).

I totally expect that some people will have to change to v2.3 for compatibility with older hardware players etc. But currently it looks like this causes less issues then the other way around.

But I'm happy to report back after a while. We'll see how this goes in reality.

This puzzles me - MP3tag and Foobar2000 have been supporting multi-value fields for a very long time in V2.3.
But the players usualy spoil the game.
Instead, they implement their own way as has been discussed in this thread:

The difference is that on a technical level with v2.4 for all text frames you get really a list of separate values according to the specs (with null separated strings). v2.3 does not specify this. A common approach is using some separator string such as "/". Which obviously breaks if the stored value naturally already contains this separator.

Some players might read null separated values for v2.3 just the same as for v2.4. But then you are likely dealing with players that also handle v2.4 and just apply the same logic to the older tag format.

I think (but might be wrong, as I don't know MP3Tag that well) MP3Tag separates multiple values for v2.3 in a similar way as for v2.4, and likely this works rather well. But it is not entirely fair to blame players for not reading it properly, as this is just not specified :slight_smile:

Picard is more strict in this regard and uses a separator string (but it will read the fields written by MP3Tag as well).

1 Like

Just here to confirm this behavior of Mp3tag. I never wanted to deal with the problematic way of multiple fields from v2.3 and use the same approach for v2.3 and v2.4.


Is it correct, that Mp3tag makes a very small difference between 3 ARTIST tags (TPE1) with different content
saved as
ID3v2.3 - ISO 8859-1:

and ID3v2.4 - UTF-8:

with a difference only in Byte #4 and the Byte before "Artist 1"?

MB Picard saves the same three ARTIST tags in ID3 v2.3 ISO-8859-1 like this (using the choosable MB Picard default separator /):

and in ID3 v2.4 UTF-8 like this (without the choice for a separator):

Yes, but you made it extra tricky by mentioning ID3v2.3 first, but showing it on the right side of the screenshot above.

The difference is the ID3 version (0x03 vs. 0x04) and the text encoding identifier (0x00 for ISO-8859-1 and 0x03 for UTF-8).


+1 for making ID3v2.4 the default.
It's time.

(23 years after v2.4 was introduced)

1 Like