Digital releases - attempt at proposal

MusicBrainz
1

A fellow editor made a good point in that to proceed, there needs to be support and traction for an initiative. The purpose of this post is an attempt at that. There have been numerous posts on different parts of this topic, from me as well as other editors, and I thought another editor attempted this same but I cannot find that post if it is there.

In short, I believe that the way MB handles digital releases is inadequate, and given that digital releases have been around for 15+ years it needs addressing to stay true to the stated goals of MB. Should others agree with this, please provide a showing of support here, so the voice can be heard if it is there. Then maybe we can identify the areas of interest and concern and look at them individually in efforts to keep things more organized.

I would like to start with:

#1. The identification of a digital release. On the release group page, there is a listing of releases that it contains. This listing works well for CD and other physical releases, but not so well for digital releases. Should multiple digital releases be added, this makes differentiating them on a initial visual level very difficult. Another editor started this topic here: Differentiating digital releases by store.

2

In effort to suggest a method of organization, I propose replies like this:

RE: #1 - the listed attributes that are clearly marked and visible on CDs and other digital releases are not so on digital releases. So while these attributes help find your release well for those releases, they do little to help on digital releases. Maybe consideration to store fronts or file types / containers could be added, and maybe even only for those of digital type. Possibly a two section table, top half physical and second (under it) digital, allowing for a different viewing matrix.

2 Likes
3

But why would we create mutliple digital releases for the same tracklist?
There is no need IMO.

As we don’t create multiple CD releases for each possible street shop we can buy them from, there is no reason to create a digital release for each online store that sells them.

If there is a reason (specific encoding, different cover art), then it is visible in the release group page (disambiguation comment and the userscript that displays cover arts).

10 Likes
4

Encoding does not have much prominence, and other editors eventually remove disambiguation comments in order to merge digital releases.

The environment informs the behaviour, and the environment currently does not promote the addition of nuanced digital information.

1 Like
5

I agree jesus2099, there is no need to differenciate digital releases!

1 Like
6

I think Release - MusicBrainz talks about the database schema pretty well

A MusicBrainz release represents the unique release (i.e. issuing) of a product on a specific date with specific release information such as the country, label, barcode and packaging.

So you create a new MB Release with the “same tracklist” regardless of whether it’s a CD you hold in your hands or files you download from a store.

7

This page does not mention release events at all, it might be outdated.

2 Likes
8

That is another possible solution worth mentioning I think. There could be a single release for all digital releases of the same track listing, and they can be differentiated as different release events. The current setup does not allow for this, but it is an option that has been mentioned.

9

One reason is that the releases are (can be) different, just like a different barcode on the otherwise same CD. All CDs are not the same just due to same track list. A digital release of MP3 vs FLAC is similar to a HDCD and a CD. It is a different medium,

10

No. There’s a core difference between physical releases and non-physical ones: physical are limited in their form by nature, while non-physical can potentially take an infinite number of forms.

As explained elsewhere, we may store information about where to find a “digital” release in one format or another, but if we create one release per digital format it will be a useless bloat, only complicating work of editors without any added value.

Currently some digital releases providers offer them in ~10 different digital formats, but in the future this will just increase, as new formats appear, until, eventually, one format rules them all.

Comparing HDCD and CD to FLAC and MP3 makes no sense to me, especially when many FLACs sold were converted from MP3s (which is a shame, i agree), and many MP3s are generated from lossless formats.

Physical releases are limited in their forms, manufacturing, distribution, possibilities are limited, which makes it more or less manageable for editors.

Now, if an album is available in various digital formats, with exact same tracklist, using same “master” (it can be a CD, which contains digital data in lossless format), i guess users may want to know where to find it as OGG, WAV, FLAC, or whatever they prefer, there’s no question about the fact MB needs to store such info somewhere.

It can be as simple as extended relationships like:

  • can be downloaded [as <insert list of digital formats> ] from <insert digital store>
  • can be streamed [as <insert list of digital stream formats>] from <insert digital stream source>

Limiting duplication of data is mandatory if we want to keep control over it, MB is human-based, things need to be human-manageable.

Also MP3 or FLAC don’t fully describe what they are, compression parameters do too, i guess we don’t want one “medium” (as defined in MB at the moment) for each possible MP3 or FLAC format. The media list is very long already, just with physical ones.

About “digital releases” i see many more issues:

  • changes in tracklist over the time (since they are digital, altering the tracklist is very easy, and it happens a lot, artists or labels reordering tracks after release, or even adding/removing some, changing titles, etc)
  • a release can contain a physical medium and a digital one (CD+download), but relationships are to the release atm
  • cover art can change for the same album over the time (it happens a lot too on Bandcamp)
  • barcodes / catnos / labels / release dates / countries don’t have the same importance, and aren’t always easy to figure
  • digital releases have no size and/or duration limitation, a 10k tracks release is perfectly possible (and legit), a title of 50k characters too
8 Likes
11

