[2025-05-20] FIX: MusicBrainz schema change resulted in track numbers not being imported correctly.
3 Likes
I saw this. It’s a really odd bug. I wonder how reading the data was implemented that the recent changes (which only was about adding fields unrelated to track numbers) could trigger such wrong track number reading.
3 Likes
- There are more things in heaven and earth, Horatio,
Than are dreamt of in your philosophy.- Hamlet
The last time I had dealt with Mp3Tag tagging sources, the code for the MB source was using the XML API and regular expressions for parsing… So I’m not really surprised 
I had even written an almost complete Mp3Tag source for the JSON API in 2019, but then I discovered Picard instead, registered an MB account and the rest is history 
8 Likes
It was fairly trivial: the script looked for <medium> and the schema change added an id attribute resulting in something like <medium id="...">
The tag source for MusicBrainz that ships with the Windows version of Mp3tag is indeed using the XML API. There are newer, community-contributed tag sources that utilise the JSON API, like MusicBrainz Expanded and I need to update this at some point.
The macOS version is using the JSON API and wasn’t affected by the schema change.
Interestingly, the MB schema change coincided (albeit unintentionally) with the planned release date for Mp3tag v3.30. This allowed me to update the tag source ahead of the public release. So no harm done, and certainly no fault on MB’s part.
5 Likes
If you’re parsing XML, the addition of an ID or of any number of attributes anywhere, without changing the tree, should not break anything.
But if you’re parsing it as text, with regular expressions, like @kellnerd said, then it breaks.