Few minor issues with MusicBrainz tags

Hi Florian!

Thank you for your continuous work on Mp3Tag. I have found some some minor issues in regards to MusicBrainz tags so I am letting you know.

The first one is regarding the tag ACOUSTID_FINGERPRINT. According to your post in Add mappings for more MusicBrainz tags - #12 by Florian it should be present in Extended tags alongside ACOUSTID_ID, however only the latter one is there. I have found my old report in Two issues with Extended Tags - #7 by Florian where I have encountered a bug with two ACOUSTID_ID fields where you have chosen to remove the duplicate one. I had a suspicion that the duplicate ACOUSTID_ID was actually supposed to be the ACOUSTID_FINGERPRINT, however I probably didn't make myself clear enough when reporting it at the time. Could you please take a look and check if it should be added as well?

The second issue is regarding the tag mapping. I have checked all of MusicBrainz tags for ID3 and Vorbis and I have found out that 3 tags do not match the Vorbis mapping according to MusicBrainz documentation in Appendix B: Tag Mapping — MusicBrainz Picard v2.6 documentation. The tags are MUSICBRAINZ_ALBUMSTATUS, MUSICBRAINZ_ALBUMTYPE and MUSICBRAINZ_ALBUMRELEASECOUNTRY. According to the source mentioned, they should be mapped to RELEASESTATUS, RELEASETYPE and RELEASECOUNTRY respectively.

What is interesting about these 3 tags is that they aren't really identifiers like the other MusicBrainz tags (e.g. with values such as 81cba7a1-222e-4901-b5c8-134ddd4e85aa), but instead they are just like other tags (e.g. with values such as official, single and US).

Here is a summary of how it looks now and how it should look:

Mp3Tag MusicBrainz ID3 MusicBrainz Vorbis

In the meantime I have remapped the fields using the custom mappings but perhaps you'd like to change them for everyone by default so that's why I have decided to report this to you as well. If this isn't an oversight but there is a reason why these 3 tags are mapped like this, please let me know. Also, I have not checked other formats except ID3 and Vorbis so I am not sure how are other formats mapped.

Thank you for taking a look at it, it is very much appreciated!

Thanks for your feedback!

Regarding the first issue with ACOUSTID_FINGERPRINT I think you can simply use that field in the extended tag dialog and it will be automatically added to the list. I am hesitant to add this as default, mainly because Mp3tag currently doesn't support calculating fingerprints and I assume that it's usually not added manually.

Regarding the second issue, I'm not very happy with this special handling of MusicBrainz names for Vorbis Comments when some of them are using the name prefixed by MUSICBRAINZ_ and some of them don't. I have access to an internal mapping table for MusicBrainz Picard, where it uses the prefixed names, but this might have changed in the meantime — but I'm not sure about the specific reasons. Maybe @phw can shed some light into this?

Happy you already found a way to map them according to your requirements.

Thanks for the fast reply!

As for the ACOUSTID_FINGERPRINT tag, I am not quite sure when exactly is this tag populated by Picard as I am actually not using it myself, I just wanted to make sure that my previous actions when reporting the duplicate ACOUSTID_ID issue and you removing it didn't mess up anything as you have previously decided to also include ACOUSTID_FINGERPRINT into Extended tags.

Thanks for answering the second issue as well, in this case I do use these 3 tags myself and basically I am just making sure that Mp3Tag and Picard would behave the same for people who won't know that these tags are differently mapped. It won't be a big deal if you decide against it as the workaround is available. Let's see what @phw has to say regarding these tags and why are they a bit different.

Currently never. Picard however supports it if it is set. If there is a fingerprint stored in ACOUSTID_FINGERPRINT Picard will skip calculating the fingerprint and use the given fingerprint. This can be disabled in options. At some point it was considered unnecessary to store the fingerprint in the tags as it is directly derived from the audio content anyway and can be calculated anytime. There are some use cases, e.g. someone on the MB forums mentioned that they write this tag directly as part of their ripping process. Then when tagging with Picard it does not need to calculate the fingerprint again, saving some time. I am considering having an option to let Picard write this tag if someone wants/need it for some reason, though.

I don't think there is a specific reason other than this happened to how it turned out. Traditionally Picard writes tags to Vorbis as they are named in Picard unless they are specifically mapped. As Vorbis only has very rudimentary definitions of tag names and most of the actual tag names are more defined by common usage those tags for releasecountry, releasestatus and releasetype just never were specifically considered and the internal naming of Picard kind of leaked out. Not sure how good it would be to change that, we tend to not change existing tag names unless there is a real need to do so.

Many thanks for the feedback and the details!

I've re-added ACOUSTID_FINGERPRINT to the list of standard fields on new installations or field-list reset with Mp3tag v3.06b.

I'm still not sure about releasecountry, releasestatus and releasetype. I have a note regarding this on my internal list.

1 Like

Thank you for taking the time to look into this, I really appreciate it.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.