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 
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.
