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.
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 ?
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
Picard is more strict in this regard and uses a separator string (but it will read the fields written by MP3Tag as well).
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.
