Digital releases

This is all a little bit complicated for my simple mind. I know that MB’s objective is to be an authoritative database, but it depends on volunteers to maintain it, so it also needs to be sufficiently ‘easy to edit’ to encourage the addition and improvement of data.

If anything, there should be an emphasis on reducing the number of releases in the case where releases share the same recording details (which I think is at least part of the thinking behind the previous post). Is there any mileage in having ‘variants’ of a release for certain characteristics? The tracklist/recordings would be ‘shared’ (i.e. only need to be entered/updated once) and the ‘variant’ data would only specify differences from the ‘primary’ release - e.g. cover art, media, packaging, etc. Possibly, even ‘bonus tracks’ on certain media (e.g. I have some downloaded albums which have bonus tracks not on the original CD) could be dealt with as variations rather than by creating a new release record.

I appreciate that this suggestion is a database structure issue rather than a ‘style’ matter, but as things stand, the risk is of ever-expanding ‘similar’ releases as the media possibilities widen. I also appreciate that the ramifications of this suggestion would need careful examination; in particular, how it fits with the present concept of ‘release groups’. An example: I have 2 CDS that, shortly after release, were re-released as a double CD with different cover art. The recordings and track details are identical, but MB has 2 release groups and 3 releases each of which can be independently edited. (I appreciate that this is not a ‘digital’ example, but it could easily be).


100 % agreed

Yes, that is one area where the situation is IMHO similar to the details of audio formats: It is a detail I definitely want to record, but it often feels wrong to duplicate all other data just to get this detail right. So my personal current approach is to add only one variant to the database and add the info in the annotation that there are more available (and leave it to others to actually add the variants as releases if they want to).

Yes, that would be cool and could handle many cases and simplify things greatly.


We’ll discuss about such possibility on next IRC meeting, i already asked @bitmap if it is technically possible, it happens we have something similar already existing for alternative tracklists. Whatever is decided, it will not happen before next schema change.


Anyone is welcome to put agenda items for a meeting, see MetaBrainz Meeting - MusicBrainz for details. Note that neither @Rob nor I are in a position where we can give a “pronouncement” on this. MusicBrainz is a community project, @Rob and I are both “slaves” to the community’s wants and needs. If anyone would have a “pronouncement”, it might be @reosarevok as the STYLE leader, but even then, he also acts on community input/feedback and tries to achieve consensus before acting on things.

What I can say, which you will likely also be able to read from the discussions you’ve linked yourself, is that we do want better ways to deal with digital music, but until we know what those ways are, we are unable to implement them. Discussions like the one here are how we figure out what needs to be changed in MusicBrainz to better support the 21st century music landscape.


This would be a great feature to have for recordings as well as releases. Various edits, mixes, etc. could share a common source recording (performers, recording date/place/engineer, etc.) and the variants would only carry the unique data (remix engineer, etc.)

1 Like

Wouldn’t this variant stuff just add another layer of complexity? Right now it is still relatively simple what a new release is: if it looks different (different cover art, different looking medium, etc) it is a different release. Now it would be “if it looks different, it is a different release unless the difference is vinyl colour, because then it is a variant of the same release.” Can’t we just create better tools for duplicating releases instead?

1 Like

Yes, we can, but it would’nt solve much.

Actually extra duplication of data is an issue, making things hard to maintain.
We don’t have any alternative to duplication at the moment.

What do you mean by " better tools for duplicating releases" ? We have a very good userscript for that (konami-command/ at master · jesus2099/konami-command · GitHub). Not sure how you think you can improve it, but it would be interesting to share your ideas.

That’s an interesting point.


Sorry I’m so late, haven’t (and still don’t) had home internet for a while.
As someone who finds the tracking of different digital releases interesting and important information, this is an important subject for me, and one I’ve unsuccessfuly tried to bring into discussion a few times in the past.

