What does musicbrainz_trackid signify?

[outsidecontext]

@audiomuze

The ‘Internal Name’ provided in the link you referenced - that pertain to the musicbrainz database schema or some Picard internal?

It’s how Picard names this tag. You use that name for example in scripting (by using the %musicbrainz_recordingid variable) or when manually adding a new tag.

@audiomuze

musicbrainz_workid - does it relate to all compositions or supposed to be classical only?

In general all recordings can have works. E.g. look at the work for Bob Dylan’s All Along the Watchtower. If a recording is linked to a work Picard will add the work ID to the tags by default. It also stores the work name.

There is some debate around this as some users would only like to store the work name in the tags for classical music. The “Work & Movement” plugin will hence clear the work related tags for works it does not consider works consisting of multiple parts, as it is typical for classical.

@audiomuze

MUSICBRAINZ_TRACKID vs MUSICBRAINZ_RELEASETRACKID - what’s the distinction between the two?

MUSICBRAINZ_TRACKID is the recording ID. MUSICBRAINZ_RELEASETRACKID is an ID for a specific track on a release. I once even saw a rare case where the same recording was included twice on a release (it was some multi-disc release). Both tracks would then have the same recording ID, but different track IDs.

@audiomuze

And if WORKID is how compositions should be identified why does Picard not write it for popular music? Here’s a freshly tagged file from Fleetwood Mac - Rumours:

It does unless you have configured it not to do so, e.g. by unsetting the work tags with scripting or using the “Work & Movement” plugin.

@audiomuze

• MUSICBRAINZ_TRACKID maps internally to musicbrainz_recordingid; MUSICBRAINZ_RELEASETRACKID maps internally to musicbrainz_trackid. Could it be any more confusing?

Hardly It has some history, though. I wrote a longer explanation (in German) on the MP3Tag forums, here is an automatic translation of the entire thing:

This needs a bit more explanation. First of all: The internal names of Picard and MP3Tag are really only names for the respective software. And they don’t have to match. The important thing is, which tags they fill. And so we have the following 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

So there is a consistent mapping, only the internal names are a bit confusing and somehow twisted. This has historical reasons.

In the distant past, when metadata was wild and chaotic, MusicBrainz had a simplified scheme: there were Releases, and Releases had Tracks. A track had an MBID, the MusicBrainz Track ID. If the same recording of a song appeared on another release, it was still a different track, with a different ID. In Picard, the tag was called musicbrainz_trackid, with the mapping to UFID and MUSICBRAINZ_TRACKID.

Then in 2011 came the MusicBrainz NGS (Next Generation Scheme), which fundamentally expanded the data model (essentially, it is the data model that still exists today). One of the changes was that there was now the concept of Recordings. A Recording is a recording of a piece of music, and the same Recording can be linked to tracks from different releases. However, since it was not reliably possible to automatically group the existing tracks into Recordings, when migrating to the NGS, each former Track became a Recording, while keeping the IDs. I.e. the former track IDs eventually became recording IDs. Important: In this model there were initially no more Track IDs!

In Picard, however, nothing changed at first. Internally the tag was still called MUSICBRAINZ_TRACKID and was stored in ID3 as UFID. Keeping the mapping to the tags in the formats was important to keep already tagged files compatible. After all, the IDs were still valid.

However, MusicBrainz then reintroduced track IDs in 2013, meaning that a very specific track (e.g. track 5) on a release got a fixed identifier that was independent of the recording associated with the track.

To distinguish this new track tag in the files, it was stored in the tags as TXXX:MusicBrainz Release Track Id or MUSICBRAINZ_RELEASETRACKID as of Picard 1.3. In order to at least use names within Picard that were consistent with the database schema, the internal name for the old musicbrainz_trackid was changed to musicbrainz_recordingid. However, a new tag internally called musicbrainz_trackid was also introduced, which was then mapped to TXXX:MusicBrainz Release Track Id or MUSICBRAINZ_RELEASETRACKID.

Probably it would have been better to use musicbrainz_releasetrackid here instead, to keep the confusion at least a bit more in check

For MP3Tag I don’t know the history that well, so I can only guess. But it looks like MP3Tag just stayed with the name musicbrainz_trackid for the original tag (pre-NGS “Track ID”, afterwards “Recording ID”). And the new track IDs were then internally named MUSICBRAINZ_RELEASETRACKID.