Digital releases

I understand what you are saying, but are you then suggesting that each and every encoding variation be a separate release? This is why I mentioned the variations in my statement. It is my understanding that MB would prefer not to use a separate release for each type of digital file.

Should you suggest a separate release for each type of digital file, I would support that personally, but I think that is not going to gain any support. One big reason is that the expectation that users know the differences is not so realistic. I think for users that do know, the variations proposal would work, where I might note such things along with the reference, so I have something like this is a lossless release, and this variation is for a 24 bit FLAC and this one for a 16 bit FLAC, for example.

Personally, for audio files I have for the intent of listening to only, I don’t even keep or want 24 bit FLACs. They are a waste of storage space and offer me nothing in return for that space. As a music consumer, I would even go as far as calling the sale of such things a gimmick to make more sales at higher prices, but that is my opinion I will say with 100% honesty that if I have the option of getting a 16 or 24 bit file set with my purchase, I want the 16 bit. Now this assumes that they come from the same source master, which is a whole different discussion, I speak assuming all else equal.

The reasons as I understand them on listing CDs under separate releases is not at all due to the musical product, but that CDs, and cassettes and vinyl as well, is differentiated by the printing and packaging, not the musical product. So you can have CDs of differing sound quality be considered the same release whereas 2 CDs with a insert printed at two different companies can be a separate release. I personally disagree with this, but I understand what MB is and has done and it is just a different view point. If you want to apply that same logic to digital, I can help there, but we will need a different release then for each and every variation in files. For this, I would be happy to assist in identifying all of the possible package differences for digital files.

@aerozol - This does not change the intent or message of your post, as a side note, just to be clear, a “listening test” is not what was done. Yes listening is a part, but, for example, the 16 and 24 bit FLAC were both opened, aligned, then one inverted and played together. The result of this, is basically the difference. The result achieved here was total silence, including no indication of sounds looking down to -60db. Regardless of what you hear, this shows that there is no detectable difference, nothing that the said test can detect anyway. This is a step above a ABX type listening test, since those are different per person and can also be thought to be different, etc. All of which makes them a test of perception vs fact.

Again, I know your point and I understand, but I wanted to make sure that what I am saying is also clear. I do a lot of ABX testing as well on many things, but the results of those tests are only valid for individual use, or as an aggregate.

Sorry to the group for yet another post, but I had a conversation a few hours ago on this topic, as it relates to non MB topics. Anyway, there is simply no tangible difference between a 16 and 24 bit FLAC file, and the same applies to a standard and Mastered for iTunes M4A file. The same also applies to a CD and a HDCD or any of the sorts. A CD is played in a CD player, which has DACs that do the work. DAC meaning Digital to Analog Converter… I believe Burr Brown are still the top class. This goes far beyond, I think, of MB, but it most likely ends up at 16 bit anyway. Then you have the quality of the cable, the preamp, the amp, speaker cable, then speaker. Or I guess the output jack, headphone cable and headphone transducers. But there is more difference between a iTunes M4A and a amazon MP3 than there is with a 16 bit and a 24 bit FLAC. I just speak honest facts, although I would love to believe that a 24 bit FLAC is better. It is just not the case.

I will make a disclaimer, that on a second generation+ remastering (the FLAC is a mastered file after all), there is in fact a difference. I doubt that is in scope of MB though. But as is well known, you cannot master a master without being destructive.

4 posts were split to a new topic: Audiophile chatter

I like that idea. I have added a number of releases where only the barcode changed and amazon has a new release date. When I see that I add a comment in the note on the add release. Some times the back art changes only in adding in extra imprints due the merging of labels, but lately I have seen re-releases where nothing but the barcode changes, all the dates, imprints, etc, stay the same.

9 posts were split to a new topic: Digital promo releases

I know this is an old topic, and I’m not sure if there’s been new/more concrete ideas or plans being thrown around since (please point me in the right direction if so), but something like this makes a lot of sense to me.

1 Like

I dunno about plans but I see potential in something like this since the variant grouping could be made automatic if two releases share all recordings between them. I think this could help solve a problem with “too specific” digital releases which really grinds my gears even though I like the current level of precision.

Imagine a situation where you want to add a “purchase for download” link to a digital release and find out that there exist two digital releases already with identical tracklists but both having different barcodes. The store you want to add your url for doesn’t provide barcode info and even the release date shown is the original release year from 1970s. Should you create a new release for this link? If you wanted to add another url for another store with a similar situation, would you add it to this yearless stub or should you play it safe and create yet another release?

