Hi y’all, I recently added a multi-lingual release (following the discussion at this thread as close as I could) and also added two pseudo-releases for the two languages represented (English and Chinese).
I know the Disc ID should be added to the official release. My question is, should the Disc ID be added to the pseudo-releases as well? I’m thinking of a use where someone pops their CD into Picard and wants to name their tracks according to one of the pseudo-releases, rather than the official.
I did add the Disc ID to the pseudo-releases, but then wondered if that was the right thing to do afterward. I’m 100% willing to remove the association depending on what y’all think.
Here are the links to the specific things I created:
The doc says no: https://wiki.musicbrainz.org/Style/Specific_types_of_releases/Pseudo-Releases
This guidance is incompatible with use of tools that currently support MusicBrainz.
Pseudo-releases are the primary way you translate track titles. Tools won’t find the pseudo-releases unless the diskid is attached. Therefore, it makes sense, at least till this is resolved (it’s easy enough to strip them programmatically later) to add diskids to pseudo-releases. Generally, I think diskid could be thought of more broadly, as a specification of number of tracks and times for those tracks. In this regard, one should be able to also attach them to digital releases.
I think there are several classes of tools. It makes sense to me that Picard is very aware of and closely tracks the MusicBrainz meta-model. However, there are ripping tools for archival as well as transcoding tools. I don’t see that Picard covers these uses. For these tools to digest all of the Music Brainz data model and conventions for using it seems like a heavy lift. It’d be better if there was a simplified interface for these “upstream” tools to use. Picard could then be used downstream to manipulate the music archive.
This is, at best, a partial solution. The challenge from an archival program is making sure the track lengths are aligned to prevent error. Really, the simplest solution is to let the CD specification (ie, hash of track lengths) to be associated with both pseudo releases and digital releases, or better yet, the underlying media, as it’s really not a “release” administrative properly but one that directly refers to the shape of the media (regardless of it’s origin).
Surely an archival tool should use the correct titles? And then if the user wants to use alternate title swapping to Picard to select those different titles makes sense.
No point in changing the core database that represents the core facts. It is down to the later tools to manipulate the data if the user wants it in a non-standard state.