It’s already possible, see release events for various countries in https://musicbrainz.org/release/24d4159a-99d9-425d-a7b8-1b9ec0261a33 and even various countries per date in https://musicbrainz.org/release/2afbc7ed-7627-413d-904c-d6cdafdf2a0a

12

A CD and a HDCD are mediums capable of storing a certain type of audio. A mp3 container and a flac container are digital containers capable of storing a certain type of encoded audio. I also speak of original products, not something you or I make, just as CDs I copy or make from others are not releases, but playlists or bootlegs at best.

So, a CD can store 16 bit audio at 44.1, correct? I hope we agree there, and if so, that is the limitation of a CD, as you stated. Now, a mp3 container cannot store 16 bit audio. A flac container can. Is this similarity not there, where the container restricts its contents?

There is a difference between a container and the audio format, the way in which it was encoded. For example, an m4a file can be lossy (typically AAC) or lossless (like ALAC). These are limitations of the medium/container, just like CDs and all other physical media. So calling it a m4a file is part of the process. I cannot play a m4a file on a device that cannot decode m4a, just like I play different physical media on all players, one cannot put a cassette into a CD player.

I agree that FLAC (or other) does not fully describe it. But, neither does CD, or cassette. It is a step one at a distinction between containers of digital audio, nothing more than that. I also agree there are many, many other issues and considerations. If you read what I posted, this is one part and one aspect in the whole topic and not a end-all solution.

It is my opinion that calling all digital releases “digital media” is like calling all CD, cassettes, 8tracks, vinyls, etc all “physical media”. I hope that explains the comparison I made, worded as “similar to” and not “same as”.

2 Likes
13

What I mean is there is no way to add notes or annotation or disambiguation to a release event and/or a specific reference. But yes, there can be different release events allowing for a different country and date.

2 Likes
14

This is very unfortunate, agreed 100%. Same has been true on CDs, where the CD was produced using MP3 files, but nowhere near as widespread as fake digital files.

I agree a lot on this one. This point is part of the reason for this whole topic… looking at the release group screen, the items used in the entities contained cater (understandably) to physical and not as much for digital. The barcode and catalog number combo there is great for CDs, but not great for digital.

On the label, one comment I would like to share is that for CDs (and other physicals), MB wants the imprint, which a user can find on the cover art for the release. The issue (or one of them) on digital is there is no cover art to look at and when looking for the label, the imprint is not what is used, but the entity listed could be the imprint. So I can most times tell you what the digital release calls the label, but I cannot do that to identify the imprint. I have tried to think of a way to address that one, but cannot.

15

This would require large schema changes:

  1. Moving barcode to Release Event
  2. Moving Cover Art to Release Event
16

Of all the options that have been presented so far (one release per store, release variants, etc.) I like this approach the most. Doesn’t pollute the database and also satisfies people who’d like to find a certain medium format to purchase their music, which I think was their concern.

I agree with all of the issues above and we definitely need to address them at some point. Sometimes there’s also different tracklisting per store (most of the time unintentional) or some other copy+paste mistakes.

For the covers changing over time, sometimes they are changed only for certain stores (e.g. one store updates it, the other store doesn’t) but I don’t see this as an issue. The editor can just add all covers with comments like old/new cover or store names, such as this release Release “Renegade EP” by Noisestorm - Cover art - MusicBrainz.

1 Like
17

True, we don’t want to “pollute” the database with current digital release details when we can use that time to store every logo placement variant on old CD cases.
Stay relevant, MB.

1 Like
18

There could also be some intelligence built into the web UI as well. For example, I see this a lot where an editor adds a release, uses an iTunes reference and marks it has having no barcode (I refer to the checkbox). I understand this completely as iTunes does not disclose barcodes for its releases, so it appears there is none. But, in order to list your musical product on iTunes, it is required to have a barcode and an ISRC for each recording.

I understand that such logic can be difficult, but the current UI detects iTunes links as such, iTunes links. So the logic is partially already there, where you can state if any reference = iTunes then checkbox for no barcode cannot be checked.

I see it as relevant to discussion as it addresses data entry errors on digital releases due to part of the issues named above. I personally do not track barcodes for iTunes releases. This is because 1) iTunes does not tell me what it is, they only provide a cross reference search, which does not actually mean that is the assigned barcode, just the referenced barcode and 2) that barcode can change internally at iTunes and we are not informed, as they do not disclose the barcode to us. That is only my opinion and usage though, I am sure others here find that barcode extremely important for some reason or another, but the fact is that asking for a barcode on a release that is always going to show none (as of today) is confusing and leads to errors that are not really the fault of the editor… as when you look at the release, you can state for sure that there is no barcode present on the release, which is the MB guideline, if you check the box, you are stating there is absolutely for sure no barcode on the release, making the editor both right and wrong at the same time.

2 Likes
19

Maybe beating a dead horse, but there is a related discussion going on – edit #48837641. Feel free to chime in.