Support reading differently named catalog number file tags

[JOJ0]

Eg mp3tag was using DISCOGS_CATALOG a couple of years ago and is using CATALOGID, which my current tests using a trial version of mp3tag for macOS revealed.

This feature enables beets make use of these potentially available on-disk fields when importing and having musicbrainz.extra_fields: ['catalognum'] set.

[JOJ0]

Out of curiosity I also got in contact with the dev of mp3tag and asked how he came to the naming decision of CATALOGID. Reply pending. The same question I would like to ask you @sampsyo for CATALOGNUM :-))) Sorry I did not do my homework of googling for what the more widely used name might be. Just asking around first ;-)

[sampsyo]

All looks good, if this is a common thing we should support! Does mp3tag have some documentation we could link to here?

Just to clarify, catalognum is an internal name, so it doesn't reflect any decision about on-disk tags. It's just an arbitrary column name for the Python side of things. The current set of on-disk tags, such as CATALOGNUMBER in Vorbis Comments, comes from Picard: https://picard-docs.musicbrainz.org/en/appendices/tag_mapping.html#id7

[JOJ0]

Hi, sorry there was a typo in my post, I actually wanted to write CATALOGNUMBER, thus the misunderstanding. Yes catalognum is just the attributes name to access the on-disk tags, got that :-)

Unfortunately mp3tag's documentation does not include that CATALOGID field: https://docs.mp3tag.de/mapping/

But here is a screenshot of a fresh and uncustomized mp3tag for macOS installation, tagging an mp3 file from MusicBrainz:

• I tested mp3 files and flac files
• It equally writes such a tag with either MusicBrainz or Discogs as the metadata source.

Regarding the "old" behaviour of mp3tag with Discogs catno's I find the term DISCOGS_CATALOG quite often on the mp3tag community forum: https://community.mp3tag.de/search?q=DISCOGS_CATALOG

These days no additional plugin/script/whatever is needed. Both MusicBrainz and Discogs are supported OOTB, which is stated here: https://docs.mp3tag.de/tag-sources/import/

[JOJ0]

Something else: I had an mp3 file that had a TXXX tag named CATALOG #, and it turned out that it was read and used somehow in the import, because I saw the catalog number that was saved in that tag in the "searching musicbrainz for ......" verbose log output. I even tried it importing it again with the original file restored from backup. And it worked again :-o

Is that by any means possible? I can't find such a tag name variation in mediafile's code.

[sampsyo]

Hmm; I'd be pretty surprised if we somehow magically found a TXXX tag with description CATALOG #! I'm not sure how that would work…

[JOJ0]

Furthermore, I think, great news :-)

mp3tag devloper Florian Heidenreich just told me that due to our conversation about this specific tag name, he changed the default to CATALOGNUMBER. The change is included in the latest release which just came out for Windows, the macOS release will follow: https://community.mp3tag.de/t/mp3tag-v3-13-released/56785

Also he included it in the docs: https://docs.mp3tag.de/mapping/

and it's talked about it in the forums already: https://community.mp3tag.de/t/do-we-need-to-change-catalogid-to-catalognumber-in-existing-tags/56792

👍

Since this PR was about to improve importing behaviour of older files and this changed just now in mp3tag, IMHO it certainly still is a feature addition that makes sense.

[sampsyo]

Wow; great development! Thanks for doing the homework. :smiley: Can you please throw a changelog entry onto this PR and we'll call it done?

[JOJ0]

Changelog added :-) Thanks!

[sampsyo]

Great; thank you for your diligent work on this!! Merged! ✨