There are conflicting requirements between modeling music generally and providing simple programmatic interface for those who are ripping, making a file hierarchy, and “good enough” tagging.
Let me provide a concrete example. I’m using cyanrip to convert a 13 CD box set of Studio Ghibli music to flac and other formats. I don’t care the CDs came in a box set, as I wish to treat them as individual albums. I also want the tracks in English. I’ve taken to use pseudo-releases, and attaching the CD TOC so cyanrip works, and am annoyed the album art isn’t pulling (unless I violate style guide… tempting). For the rare case where I need to override things cyanrip provides serviceable coverage.
These needs are different from an ideally normalized set of tables. Expecting tools to manage schema migration is also problematic and will limit how fast you could iterate on the meta-data model. For example, decomposing track artists is probably not worth it for cyanrip to support.
Anyway, it may be more prudent to have a “good enough” model that simple tools could use; a 2nd pass with Picard could be used for more rule based bulk rewrites that preserve track identity.
It sounds like you are talking of the ripping \ tagging tool needing to read the database in a different way for a boxset.
As many boxsets in MB have a “includes” relationship listing the releases it contains, then you are part way there to having your favourite tagging tool being able to split a box.
It is not up to Musicbrainz to make a fake release to split the boxset. MusicBrainz documents what actually exists. It is up to your chosen tagging tool to do the choice of faking things.
Personally when I have a box like that I’ll manually do this and choose different releases that look good based on that includes relationship. I don’t need to make up fake pseudo releases to make that work.
I’m using cyanrip. The meta-data is used for file folders and basic tagging. This is needed as a precursor to using Picard to further characterize the media. What tools like this could use is a very simple interface from MusicBrainz that denormalizes much of the data model into something more easily coded and maintained. For example, it seems there is a recommendation to not attach CD information (which I understand as merely a hash of tracks and lengths?) to pseudo-releases. This is added complexity that cyanrip doesn’t have, nor should it need. If MusicBrainz keeps normalizing (a very good idea) via either data model or conventions, you could use a stable interface that CD archival/extraction tools could use.
You don’t have to use pseudo release but provide aliases to recordings. That will totally solve your problem as far as I can see, but you must use Picard 3.
Does Picard now provide for CD ripping to FLAC (archive) and other formats? I’m referring to tools that perform this function, such as cyanrip. It makes sense to me that Picard, being an integrated project, would have full knowledge and take advantage of the larger information model (and it’s complexities). I’m referring to a simple API for other tools that may not have the time luxury to fully understand all of the nuances and track changes of the model and conventions used over time.
One interesting perspective is to use ListenBrainz APIs for lookup. LB already has to solve the issue of matching track metadata to a single recording.
@rob and I had been experimenting with using LB APIs for Picard as well. It was all just experimental, but results where promising for the use case of looking up single tracks. I hope to get back to this once we have Picard 3 out of the door
