Digital releases

Tags: #<Tag:0x00007f7cfcf23340> #<Tag:0x00007f7cfcf23278>

My friend… I understand your statement. However, there are some of us who really care about making and maintaining a quality database. When you look at the happenings around you and simply think … all is good, you are passed by. Innovation comes from those who challenge the status quo, not those who accept the norm as just fine.

I really like MB, but unfortunately, the way digital releases are handled makes it basically unusable to me. There are better sources of data, and that is a sad thing to say given that I gave a portion of my time in the recent past to try to make this system the best I could.

BTW- If you are a flat earther (I am not), the world would not turn at all… LOL!

@ Skeebadoo
My opinion, if that means anything, sees a digital release as a digital release in the current MB. If you create a new release for each and every store or streamer, you will end up with a large list that is cumbersome. I believe that all of these sources do need to be identified, but as release events (using the current terminology) and not as different releases.

I am also a form believer that all digital releases need an ISRC code to each recording. Thus, I have added the ISRC to the recordings (and some copyright/licensing) on this release that were not there (Renaissance by Aluna).

1 Like

Given that release events encapsulate a date and a country, how they can be used to store information about a release on a download or streaming platform? Most releases are released on multiple platforms on the same day.

We’d all like a set of guidelines that would make it straightforward to determine whether a digital release should be created as a separate release or not, but it’s just so nuanced that I just can’t see that it will ever be feasible. Based on your replies, yourself and @aerozol seem to have strong but opposing views on this, whilst my personal view is that the answer lies somewhere in the middle and you just have to use your best judgement.

AFAIK many platforms don’t require ISRC codes. It seems that Spotify and Deezer do but Bandcamp definitely doesn’t.


