I recently bought a box set of Rick Wakeman albums (just plugging age-old holes in my CD collection). I was initially pleased to discover that my first discid matched and that someone had got here first and done all the hard-work. 5 Classic Albums release group
I then realised that Picard was going to create tags with the album title “5 Classic Tracks” on all titles - This seems wrong, but that’s because box-sets come in different styles and MB is (apparently) only modelling multi-disc albums, but I wondered if the way that the data had been entered was “missing a trick”.
Having done my best to search this topic I’ve seen references back in 2016 to the idea of developing a release-group type of “box-set”. It looked like it was in the pipeline. I’ve been experimenting with adding a new release-group and I can see no mention of box-sets.
Along the way I saw some other examples and realised that some people were adding the relationship for “includes/include in”, so I’ve added those relationships to the existing entry.
Look carefully at the uploaded coverart for that release, you can see that each of the 5 discs is in a card sleeve printed with the original album’s front/back. They each have a distinct catalog number on the back (in a series of 5 consecutive numbers). The media labels also feature this catalog#.
I feel that I could enter each disk separately as 2016 releases on the budget “Spectrum Music” label, give each release the same barcode as shown on the box and their own catalog numbers. In each annotation I could say part of the box-set release-group “5 Classic Albums” and use the “included in” relationship.
This feels like I would be doing something very wrong because I’m adding duplication into the database but the alternative, the status quo, is that we drop vital information on the floor when we tag. What was the original year and album for “Catherine of Aragon”? It certainly wasn’t 2016 on “5 Classic Albums”. This doesn’t lend itself to an album-level “play-all” in our music players or searching your archive for “six wives”.
I thought about adjusting my Picard scripts to favour the media title over the release title, but that doesn’t solve the fact that the original year/date has dropped through the cracks. Clearly we can’t have a one-to-many relationship between the existing release-group and original date, so what can be done?
I think we need a model which models box-set-of-albums as a release-group which has member release-groups.
So have I missed a trick?
In the meantime I’ve tagged the rips with bogus releases to get useful tags.
Hi Robin. 1st, nice research on your topic. Several of us would like a consensus on this subject. I can’t offer more than my opinion. When faced with this I often create a series which isn’t correct but it works. I always add some type of comment. Let’s hope for some input. It would be cool if there was a check box for series, set of, box set, etc. that once checked would make it easier for submission.
A series is not correct for a box that you get all at once.
Until we get a specific release group type (I am not even sure we really need anthology or box set, any more) I think it is just a multi disc release in a compilation album release group.
Sorry if I missed the point, the OP was quite long for me.
Totally agree that it would be nice to see some kind of solution to this. Even something simple like a flag to set to state it is a box set so it can be better handled outside of the database.
I have a Pink Floyd discovery box with about 18 discs in it. Looks especially daft. Similar with a Bowie box of all his works. Gets a bit messy to work with in a media centre when you want to just select a single album to play.
In the above case all of the releases are also separately listed in MB as separate releases. So sometimes you get discID matches that way instead. And, of course, that leads to people trying to subvert the data in MB.
It would also be good to get some thought on official way of handling the extra discs in Deluxe sets. These 25th Anniversary releases like the White Album where those extra disks have their own important separate titles. Though reality is you are more likely to want to put on the original album than listen to all of the disks.
@Llama_lover Indeed, for the moment I can see that the person who submitted the set did a good job with the scans. I don’t feel it would be polite to set up an alternative without there being some sort of resolution in here which said “that’s the best way to go”
jesus2000
Sorry about that. I’m new and wanted to describe what I found and what I had tried - in case I had missed something. I also like to lay out my case as best I can
I hoped I had explained why the outcome of the current model was not right IMHO for cases where the purchase is a wrapped collection of albums. Please go and visit the link to the set-of-albums. You will see that the front+back artwork is the same as the originals (going back to vinyl) - Indeed, the “White Rock” back still refers to “SIDE ONE” and “SIDE TWO”! The discs have the same tracks, in the same order. It is not a new collection of tracks across 5 disks, it is a collection of 5 albums.
It’s not a set of tracks in a multi-disk compilation, like thousands of new “best of” release
There is no deviation from the original contents, no bonus tracks. The true “original dates” are from 1973-1977, but treating them as 5 disks in a release-group means all tracks share a common “original date” of 2016. This is completely mis-representing the work!
I would argue that the lack of grouping of tracks is also a failure. It isn’t good enough to say that “some of these tracks were originally from…”
If that means that “Anne Boleyn” is tagged and filed as a track within an album called “The Six Wives of Henry VIII” and the original release date of that work was 1973, not 2016 then I’d be very happy.
Final tongue-in-cheek example: If you buy 15 discs from Amazon and they arrive in the standard brown Amazon box, do you throw away the jewel cases and sleeves and store the discs in the brown box? Because that is the metadata equivalent of what Musicbrainz/Picard does for the case of a collected set of albums marketed together.
I also have a few boxes like that. Just the original albums stuffed in a new wrapper with all the separate barcodes still accessible.
This is still manufactured in one go, so the release date should still be the date of the boxset. There just needs to be a clearer way of making sure the links to the original release dates of each separate disc can be brought up to. (Just like with a normal re-release)
The “Two albums on one CD” example is a common problem I come accross. In the same way we can lable a disc it would be handy to label parts of a disc. But this is a harder thing to work out.
This is a common problem, not specific to box sets. (Also, I’m not sure you’re using “work” in the way that we understand works in MusicBrainz terminology, do you mean recordings maybe?)
You may want to look into solutions proposed in threads like these to get the desired behaviour (from Picard at least):
Those are not really equivalent at all. You can buy a single boxset containing 15 albums or you can buy those 15 albums individually, they’d still arrive in an (additional) brown Amazon box, but they’d be 1 single item vs. 15 separate items in Amazon’s storefront, which is the data we’re mirroring here: 1 single item (1 release in 1 release-group) vs. 15 separate items (15 releases in 15 different release-groups).
Indeed. I can’t see how it should be handled without becoming quite tortuous. I now look on that purchase and think “more fool me”. I should have bought a basic “There’s the Rub”, which was all I was looking for. I just thought getting more was a bonus and the single album wasn’t on the shop’s shelf. Buying practice distorted to suit the side-effects of tagging… it’s not ideal is it?
I was the one who added those relationships to that Wakeman set of 5 albums, but adding the relationship there doesn’t solve the problem of getting a more meaningful original date and “original album” for that disk medium.
At the moment that “includes” is just a relationship from the group level to group level. If the link were not the vague link “includes”, but instead were a more specific “is a member of” at the track or disk level, then we would have the model to allow a whole disk of tracks to “be” a particular album/release-group, or we could even associate the individual tracks with their parent release group (allowing the case of two old albums being released as a new two-in-one or n-in-one release).
I’m not a digital-release user, but isn’t the “n-in-1” case something of a problem for digital releases?
Since recordings (can) exist on multiple mediums (and thus releases), it is possible to look at a recording and find the earliest release’s release date. This is what the Picard and beets plugins linked to in the topics I linked you earlier attempt to do.
At first I thought you were probably right (as a newbie I might not be too precise with my terms, but I try) Having reviewed the links to “work” and “recording” I do think I meant “work”.
Specifically I would point to the description of: Aggregate works An ordered sequence of one or more songs, numbers or movements, such as: symphony, opera, theatre work, concerto, and concept album. A popular music album is not considered a distinct aggregate work unless it is evident that such an album was written with intent to have a specifically ordered sequence of related songs (i.e. a “concept album”).
Is there much doubt that certain albums were the final product of some months or years of energy (avoiding the word work!) to make something with a pre-ordained structure, transitions between tracks etc. It was that work-of-art which came out, not a collection of tracks to be played on shuffle.
The MB definition of recording suits the need to apportion artists and credits at a level of granularity that matches the public record i.e. we tend to get to know who did what on what song/track/recording. It is rare for credits to specify to finer granularity (e.g. the sax in the middle-eight was x). A “recording” also works correctly for the data - to be the leaf-node - for tracks on different releases to point back to, regardless of additional fader and EQ tweaks in the passage of time.
From what I’ve read, it was the case that in the early days MB only modeled one disc per album and so had sets, but it (sensibly) adapted to the market and then modeled multi-disc albums. I’m saying that the release-group does not model correctly for a certain (fairly common) pattern and jumping through hoops to get around that doesn’t seem to be the right architectural approach… But I am going to read through the “workarounds” to see if they can solve the problem. On the swiftest of looks I think the original date is the most fragile to get right. e.g. If any of these boxed sets of albums had tracks which were released earlier as singles I can see “workarounds” going wrong.
The RG-RG relationship is good as far as it goes. If a user were to have a mechanism for building a “Set-Of-Albums” the starting point would be to add each RG which is “included-by” this RG-Set. When they add a medium they can pick from that list of included RG, perhaps that is called the “is from” list. You could allow the same assignment at the track level, to cope with the cases of two traditional albums squeezed onto a CD or other optical media. Doesn’t that also help with grouping digital releases? Either way you have the idea that a track “is from” a particular album at a particular date in history. The model might be down to each track and it might be just a UI convenience that applying a parent RG to the medium is actually applying the data to the tracks. Similar to how we have track-artist vs album-artist in ID3 you would have a sort of track-album which might be different and more specific than the release-group.
The “album” was surely a structure (avoiding the word work) created by the artists, the box set is more the product of a sales team. It seems that by maintaining a strong link to the packaging and a weak link to the “work” Musicbrainz is prioritising marketing over the creatives.
Does that seem fair at all?
I point to my “use case” scenario where the pre-condition is this: there was a single which came out before the album, which was bundled into a Amazon-special box-set 3 decades later. As a user, when tracks are playing which come from that album, within that marketing bundle, I want to see the name of that album and the date-of-original-album-release. I expect all of the tracks to have the same date because the entity which I have chosen to play is the album.
NB If I had ripped and was tagging the single track I might have chosen the tag source as the single or album. When played in isolation the single date would be acceptable (if that was chosen at tag-time)
What must not happen is that one track has an earlier derived original-date (because of the single) or, worse still, the entire set of tracks drops back to that earlier date!
Worst case scenario: Single released in December 1980, album in February 1981.
I want my FLAC storage path and ID3 to contain the 1981 date and the album’s title for all of the tracks.
Approaches where a plugin tries to walk back through the tree to the earliest recording or release date seem a bit “fragile”.
Here’s my experience over the years with MB Robin, you may find it helpful:
MB has a very long view of things, and to make it effective in the long term it is focused on being primarily a strong database. In this particular case, for instance, I agree that it is extremely unhelpful to have your albums tagged as a box set. However as a database it is incorrect to duplicate these releases as separate releases, or to split it up: they were released all together, on the same date, in a box set. It’s unlikely, no matter the reasoning, that MB’s powers that be (the users, more or less) will compromise the database to make the tagging better right now. The trackset update will come eventually, and then relationships using them, and then Picard updates, and then this will probably be ticked off. But quite frankly that’s going to be a while™.
You obviously care about your metadata a lot, as does everyone here, so please don’t get discouraged! Maybe there is a way that can be pushed through now. But you may find you are pushing against a brick wall. And although I was resilient, I eventually came round to MB’s thinking on pretty much everything btw - although I don’t know if that’s encouraging for you!
If you want to consider the different discs from your box set release to be some other release(s), I’d just pull in that other release into Picard if I were you and tag your files against that. It’s objectively not the same release, but you seem to want the data to say/pretend that it is, so that would be the way to do that in the current (and foreseeable future) state of things.
@aerozol Yeah, I understand that it takes a long time to mull over a suggested change. I wouldn’t have expected anything soon and it would have been a miracle if someone new came up with the “right” way! I accept that tweaking any data model is a dangerous exercise and you risk just muddying the water somewhere else. Devs are likely to wrangle for ages on the “right” way.
I mainly wanted to stick to my guns that I don’t think it’s “an error of judgement” to want the outcome of tagging a “set-of-albums” to be a large and disparate set of tracks which have lost their significant creative album title and date of original release.
I agree with @Freso that the line-of-least-resistance for me is to pull in the release which gives me what I want in terms of tag outcome.
Actually I wasn’t advocating separate releases. I was advocating creating a relationship to the parent release-group, possibly at the track level, or possibly at the disc level. The release group doesn’t say anything about barcodes or packaging, that would properly go in the release of the set, the entity which you buy. The RG representing the new set-of-discs would start with a singular release representing the actual first release of the set-of-disks, obv. That would have all the artwork, media details etc. So there would be no need to create new standalone releases but the UI would have to provide for the user to link tracks to the original-album RG. If the user has first used the existing “includes” properly, then the UI already knows the small subset of album RGs from which the user will be selecting when they are setting the original-album for each track of the new n*album release.
Somewhere earlier the idea was discussed of creating 5x new releases annotated to say not available separately but part of a set - but that most definitely would be duplication of release data. Tagging to imperfect releases is the better workaround I think. Perhaps the idea of optionally assigning the tracks to parent RG makes it easier to see an upgrade path where we can re-visit the “5 Classic Albums” style of entry and retrofit the missing relationship to original album.