If variant groups had url relationships and those could be easily moved between a variant group and its releases, the beforementioned problem wouldn’t exist. A variant group could have a release from which it takes its tracklist (compare to setting a release group cover art) and so it would act like a normal release. This would help taggers who don’t know or care which specific release is the absolutely correct one for their purposes but don’t want to put potentially incorrect info in their files.


Something like this is currently going on with RTJ4.

As of now, there are 5 (known) different “barcodes” for a single release event for the same album

  1. US official free download
  2. UK official free download
  3. US official paid download
  4. Spotify/Deezer
  5. iTunes
  6. [Every other digital store without an accessible barcode]?

That’s potentially 6 (maybe more!) releases for a single digital release event where you wouldn’t even be able to say which one you had if you only looked at the files on your computer.

Now to some, the distinction in barcodes is signficiant, and worth documenting, so I won’t argue that. However, for the majority of music consumers, I don’t think this is the case and I believe the differences should be taken to a ‘deeper layer’ of the database and out of the initial release group presentation.

My dream layout:

  • RTJ4 (release group)
    • Original Album
      • Vinyl (I don’t know a ton about vinyl releases, but you get the idea)
        • Europe pressing
          • Red
          • Green
      • Digital
        • Official download barcode
        • Spotify/Deezer
    • Deluxe
    • Original Remastered by Hi-Tech Sound
    • 20th Anniversary Double Disc

Where a ‘master release’ is based on tracklist and mastering and nuances are displayed in sub-releases or variants. Arguably, this layout is much more readable when looking at any release group and less intimidating for any users that maybe just care they have a digital version of the original album. All sub-releases would inherent all data from their parents and change or modify as required.

Note to top dogs: I have a background in computer science and may be able to provide more info/help if required.


The recent comments all match my intent on this thread. It is nice to see that others recognize this as an issue.

1 Like

Is there a ticket for this? This seems like a nice and simple way to solve a major grievance in this thread.

I’ve added format options to some URL relationships (but only on You can try them out by going to an edit URL page such as


So when we add a Bandcamp release with the above system in place, the relationship becomes “can be purchased for download in MP3, FLAC, AAC, Vorbis, ALAC, WAV, AIFF”? (Not to mention the case where Bandcamp decides to add e.g. Opus downloads, which instantly makes all Bandcamp links outdated)


Maybe the formats are optional, and you can just leave them off bandcamp links as they’re assumed to be available in all or most formats. Or even better, if bandcamp is selected maybe the system can auto-populate the formats it’s available in. I don’t really understand the argument against allowing more information in the database.

There’s the fine line between allowing more information in the database and maintaining useful and relevant information. Taking it to the extreme, should we also attach a list of every piece of software that can play the file? I think we can agree that doesn’t make a lot of sense, even though it can be considered valid data.

Personally, I don’t see a lot of value in listing every file format available for download, but that’s just my opinion. There are programs out there that allow me to convert between formats at will. I might be convinced to have a flag (or some attribute) indicating that it is available in a lossless format, because I concede there might be value in knowing that. Other than that, not so much.


You don’t have to add any information to the database, but maybe people that find it useful add it. If you don’t think it’s worthwhile, you could just let others bother with it.

1 Like

But if the information is outdated whenever a store updates its supported formats, the information is not much use to anyone. If available formats can automatically be displayed depending on the link (it’s Bandcamp, so it’s these formats) the information wouldn’t get obsolete and it would save all editors a lot of time.

1 Like

It’s not exactly automatic, but bots could probably be used to set format attributes for most stores.

1 Like

If someone is at all interested in cataloguing digital music then there’s a huge difference between having/being able to find the link to buy a FLAC version vs finding a stream. And in a much more practical sense than tracking slightly different text on CD packaging.

I don’t really care if we find other ways of implementing these distinctions. But as the world heads more digital dumbing down what we allow people to store in regards to digital release specifics is not the way forward imo.


A boolean “lossless” flag feels like an acceptable compromise between having the data where and if people really want it and not overburdening the database and editors with tracking the whims of format selections by music vendors.

But even this has its problems; For example Deezer claims to offer “lossless streaming” but if you actually look at the files they give you, in many cases they are just converted lossy audio.