# Logik hinter MUSICBRAINZ\_RECORDINGID und MUSICBRAINZ\_TRACKID?
**URL:** https://community.mp3tag.de/t/logik-hinter-musicbrainz-recordingid-und-musicbrainz-trackid/58074
**Category:** Allgemein
**Created:** [August 1, 2022, 1:06pm UTC](https://community.mp3tag.de/t/logik-hinter-musicbrainz-recordingid-und-musicbrainz-trackid/58074 "2022-08-01T13:06:39Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [August 1, 2022, 1:06pm UTC](https://community.mp3tag.de/t/logik-hinter-musicbrainz-recordingid-und-musicbrainz-trackid/58074/1 "2022-08-01T13:06:39Z")
Kann jemand bitte erklären, warum Mp3tag trotz
> [@MusicBrainz Recording IDs erroneously written to MusicBrainz Track IDs](https://community.mp3tag.de/t/musicbrainz-recording-ids-erroneously-written-to-musicbrainz-track-ids/44233):
>
> Likely not a bug, see edit below. Hello, When using the MusicBrainz Tag Sources option, after selecting a result and clicking Next, the list of IDs shown on the left panel are all Recording IDs not Track IDs as the column header states (bug1). I'm not sure which ID type is meant to be displayed next to each song on the left, but for certain, those IDs aren't Track IDs. When saving these suggested tags, these Recording IDs are mistakenly being written to MUSICBRAINZ\_TRACKID instead of MUSICBRA…
den Tag MUSICBRAINZ\_TRACKID benutzt um eine UFID abzufüllen?
Gemäss [Appendix B: Tag Mapping — MusicBrainz Picard v2.10 documentation](https://picard-docs.musicbrainz.org/en/appendices/tag_mapping.html#id24)
steht
MUSICBRAINZ\_TRACKID für "TXXX:MusicBrainz Release Track Id"
und
[MUSICBRAINZ\_RECORDINGID](https://picard-docs.musicbrainz.org/en/appendices/tag_mapping.html#id21) für "UFID:[http://musicbrainz.org](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?
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [August 2, 2022, 9:02am UTC](https://community.mp3tag.de/t/logik-hinter-musicbrainz-recordingid-und-musicbrainz-trackid/58074/2 "2022-08-02T09:02:57Z")
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](https://picard-docs.musicbrainz.org/downloads/MusicBrainz_Picard_Tag_Map.html) von Picard/MusicBrainz:
---
### Author:  [@phw](https://community.mp3tag.de/u/phw)
#### Post date: [August 2, 2022, 2:43pm UTC](https://community.mp3tag.de/t/logik-hinter-musicbrainz-recordingid-und-musicbrainz-trackid/58074/3 "2022-08-02T14:43:29Z")
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](https://wiki.musicbrainz.org/History:Next_Generation_Schema) (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 🙂
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.
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [August 2, 2022, 2:58pm UTC](https://community.mp3tag.de/t/logik-hinter-musicbrainz-recordingid-und-musicbrainz-trackid/58074/4 "2022-08-02T14:58:30Z")
@phw Vielen Dank für diese detaillierten und sehr aufschlussreichen Hintergrundinformationen! 👍
---
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [October 5, 2022, 10:30am UTC](https://community.mp3tag.de/t/logik-hinter-musicbrainz-recordingid-und-musicbrainz-trackid/58074/5 "2022-10-05T10:30:23Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.