Add field mapping for MusicBrainz Picard

I have mentioned this on a Picard ticket so hopefully it will be capitalized in the future.

Are you sure about this? Picard seems to be using neither of those tags but instead it's using one of the MusicBrainz specific tags named "MusicBrainz Album Release Country" which is correctly mapped in Mp3Tag as MUSICBRAINZ_ALBUMRELEASECOUNTRY.

As for the remaining tags, you should be able to use the custom mappings in Mp3Tag's Options/Tags/Mappings with the following values:

ID3v2 COUNTRY RELEASECOUNTRY (you shouldn't need this if you would use the MusicBrainz specific tag for the album release country)

If some of these don't work, try switching the Source and Target values.

You're right, it's MUSICBRAINZ_ALBUMRELEASECOUNTRY, but MP3Tag shows it as COUNTRY or RELEASECOUNTRY. Picard as a releasecountry. I read the correct tags only from
I managed to get releasecountry compatibility in FLAC and Mp3 and label files.
In no way does it succeed with originalyear and discsubtitle in Mp3 files.
If I download the information in Picard - discsubtitle.
Loading mp3 to MP3Tag is there - SETSUBTITLE.
After saving the Tag in MP3Tag and loading it again in Picard - setsubtitle suggests to delete it, and again to write discsubtitle.
No way of mapping succeeded so that after saving the tags in both programs were the same fields.
The same is with originalyear.
In FLAC files everything is OK - nothing changes, there is compatibility in all fields.
I have a problem with mp3 files.

I did some more investigating and I have found out that the tag mapping for


works for ID3v2.4 (Mp3Tag correctly writes it into the TSST tag) but not for ID3v2.3 which writes it into TXXX:SETSUBTITLE (this is the issue you are having).

According to Mapping – Mp3tag Documentation the ID3v2 tag name should be enough for the tag mapping. @Florian am I missing something or is this a bug with the TSST tag field? Are there any more tag fields affected like this? I tried to reproduce it with a different tag field such as Artist (TPE1) and it's mapped correctly for both ID3v2.3 and ID3v2.4 tags.

(I tested this in Mp3Tag v2.91b, I will update into 2.91d and re-test this again in the evening if needed.)

The TSST frame was introduced with ID3v2.4 and doesn't exist for ID3v2.3. This is also reflected at Tag Field Mappings – Mp3tag Documentation for SETSUBTITLE.

Ah, that's why. It seems like Picard is using the TSST frame for both ID3v2.3 and ID3v2.4. @phw can u chime in on this? :slight_smile:

Picard does save a couple of ID3 v2.4 tags to v2.3 also for compatibility. Originally this was TSOA, TSOP and TSOT. With Picard 1.4 also TSST was added there. Interestingly in the ticket requesting this feature MP3Tag was listed as a reason for supporting this. @Florian did this change during the years?

1 Like

@Zwanzig In the meantime there is a workaround to force Picard to use the TXXX:SETSUBTITLE frame that Mp3Tag is using. Go to Picard's Options/Scripting and add the following code:


or you could even use


The code above will also delete your existing Disc Subtitle tags that have been written in the TSST frame by Picard.

The disadvantage is that the field will be shown in all caps as "SETSUBTITLE" in Picard's UI but now you should be able to modify the value written by Picard also in Mp3Tag without having any issues.


No. I've just checked the version that was active when this issue was created and it also did write TSST only for ID3v2.4.

1 Like

OK, thank you for the tip. For now I am at work, in a few days, when I come back, I will check this way and see how it works for me.
By the way the question - maybe it's better to go to id3v2.4? Some time ago I tried but I withdrew - because of which I do not remember :). What are the obstacles to using id3 v2.4?

The only disadvantage that I know is the lack of hardware support, e.g. the stereo in your car might have issues loading ID3v2.4 tags, or at least it was like this a couple of years ago. I don't know how much has changed in this regard since then.

Unfortunately, after many attempts, it still causes me chaos in Tagas.
Question to the Developer of the Mp3Tag - is there any amendment possible to synchronize the previously discussed fields?
Or maybe this is a question for the creators of Music Brainz Picard.

@culinko Thank you for this hint!

Are you sure that this is still true if you try this syntax in MusicBrainz Picard Options -> Options -> Scripting -> Tagger Script?


Yeah, I just tested your script and it was still displayed in all caps (the tag value was saved via Mp3Tag).

Thanks for testing. How did you set the value in Mp3tag exactly? Manually? With an Action? With a Websource-Script? Would be interesting to know what exactly writes this tag in Mp3tag and which syntax is used.

I right clicked on imported file, selected "Extended tags..." and added the tag via the "Add field..." button.

And the "Add field..." button suggested what fieldname exactly in what syntax?
Could you please show us a printscreen?
(You can create a printscreen and paste it directly into your answer box.)

It did not suggest anything, I have typed it manually (I have tried both DISCSUBTITLE and SETSUBTITLE just to be sure, case doesn't matter as it is always all caps). I have also set ID3v2.3 as the tags to write in both Mp3Tag and Picard.

I have already switched my settings back to what I use (I am not using this any of these tags myself and I'm also using ID3v2.4 in my music files) and honestly don't really want to spend any more time on this myself as the issues by the reporter have been addressed and various workarounds have been proposed.

Perhaps other posters could help you regarding this matter.

Thank you anyway.

Just for the record for other users interested in this topic:
You can set and fill the "SetSubtitle" (1th and 4th letter uppercase from within a Websource-Script) in Mp3tag. Then you can see it the same way in MusicBrainz Picard and prevent the


Would it be possible to get an updated list of implemented tag mappings at Tag Field Mappings – Mp3tag Documentation please?

I had serious trouble to correctly map the somewhat stupidly named MusicBrainz Picard internal tag "MusicBrainz Recording ID". While other common MusicBrainz Picard tags are correct mapped, this one isn't. I thought it's "MUSICBRAINZ TRACK ID" because that's how mp3tag is showing that tag written by Picard but when I write that tag with mp3tag, Picard is not recognizing it. I created a mapping for MP4 - MUSICBRAINZ TRACK ID - MUSICBRAINZ_TRACKID

Turns out, the correct mapping is MP4 - MusicBrainz Track Id - MUSICBRAINZ_TRACKID

This is the current list of MusicBrainz field mappings:

MUSICBRAINZ_TRACKID is a little special, because it's mapped to the ID3v2 UFID (unique file identifier) frame for MP3.

I've made a note to add a dedicated section for MusicBrainz field mappings to the mapping table in the documentation.