Logik hinter MUSICBRAINZ_RECORDINGID und MUSICBRAINZ_TRACKID?

Kann jemand bitte erklären, warum Mp3tag trotz

den Tag MUSICBRAINZ_TRACKID benutzt um eine UFID abzufüllen?

Gemäss Appendix B: Tag Mapping — MusicBrainz Picard v2.8.2 documentation
steht
MUSICBRAINZ_TRACKID für "TXXX:MusicBrainz Release Track Id"
und
MUSICBRAINZ_RECORDINGID für "UFID:http://musicbrainz.org"

Obwohl die MUSICBRAINZ_RECORDINGID (richtig abgefüllt mit einer UFID) wohl kaum je benutzt wird, müsste nach meiner Logik nach die MUSICBRAINZ_TRACKID den Inhalt eines TXXX-Frames bekommen.

Oder wäre logischer, wenn "MusicBrainz Track ID" neu zur MUSICBRAINZ_RELEASETRACKID würde?

Wie sehen das andere Mp3tag-User?
Was meint insbesondere @phw dazu?

Vielleicht verdeutlicht dieser Screenshot die Situation.
Man sieht die Metadaten, frisch mit der neusten Version MB Picard 2.8.2. abgefüllt.
Die MUSICBRAINZ_TRACKID wird in Mp3tag nicht mit dem korrekten Wert f8e2b554-3b86-3fe8-bc08-f3a5778f659a dargestellt, sondern mit der Picard "MusicBrainz Recording Id" 5e0aa7e4-01cb-441c-9fc2-d89e890cb981.

Auch die anderen MusicBrainz Tagnamen lauten nicht immer offensichtlich gleich. Gibt es dafür einen speziellen Grund?

Das ist die aktuell gültige Mapping-Tabelle von Picard/MusicBrainz:

Das braucht eine etwas umfangreichere Erklärung. Erstmal eins vorweg: Die internen Namen von Picard und MP3Tag sind ersteinmal wirklich nur Namen für die jeweilige Software. Und die müssen nicht übereinstimmen. Wichtig ist, welche Tags sie befüllen. Und damit haben wir folgendes Mapping:

Picard MP3Tag ID3 MP4 Vorbis
musicbrainz_recordingid MUSICBRAINZ_TRACKID UFID:http://musicbrainz.org ----:com.apple.iTunes:MusicBrainz Track Id MUSICBRAINZ_TRACKID
musicbrainz_trackid MUSICBRAINZ_RELEASETRACKID TXXX:MusicBrainz Release Track Id ----:com.apple.iTunes:MusicBrainz Release Track Id MUSICBRAINZ_RELEASETRACKID

Es gibt also ein einheitliches Mapping, nur die internen Namen sind etwas verwirrend und irgendwie verdreht. Das hat historische Gründe.

In grauer Vorzeit, als die Metadaten noch wild und chaotisch waren, hatte MusicBrainz noch ein vereinfachtes Schema: Es gab Releases, und Releases hatten Tracks. Ein Track hat eine MBID, die MusicBrainz Track ID. Erschien die selbe Aufnahme eines Songs auch auf einem anderen Release, so war das aber dennoch ein anderer Track, mit anderer ID. In Picard hieß das Tag musicbrainz_trackid, mit dem Mapping auf UFID und MUSICBRAINZ_TRACKID.

Dann kam 2011 das MusicBrainz NGS (Next Generation Scheme), das das Datenmodell grundlegend erweiterte (im wesentlichen ist es das Datenmodell, das auch heute noch existiert). Eine der Änderungen war, dass es nun das Konzept der Recordings gab. Ein Recording ist eine Aufnahme eines Musikstücks, und das gleiche Recording kann mit den Tracks von verschiedenen Releases verknüpft sein. Da es aber nicht zuverlässig möglich war, die existierenden Tracks automatisch in Recordings zu gruppieren, wurde bei der Migration zum NGS aus jedem ehemaligen Track ein Recording, wobei die IDs beibehalten wurden. D.h. aus den ehemaligen Track IDs wurden letztendlich Recording IDs. Wichtig: In diesem Modell gab es zunächst keine Track-IDs mehr!

In Picard hat sich aber zunächst nichts geändert. Intern hieß das Tag noch immer MUSICBRAINZ_TRACKID und wurde bei ID3 als UFID gespeichert. Das Mapping auf die Tags in den Formaten beizubehalten war wichtig, um bereits getaggte Dateien kompatibel zu halten. Schließlich waren die IDs ja nach wie vor gültig.

Dann führte MusicBrainz allerdings 2013 wieder Track IDs ein, d.h. ein ganz spezieller Track (z.B. Track 5) auf einem Release bekam einen festen Identifier, der unabhängig von dem mit dem Track verknüpften Recording ist.

Um dieses neue Track-Tag in den Dateien zu unterscheiden, wurde es ab Picard 1.3 in den Tags als TXXX:MusicBrainz Release Track Id bzw. MUSICBRAINZ_RELEASETRACKID gespeichert. Um zumindest innerhalb von Picard Namen zu verwenden, die dem Datenbankschema entsprachen, wurde die interne Bezeichnung für das alte musicbrainz_trackid auf musicbrainz_recordingid geändert. Außerdem wurde aber auch ein neues intern musicbrainz_trackid genanntes Tag eingeführt, dass dann auf TXXX:MusicBrainz Release Track Id bzw. MUSICBRAINZ_RELEASETRACKID gemappt wurde.

Vermutlich wäre es besser gewesen, hier stattdessen musicbrainz_releasetrackid zu verwenden, um die Verwirrung wenigstens etwas mehr in Grenzen zu halten :slight_smile:

Für MP3Tag kenne ich die Historie nicht so gut, kann daher nur vermuten. Aber es sieht so aus, als wäre MP3Tag einfach bei der Bezeichnung musicbrainz_trackid für das ursprüngliche Tag geblieben (pre-NGS "Track ID", danach "Recording ID"). Und die neuen Track IDs wurden dann intern als MUSICBRAINZ_RELEASETRACKID bezeichnet.

1 Like

@phw Vielen Dank für diese detaillierten und sehr aufschlussreichen Hintergrundinformationen! :+1:

1 Like