After reading everything I would like to make a few points from my perspective.

  1. If MusicBrainz wants to be the “ultimate source of music information”, and doesn’t allow detailed information on various digital releases, it’s failed on that front. In reality the goal should be changed to the “ultimate source of physical release music information”. I think it’s clear that a 162kb MP3 can be very different to a FLAC file, and indeed much more so than many physical reissues, regardless of your interest in digital.

  2. This has been broached a few times and discussion has gotten nowhere. I do actually think an official call has to be made (@Freso, @rob, @reosarevok, sorry for the tags!). Adding detailed digital releases and having to watch them in case they get merged/just having them be merged later is a massive waste of everyones time. It needs a call - digital releases that have differences, and not just the ‘different cover art’ loophole that’s the only applicable mention in the style guidelines at the moment, can be added, or they can’t. Hammering out details can always happen later.

  3. I am not a fan of the variant idea as a solution to this digital release problem. I think it’s definitely interesting, and if the UI can be wrangled that’s great, but it just delays being able to consistently add data (or not add data) across the board while we wait for updates that may take a long time, or never happen. It’s may eventually be an amazing solution to data duplication across the board. But I also think MB’s complexity is a far larger problem than having too many releases*… which brings me to

  4. All I hear from the nay-sayers is variations on “I don’t consider digital releases important”. I don’t care about classical music releases, which are a massive source of complexity in MB, but that’s not a good reason not to store the information. The only other argument against is some version of a release group that I hear is that we will start having “too many” releases. How is this actually a problem? Has anyone really gone to a release page and thought “wow there’s like twice as many releases here as on Discogs, that’s annoying, I’ll go use a database with less information instead”? With good data and clear annotations I think this is a non-issue, and simply one of the only plausible sounding arguments available against, with no practical application. Multiple coloured vinyl has been brought up as an example here, and again, this is something I’ve never had a practical problem with. It allows for pictures that correspond to the exact release, linking to shopfronts that may only stock that version, adding the exact version I own to my collection, etc. And it has not caused me issues browsing a release group.
    A small note: I have actually had trouble browsing long Discogs lists, with the lack of disambiguation there. I have not had the issue on MB, or have been able to fix it with a merge or a disambiguation.

So, mr Ranty-pants, any solutions?

  1. Since all I can really gather is that some pople don’t like digital releases/‘clutter’, I suppose having better filters that let you hide or show, or sort by, medium would solve that problem. Even just seperating out digital and physical into two sections, digital below physical. I guess my point is that there are very simple solutions available without limiting the scope of MB.

*understatement of the year :medal_sports:


I’m not sure to understand here, a MP3 file is indeed different from a FLAC file, but how does this impact associated metadata if they share everything but the digital audio file format ?

I think it is good to be able to store informations related to which formats a release is available in, but i think it is very bad to duplicate data without good reasons to do it.

Also if i take a random Bandcamp album page, with 3 vinyls in different colors, 1 CD, 1 cassette, and digital (available, at least, in FLAC, ALAC, AAC, Ogg Vorbis, WAV, AIFF, MP3), if we go the duplication way, creating one release for each, it means 3 + 1 + 1 + 7 = 12 releases, sharing more or less the same data.
If we go the variant way, it would be vinyl 1 (with 3 variants), 1 for CD, 1 for cassette, 1 for digital (with 7 variants) = 4 releases.
Since, currently, i hardly see all releases from this random Bandcamp page added to MB (usually digital, sometimes one vinyl, and the CD, when lucky), i don’t see how we could even reach completeness with 12 … Example: Devil Electric | Devil Electric vs Release group “Devil Electric” by Devil Electric - MusicBrainz

When i compare with Discogs, we aren’t even near being the “ultimate source of physical release music information”, most of the time, for physical releases, Discogs has almost all, when we have almost none…
(example: french punk band from nineties i edited today, compare with Release group “Raymonde et les Blancs Becs” by Raymonde et les Blanc Becs - MusicBrainz)

Don’t get me wrong, i consider digital releases very important (especially since physical are disappearing slowly), and i’d like we have a way to provide full information about them, but i don’t think we need to duplicate data if we can avoid it, especially when we are not currently able to have all recent releases on one album in the DB (i don’t even consider reissues etc…).

I fear going the way you propose will just lead to very incomplete and/or buggy data… because i doubt anyone will either fix the ALAC release when one will spot an error in the FLAC release… It is already the case with physical releases (CD is entered, cloned to create the vinyl, with an error in the tracklist, later the CD tracklist is fixed, but no one takes care of the vinyl tracklist, the error remains…).

When we code we try to reduce code redundancy because on the long term it is much easier to maintain, data is no different imho.


I am not advocating this at all. We don’t currently stop anyone from adding every format available from a single storefront (another reason why having no guidelines is not a great idea), but I haven’t seen it being an issue, because as you say, there has to be a good reason to add multiple releases, and this isn’t one.
However buying an album on Bandcamp is different to buying a bad rip from Amazon. You are buying a very different product (again, even moreso than a lot of CD reissues), and we should be able to differentiate the two.