My statements refer to a lot of prior communications on this topic. In the current form, it is not possible, you are correct. The current design is not really accommodating to the nature of digital releases in an efficient manner. I also agree that there needs to be some compromise. It was already made generally clear that there is not much willingness to make major changes to the database, so that will be a limiting factor for sure. I think to start, a collective decision needs to be made as to what aspects of a release are important. Meaning, like with a CD, there are strong aspects to see. The bar code, the cat number (or other distinguishing marks printed on the CD, the TOC of the CD, etc. This needs to be determined for a digital release.

Most retailers will require ISRC. If it is not listed, you can always look it up. Not all recordings will have an ISRC, but the majority will. There is also a lot of talk about a recording having multiple ISRCs and that somehow causing issues. I personally have not seen this in the age of digital releases. Back in the CD and cassette era, absolutely. That does not mean that I am correct, it just means that I have not seen it.

Some other areas I find troublesome…

  1. The current “label” in MB does not apply to digital releases the same as CD. This caused me a lot of confusion when I first started which was resolved by one of the auto-editors. It took a while to sink in for me, because of the different with the digital vs CD. The label of a CD is not the logo printed on the CD, because there is no CD. The label becomes the label in the metadata, which does not always match the one MB asks for.
  2. Bar codes are not so relevant to a digital release. While they are printed on nearly all CDs, that bar code is not in the metadata of most digital releases. The identifying factors should help a person identify a release in their possession, and when the bar code is most likely unknown to them, it does not help in identifying the release. Should it be recorded when and if it is confirmed for a specific release event, sure.
  3. The AcoustID (or other similar technology) to me becomes very important. I have found it to be a very good identifier when metadata is not there, altered, etc. The only issue it leaves is how to determine which of the digital releases you have, and with the current data, it is not possible without the original metadata. This is also something to consider, the objective is to help users identify releases Digital releases should have some structure that is in stages… the main release (the track listing of the digital release with ISRCs and AcoustIDs) and a second layer to break it down by store/distributor/etc (if that information is known).

We do this all the time for CD and vinyl records etc, when there is a difference, and it is not cumbersome at all.

If Skeebadoo has identified differences he should be able to make new releases. Note that this is not the same as always creating a new release for every storefront, only if there is a difference in information to be stored.

1 Like

Yes, if there is a real difference, for sure a different release is justified. However, I see a different as it relates to some areas. For example, as mentioned, featured artists. The store front has a display, which may not accurately represent the product. Some places leave out featured artists all together, some have then added with “feat” and some add them with “&”, and some even do both. I fail to see how that makes the release any different. There are even some stores (like Bandcamp) which dynamically create files for download. The metadata on such files cannot be viewed as “cover data” like on a CD. It is dynamically created from whatever base data is available, and not to mention, different formats store different types of data.

The different I see with this is the fact that there is not really more than say 10 versions of a CD with the same track listing, whereas there are most always more than 10 digital releases with the same track listing. With a CD, there were a few like BMG that would basically rebrand a release, which in MB, makes it a new release. On CDs though, this was somewhat rare, there were not 10, 20, etc companies doing this. On digital releases, every store does this. So it is my opinion that we need to distinguish between a difference of store vs a difference of release.

My only intention is to make MB a good and solid usable resource. I find MB to fit that description quite well when it comes to physical releases. Flaws, yes, but is there better, no, second place is far off of MB quality… For digital releases, speaking for me as a user, it is partially unusable to a point that I stopped. I have no ill will and do check in often to see if there are changes as I am happy to contribute to something I believe is not self destructing. I feel that the digital releases in MB are almost to a point that any sort of change / correction is not really possible as there is too much data that needs attention.


Sorry but I still don’t quite think you’re following me… the amount of digital storefronts is irrelevant because I would not advocate creating a new release for each one in every case. Only if there is a interesting difference that someone wants to store.

Most storefronts will not have differences for a release - you upload your music to most of them via a distributor where you only enter one set of information (credits, track titles, album art etc) and then that distributor passes it on to the various storefronts. It costs $ each time you do this so it should be uncommon for somebody not to release to as many storefronts as possible with one set of data.

There are plenty of physical releases with a crazy amount of variations and nobody is posting about the problems they cause :slight_smile:

Agreed! But I don’t think that is the same as saying that someone can’t distinguish between them if they have a reason to. is one of the main players in music distribution and has a large catalog of music to sell. They allow you to set up your own store front based on thair api so if musicbrainz wanted to make some money they could reletivly easily set up a store for listenbrainz.
I would not be surprised if some of the smaller stores and streaming services was all music provided by the one distribution company

1 Like

I can agree with you there… except I think the difference in question needs to have merit. What is a difference? Track listing, yes. A MP3 vs FLAC, hmmm. a difference of the store listed artists, hmmm. There are some points that I believe need to be solidified. No one can predict the future, which is why I believe that the accommodations, if made, need to be thought out with as open mind as possible. This is why I believe that the structure needs another level … the release group -> the release -> the sub-release.

EDIT: I want to clarify… the sub-release is where the weird stuff can be distinguished. A store ID, an encoder format, a difference of how the site/store front lists it in regard to say artists, etc. I assume this … but I would say that some people will think of a digital release being the same whether m4a (iTunes), mp3, flac, opus, etc. Then, others would find this opposite, where those warrant a distinction. The second level of release would provide this opportunity for both sides, while not discounting either.

Interesting point. I wanted to add that this crosses into my statement of the “label” on CD vs digital. The “distributor” is often times a “label” on digital… if that makes any sense.

One project that I would like is music index that sits next to musicbrainz (call it botbrainz, indexbrainz, spiderbrainz?).
Music stores have websites and some of them have api’s.
Can we write scrapers that go out and scrape theses sites for information.
This can also scrape things like spotify, youtube, soundcloud etc.
This will build an index of music and where it is available.

Let the computers keep track of this information and keep this information up to date instead of having to maintain this ourselves.
If there are different editions it could let us know that some stores have these songs and other stores have a different list and track who has what.
The api would be useful for musicbrainz to allow you to go to a digital release and find what stores have what edition of the release with the same amount of tracks.
It would also be useful for listenbrainz to allow you to build playlists for spotify, youtube or another streaming service.


Very interesting idea… but does that involve more work than a modification to MB?

Musicbrainz is not friendly to bots and this is a policy that I generally agree with.
There are a few bots that do some minor fixes but generally the focus is on human editors.
Bots can start adding garbage so it is something that you need to be careful about.
If we can make something that makes life easier for human editors and allow them to add missing information without too much work it will help things.

If you have indexbrainz and design the web services right it should be useful for musicbrainz, listenbrainz and other uses.
Suggested web services:
Store lookup:

  • Give it a musicbrainz release id, return a list of stores and url’s to go directly to that release.

Missing lookup:

  • Give it a musicbrainz release id or artist id, return a status code if there is a release with a different set of recordings or a missing album.
  • Seed the editor with the list of tracks.
  • Use A multi‐source seeder for digital releases to seed the release editor.
  • For things such as soundcloud / youtube suggest adding a release as a single or just add stand alone recordings.

Song lookup:

  • For things like listenbrainz have a central index of songs instead of trying one service after another.

Initially should be able to call this api from a greasemonkey(or equivalent) user script without needing to modify musicbrainz.
Once things have been tested and the web service is stable you can add this to musicbrainz like they did with adding acousticbrainz.
In case you missed it you can go to recordings pages and it will look up for an entry with that recording id and display the key and BPM on the page.

1 Like

I have yet to see an argument for tracking store availability that gives a user more information than what is currently possible with the “can be stream/purchased for download” links.

With a CD or other physical media, we can track all these minor details, because they are all verifiable in the end. If you have the CD in hand, you can just check whether it says “Booklet printed in X” vs. “Booklet printed in Y”. With digital releases, the information can change under our feet (since vendors have total control over their databases). The popular streaming platform import tool demonstrates this: It adds a huge list of country codes as release events if if its unavailable in some of them, but if you run the same import a few days later it’s not unusual to find that the list of available countries changed again, e.g. including the one that was indicated as unavailable before.

Interesting points, thanks. I did just jump in to this topic so apologies if I missed some concepts explained in previous parts of the discussion.

Personally, after adding hundreds of digital releases, I’ve come up with a few rough guidelines to determine if a separate release is needed:

  1. Differing number of tracks, track lengths or track order (this in particularly is surprisingly common).
  2. Different release label (again reasonably common).
  3. Different catalogue numbers (however this is often quite ambiguous due to “standardisation” of numbers on platforms like Beatport and Juno Download).
  4. Different barcodes.

I always start from the position of “a new release is not required” so I am looking for notable differences rather than similarities. Some differences I personally think are generally not significant enough to warrant creating a separate release are:

  1. Release dates (within reason), e.g. artists often release on Bandcamp first and then streaming sites a few weeks later.
  2. File formats and bitrates. Most stores offer downloads in several formats, and streaming sites such as Deezer offer “HQ” lossless subscriptions. I’ve seen master releases on Discogs containing 6 releases which are identical except for the file format.
  3. Minor differences in track titles (e.g. “Original Mix”) or featuring artist credits.

Do you have a link to an edit note or forum post about this? I’d be interested to read it.

Isn’t the purpose of a barcode is to uniquely identify a given “item” that is offered for sale? I appreciate that most people neither know nor care what the barcode of a given release is, but it surely still serves a useful purpose for a music database as a unique identifier?

I agree that the acoustic fingerprint is important and it’s entirely reasonable to have multiple releases in the database with the exact same AcoustIDs. However I would also say that differing AcoustIDs is a strong indicator that a separate release is required.

I’d be interested to hear your view on why the current URL relationships aren’t sufficient to provide the “second layer” to enable someone to identify the release by the the store or distributor (if known)? I do appreciate that this information isn’t available in Picard, so it would require the user to look at the release pages on MB.

I agree and this is why I have issues with adding 180+ release events. It makes sense in a perfect system, but in the real world it doesn’t really capture any useful information.

I think many of the difficulties we have around adding digital releases are due to people trying to treat digital releases like physical releases, when they are and always will be fundamentally different. The complete control platforms have over their databases means that there is no canonical source of information for a digital release, so as submitters we are forced to create the most accurate release we can based on information from multiple sources. This naturally make many people (particularly those who are likely to contribute to MB) uncomfortable, because we expect the process to be almost completely objective.

A good example of the way in which the schemas of different platform’s databases cause problems is the “standardisation” of catalog numbers:

Would anyone seriously argue that separate releases should be created for Juno Download and Beatport because they strip the hyphen from the catalogue number?

1 Like

I very much agree with the catalog numbers example, and I would go one step further and say to ignore the catalog numbers from Beatport (I don’t know about Junodownload), because as far as we can tell, they are not assigned by the artist or even the label, but the store based on an algorithm.

1 Like

If they have the same artwork, barcode, labels, tracklisting, recordings, than it’s the same release. Storefront alone, I believe, is irrelevant. It seems the same to me as physical media. So, I agree.


You can also search YouTube and 7digital by barcode to see if they are the same release as iTunes, Spotify & Deezer. Also, HD Tracks now has a great API that gives barcodes as well at:[HDTracks album ID string]. Also, many Bandcamp release actually do have barcodes as well, many don’t.

1 Like