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
We’re perhaps missing a concept of “Album”, which is a sequence of N recordings. Those recordings could be physically encoded as 3 CD media.
However, a “Box Set” is more of a bundle. It’s not an album. It’s recordings are not sequenced. Boxed sets are often collected works, pulling together N previously released titles into a single bundle. When I’m trying to find music, I’m not interested in the bundle, I’m interested in the underlying releases. Given that album and release are synonymous, I find the “box set” as a release to be very unhelpful. A “Complete Mozart Operas by Solti” box set is a multi-album distribution.
Personally, I’d even rather see an opera and musical sound tracks as a single recording, with old-school indexing so you could jump though it. Alas it seems the standards don’t use indexing, which was an excellent 80s era concept that scaled well to opera, musicals, and movie soundtracks (including dialogue).
MB is generally built around the media. A CD has tracks on a table of contents, and the CD Medium is split by these tracks, so if there are 14 tracks on the CD TOC then there are 14 tracks on the Medium on the Release in MB.
Similar follows if a Digital Store sells you an album as 14 FLAC files, or 14 streamed files. Then the track list is 14 tracks on that medium.
You are now reimagining the item that is on the medium. Yes indexing was an interesting idea that didn’t catch on, but MB was not built around it. MB represents the media, not how you hear them.
Yep. A bundle of separate albums. Or albums and bonus items. Media centres try and break these up again in different ways. I believe this is the area you’d have some of your requests answered. It is not about how the digital files are tagged, it is about how they are then accessed.
I have various media centre apps that do a variable job in separating the parts back out. Often when listening to the album I want just the CD with the original album on and not those bonus parts. This is where the Media Centre software ability to manipulate the data comes through.
Same with your Mozart boxset. Picard tags as the CDs are - part of a box. But your Media Centre app can select that specific performance for you from that boxset.
It is not really Picard’s need to do this separation. Picard tags as the item physically exists. It is the playback software that can then choose how to represent this. Just the same as me the human choosing to only put on CD1 of the set and leave that bonus CD2 in the box.
@IvanDobsky Thank you. It’s hard to model things to cover so many use cases. I do see a difference between a performance being broken into multiple media/recordings, vs a compilation of performances potentially included in subsequent recordings on a single media. The box set or bonus tracks are more about distributions than performances…
I think this packaging/distribution vs performance/segments is a fundamental distinction that MusicBrainz conflates and could really use some rethinking for the next major release.
I believe this is more a media centre issue. If your tags have all the data about a performance, then a good media centre should then be able to select your music in the way that you personally see your music. (Even better if the media centre directly feeds from the MusicBrainz database)
But also I realise you are talking Classical and that is a world that utterly confuses me on MB. One of the things that I know is coming is the ability to add different types of track lists to the same release. I personally get confused when a solo sax player will have their Artist credits removed from a track list and replaced with Composer names because they played two Mozart pieces in the middle of a dozen pop songs.
As a half way hack there are plugins for Picard that will manipulate the credits for a classical album. Swapping performers and composers around as required to best fit your needs.
Essentially resolving artist name + track title to the proper recording. That’s the challenge ListenBrainz faces. The user expects the proper recording to be mapped. The new mapper was giving promising results, an improvement over the current LB mapper.
And this is also interesting for a tagger like Picard. For full release lookups Picard already does a good job, but one of the week points is looking up a collection of single tracks. Mapping these with only using the MB API is difficult, and often the match goes to some compilation release. I think the LB mapper could help here.