To clarify: I think allowing (but not requiring!) a new release for a specific purchase would be a good rule of thumb. Just like we would do with a box set, we don’t add the seperate CDs - you purchase all formats together on Bandcamp.

When I stopped adding HumbleBundle digital releases a little while back, because they looked like they were all eventually going to merged (even though they’re well disambiguated, contain complete data, and caused nobody any practical issues whatsoever), I didn’t spend that same time adding physical releases that I didn’t have instead. I went to work, read books, played video games, and daydreamed about the database where I could find out or add what storefront contained what tracks and in what format so I could tidy up my messy files.
Stopping people from adding the data they’re interested in doesn’t meant they’re going to spent more time on the data you’re interested in.

If the argument is that allowing more data means the potential for more buggy or incorrect data, you are correct, but in that case you may as well advocate for removing all hgh level data from MusicBrainz.
And if you could hide digital releases you weren’t interested why would that even bother you? I definitely prefer some bad data instead of no data, and MB’s move towards more autoedits mirrors that idea.

I don’t think that’s the claim here :slight_smile: The idea was that if I make a typo, and then the typo is expanded to 20 releases, who is going to fix all 20 one by one?

Of course, the answer isn’t necessarily “don’t add 20 releases”, but “make fixing things easier” :slight_smile: But it’s the opposite of most of our high level data, which we try to avoid having to duplicate (see: reusable recordings, works). Hence why something like the “variants” idea (as in, one tracklist, several releases on top) might make sense. Funnily, that sounds pretty much like pre-NGS MusicBrainz :smiley: (although, to be fair, this would still separate “full” releases much more than old MB did).


yes, IMO Bandcamp is a FLAC release as it relates to digital. Their online converter can convert it for you into any of their supported formats if you choose.

You’re probably right, but it’s a pretty damn hard call to make. I’m still not 100% sure what the proposals are, honestly. I do see the point that we’d want to differentiate a badly made digital release from a good one, but:

Does this mean you’d have one release for iTunes and one for Amazon and one for CDBaby and one for Bandcamp and one for the Spotify stream and one for the Tidal stream and who knows how many more, or am I misunderstanding the idea?

If so, that does sound like a bit of overkill for a complete duplicate (for the data we store anyway) with a different store link, which makes something like the “variants” idea seem tempting. Right now, we would need a userscript to even be able to do this cloning without having to re-enter half of the data and get angry at the world for it :confused:

If the idea is to differentiate digital releases that are audibly different, that sounds at the same time more directly important and even more confusing to determine.

Don’t get me wrong, I am not saying the answer is not to store this info either, just trying to figure out how.


Really all I was saying is that an example like ‘10 releases for every bandcamp release’ is hyperbole. I don’t think anyone is advocating for that.

In my personal opinion you would make a new release if there is a difference that you want to store. This can be format, label, cover art, notably different credits etc.
Just like with adding a new release for a different CD matrix, you would not HAVE to, and I would not expect it to even happen often, but we should be ALLOWED to if we do it properly.

Variants is a whole different can of worms. If someone can figure out how to implement it that’s great. I see the value in not duplicating data, and it affects almost everything in the database. The issues I can see with it are probably for another thread.

IMO, I look at a stream as a stream. But I need to admit I have a bias opinion as I do not really even consider it a release in the first place. But I see the counter side where it is released, as in you as the end user are able to hear and experience it, so that is a release. But I would vote to have YouTube, Spotify and other streaming locations all as a “stream release” but with references citing the specific streaming locations (I believe that is important).

For this comparison specifically, IMO absolutely. For me, there is enough of a difference that I will scrap one for the other. There are many reasons, some have been mentioned, including Amazon’s crappy rips, the differences in encoder which causes differences in sound, etc.

In addition, there is a major factor that is not audible. A lossless file can be used in more ways than a lossy compressed file. So there are reasons I want or even need a lossless file and a lossy file just cannot work. But for many, just listening to the file itself will not be any different. My point is that I believe that lossless and lossy are for sure different, period.

I also agree that this all gets difficult. It is hard enough to actually understand all the different quality settings and file formats / containers, but to add to the complexity, there are fake files out there, not just in pirate environments but files that are sold as well. My only thoughts on how to “fix” that are to use the store/source as the driving factor for the release. This would match the logic used on physical releases. Example… if I have one of those CDs that were produced using MP3 files (and they do exist and were/are in fact sold legitimately), there is no expectation that the user evaluates the CD to ensure it was actually created from an appropriate lossless source.

