Digital releases

[dns_server]

@aerozol

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.

https://www.7digital.com/ 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
.

[thwaller]

@aerozol

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.

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.

[thwaller]

@dns_server

https://www.7digital.com/ 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

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.

[dns_server]

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.

[thwaller]

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

[dns_server]

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 acousticbrainz.org for an entry with that recording id and display the key and BPM on the page.

[elomatreb]

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.

[atj]

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.

@thwaller

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.

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.

@thwaller

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.

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

@thwaller

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.

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?

@thwaller

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).

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.

[atj]

@elomatreb

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.

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:

@atj

Both Beatport and Juno Download seem to perform some sort of internal “standardisation” to catalog numbers. Juno Download strips non-alphanumeric characters and adds a space between the letters and numbers. Beatport just strips non-alphanumeric characters. Also as noted above, sometimes Beatport just lists the UPC as the catalog number.

Using Anunaku - Stargate EP as an example:

• Juno Download - 3024 ANU1
• Beatport - 3024ANU1
• Boomkat - 3024-ANU1
• Bleep - 3024-ANU1
• Traxsource - 3024-ANU1

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

[elomatreb]

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.

[tigerman325]

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.

[tigerman325]

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: https://hdtracks.azurewebsites.net/api/v1/album/[HDTracks album ID string]. Also, many Bandcamp release actually do have barcodes as well, many don’t.

[tigerman325]

There are actually cat # on Beatport that look like legitimate cat #. But, yes, many are just the barcode thrown in the field.

[atj]

@tigerman325

Also, many Bandcamp release actually do have barcodes as well, many don’t.

It doesn’t seem to be possible to assign different barcodes to physical and digital releases on Bandcamp, so most barcodes apply to the physical release. As a result I would only trust the barcode on BC if the release is digital only.

[tigerman325]

Doesn’t matter. If a digital release on Bandcamp has a barcode, than it’s the barcode for the digital release. I’ve edited many Bandcamp releases that share barcodes with other digital outlets. Also, many iTunes, etc. releases also share barcodes with physical media. It’s still the barcode for that release.

[ulugabi]

So all the similar releases from below release group could be merged together?

Sainte‑Victoire

Regarding the quality will the new field be available at Media drop down box (ex: Lossy/Lossless/HD) or only at the store link with format. First option would be nice to better organize its collectio.

Thanks

[aerozol]

@ulugabi

So all the similar releases from below release group could be merged together?

I personally would never want those merged… It looks (at a glance) like someone’s gone to the effort to make a really comprehensive release group. Amazing.

(Something like a seperator or filter for digital vs physical could help for those who don’t like it)

[ulugabi]

For me it would like trying to keep records of all the shops that had a specific CD available including their internal references, catalogues and other marketing tools which is not the purpose of Musicbrainz
Also it could be quiet complex as “Release mode” was not created to handle the nature of those data which are not fixed in time (It could be available in a shop and/or country then removed then back again).
And there are the other issues already discussed such as labels (not the same meaning as for physical), impossibility to verify the data from public sources,…

Nevertheless seems some people are interested to keep those infos so we could but “Relationship” seems more appropriate to handle the evolution in time and/or the differences between shops

Taking the old Release group example I would see:

Releases:
- 1 for the 11 tracks CD
- 1 for the 11 tracks Digital Media showing Lossy/Lossless (5 to merge together)
- 1 for the 15 tracks CD
- 1 for the 15 tracks Digital Media Lossy/Lossless/HD xxbits/xxxKhz (6 to merge together)
- 1 for the 20 tracks CD
- 1 for the 20 tracks Vinyl
- 1 for the 20 tracks Digital Media (3 to merge together)

With this example of relationships (fake data):

Stream for free: Spotify under [no label]
in: Albania from 2018-04-06
Vietnam from 2018-04-06 to 2019-01-14

Purchase for download: Qobuzz under [no label] with barcode XXXXXX1
in: France from 2018-04
Belgium from 2018-04 to 2019-12

Purchase for download: HDTracks under Initial Artist Services with barcode XXXXXX1
in: USA from 2019

Purchase for download: iTunes under Initial Artist Services and Mastered for iTunes with barcode XXXXXX2
in: USA from 2019

Purchase for download: Qobuzz under IAMNEW with barcode XXXXXX3
in: France from 2020-01

In details it means a specific release should be created only in case of major difference(s) on the Track numbers or music files (ex: real remasters).
Marketing stuff from shops (ex: Masterised for iTunes) should be ingored as rips from CD (see 1)

For the main release data:

• Date: The first one from the different platforms
• Country: To grey out (not really relevant as restrictions can easily be bypassed and change in time)
• Label: To grey out (as no imprints on Digital releases and the ones from platforms dont refer to the same notion)
• Cat number: To grey out (as for labels it would ends up mostly in wrong information)
• Barcode: To grey out or to allow multiple values

1 Not sure about this one. To my point they are not a new release but a rip of the CD version, not a specific release of media (files in this case). But I m missing knowledge on this: How were made releases in the 2000s (real remaster or just rips) and legaly (ex: can a shop provide digital files along a CD is selling to a customer without specific contract).

[tigerman325]

No. If they have different barcodes, they are different releases.

[IvanDobsky]

I am not a collector of digital, but don’t see the problem with this Release Group. If the barcodes are different, then they are different Releases. We use far smaller differences in the CD versions to allow different releases. Small changes in artwork is enough for a new Release, so the same should be fine for Digital.

Too much information is better than too little. A difference is a difference and is interesting to someone…