It can sound that way in some cases. But this is no different than a CD that is the same CD but with a different barcode on it. The data is all the same, but the packaging (or store) is different. Same with the BMG CD club releases, etc. If a store sells a product that is in some way different than another store, that is by current MB guidelines a different release, just the same as a different color vinyl or a different barcode or catalog number on a CD. What makes a different series of printed numbers on paper any different than a difference of digital characters “printed” in metadata? That said, I agree the HOW to handle this is key.

Generally speaking, all lossless files are the same as they can be converted to and from each other without loss. It is important to keep in mind though… this is not actually true, but for all intensive purposes it is hard to argue a case against “lossless is lossless”. For lossy, the top three players in container formats are MP3, M4A(MP4) and OPUS… although at this time OPUS is more behind the scenes (ie. most all YouTube streams are OPUS audio now). That list is also in order by genetic superiority, theoretically speaking of course.

1 Like

Perhaps an example would be good.
Does anyone find this release group particularly offensive?

The steam and bandcamp version have different cover art, but if they didn’t the only difference would be format and tags (different track titles on some tracks), and someone can merge them.

I don’t know about thwaller, but all I want to do is be able to store that data, when it is of interest, regardless of cover art, and not have to worry about wasting my time.

To clarify… you are suggesting that you have 2 releases that differ by cover art, have the same track listing but are in a different format. These two releases should be the same release, but noted that there are 2 different formats available for it? I can think of three similar examples, from Katy Hudson (MB appears to be in error on this release as well), Tiffany Evans and Eminem where there is a release with different covers. So with clarification, I think there should be some good example data to discuss.

In your example, it appears that the “stream” one has only 31 tracks, not the 32 listed in MB. Also, just a comment, I would not even consider that one a release, in my opinion. The reason is that it requires the game in order to get/use it. To me, that makes it part of the package, like a box set. If you buy the release, the game, you get that as well. But without the game, you can’t get that as a release on its own… per the web site if that is correct. Just because I would not add it though does not mean I am saying it is wrong to, to make sure my statement is not misunderstood.

You misunderstand me I think. Different cover art is currently used as an explicit reason for a new release in the guidelines, so you can ‘officially’ add any digital release with a different cover.

I have added all those releases, and am just asking if people would confused or bothered by them if they didn’t have different cover art. I want them all to be there, even if the only difference was different track titles or format (as long as they are annotated and disambiguated effectively).

For me whether a soundtrack (or a cd) is packaged with another product is irrelevant. If it can be played or ripped someone’s going to want to tag it. And sometimes it’s the only way to get a soundtrack, and we would never say a soundtrack can’t be on here at all afaik. But I appreciate that you might not have any interest if you don’t have those types of files yourself :slight_smile:

The ‘Steam’ example is actually a good example why this is good data for MB to have. Often you have no idea what format you’re getting from a storefront, or how many tracks etc. I have all of those releases and can confirm those track lists are correct even if the Steam tracklist on the site is missing a track - information you can literally not find anywhere else on the internet. And won’t be able to once again if they are merged because someone ‘doesn’t see the need’ for multiple digital releases.

AFAIK we already do this. I really don’t mind to differentiate that a release is available in low quality in one shop, and there is another high quality version somewhere else. E.g. having an Amazon MP3 release and a release for a 24 Bit 96 Khz FLAC version from another shop would be a no-brainer for me, especially as the other shop wuld advertise this as being special. That’s a good reason to differentiate releases. Also we should be able to record the formats a release is available in.

I am only against duplicating releases from different store fronts for no good reason. And especially not listing all the formats available on a single store as completely separate releases.

I disagree with the “store” part here. We don’t do separate releases because of a different store for physical releases, that would be crazy. As you said yourself we only do this if they are actually different, and the “store” is not the actual reason. So we should not take this as an argument to add separate releases for different digital store, but we should figure out some guidelines what we actually consider different on digital releases


Yes, more exactly Bandcamp encourages artists to upload lossless audio files (WAV, AIFF or FLAC), which (being lossless) are equivalent, formats available for download are all generated from lossless data.

Some artists even upload 24 bits / 192 khz lossless files, which can be downloaded in any supported lossless file formats. When you compare with crappy MP3s most websites (including Amazon) provide…