Here is a mock-up for a digital media release page

[Alex1]

I am offering for discussion a mock-up of how the release page of a digital release might look like.

As a way of introduction, I see that external links may suffice to merely indicate that a digital version exists:

But when you decide that digital media should be treated as separate release entities, then I think you might want to devise a separate database scheme, because the details might not fit into the same scheme you use for physical media releases.

The release I used for the mock-up I submitted myself (my very first ) via a-tisket (and it is still open for votes). Here it is:

My explanation for each change (see the numbered red circles):

1 and 4

I moved the link away from “External links” and also renamed it.

First, about renaming:

The global link ‎My Life (Bonus Track Version) - Album by Mary J. Blige - Apple Music should not be named “iTunes US”, rather “iTunes” or “iTunes global”. The “US” link is this one: ‎My Life (Bonus Track Version) - Album by Mary J. Blige - Apple Music. This might seem like an insignificant detail, but is it?

In today’s world, there exists iTunes, Apple Music and Music (the app) - various services to get the same thing. So, this link could just as well be described as “Music” or “Music US”. Thinking of a general description, you’d have to use “Apple US”, or simply “Apple”. Apple after all is the release source for this album.

Second, about external links:

Source information is one thing, whereas an “external link” can be anything else specific to the release, like a corresponding Discogs page. These are two different things though!

Therefore, placing this link under “External links” makes it look like a minor detail, especially if there were more external links.

Placing it under “Release information”, as I did, gives it more relevance over other links.

2 and 3

The release date is not the same as the date an album became available in a store. Releases through Apple come with the original release date, which is important information.

Taking Live by Donny Hathaway as an example, we all know it was not released through Apple in 1972, however the date tells us which original release the digital files correspond with (or were produced from).

Placing this original release date under “Release Events” is simply wrong - something that a-tisket does automatically without warning.

It is too much to ask from an editor to know or research the digital release date. If it is known, as in this case, fine. If not, don’t bother with it.

With physical media, the release date and region are essential data to describe the release event. With digital media, it is different:

The release date may not be known and is probably less significant than availability information.

The geographical region of a digital release seems arbitrary and relatively unimportant. It is the “source” (distribution platform where the files were released) that is more important.

5

Placing country and flag under “Release events” is wrong, because they signify something else: availability.

I realize it would be unwieldy to clutter the page with a long list of countries. Better let a tool like a-tisket by @marlonob generate this information on-demand.

The trouble of determining the release region for a digital release (addressed in this topic by @August_Janse) could be diminished if the question is not “where was this released?” but rather “where was this release noticed?” The second question can be answered easily by the person making an edit. @cbedgar used the annotation field to list the countries, and I suggest using a separate “Availability” tab.

For an example of how it could be used, see the annotation on the release page. I checked US and DE, so that is all I know and will put down. The dates represent “date noticed”.

If another editor comes along and checked for FR availability, he could expand the list. If yet another editor comes along and checked DE, he could update the date or append a date.

In my mind, region data (country and flag) should be discarded from what defines the release event of a digital media release and should be re-associated with “availability”. It is the release source (store) that matters. It is to digital media what country is for physical media. Accordingly, I also re-imagined the release group page:

My explanation (see the numbered red circles):

1 and 2

The column title “Country/Date” becomes “Release event” and a digital media release would be distinguished by its release source.

Release sources then could become entities, like labels, with their own https://musicbrainz.org/source/[id] page.

Applying the mockup to another album

Take a look at this #Relexa example provided by @thwaller in this post. The release events data would be moved to the “Availability” tab. The BR and ES iTunes links would be discarded. Instead, one (and only one) source has to be given under “Release information” - whichever the editor used to get the audio file and/or information about it.

What is still troubling about this whole approach is that basically every digital release in every store on the planet would have to be treated as a separate release… unless you allow only one digital media release per album and then add the sources as links, dispensing with other details like barcodes, quality, etc.

Related topics:

Differentiating digital releases by store

Continuing the discussion from Digital releases and barcodes: Perhaps store links should be displayed more prominently on MBz. How about adding a new column to the release table, and when an online store is linked to a release, displaying that store’s icon in that release row.

Change for UPC and iTunes handling to clarify digital releases

I think that it’s necessary to clarify some aspects of this fields to avoid destructive edits. For example in https://musicbrainz.org/edit/56215749 the editor most likely thought that, as this is a digital release, it does not have a physical barcode. It would be helpful to rename the field as “barcode / digital UPC” or something similar as to avoid this kind of edits. Also, automatically transform “https://itunes.apple.com/album/*” to “https://itunes.apple.com/us/album/*” would help to avoid …

[thwaller]

Excellent work. I sort of gave up on things due to this (and the related) issue. It is great to see that others see the problem that exists. I still believe that a digital release should be ONE release, with different release events to distinguish the different stores and formats. Having said that, I also understand that the database does not support this as it is a major change … adding basically sub releases to a release, in a release group.

There is other information in the metadata that I find very useful. In the early days of my joining MB, I had some long discussions with @fmera on labels. After a while, I began to understand better what MB is actually wanting. The issue is that personally I find that option less useful compared to the “vendor” as is in metadata, but it is also sometimes the same as “label”.

On the issue of the aspects of the digital file, I will gladly participate again, but will not debate on it. In the past, many argued with me, and I back, on the differences in quality and what can or cannot be actually heard by the listener. I still stand by my statements and they continue to be proven, so if there is disagreement I will simply step back and let what happens happen. The quality of the release is a bit outside the scope of MB as it is detail that even CD releases did not address… meaning that not all CDs are true 16 bit audio as they are said to be.

A last comment … I would suggest that Picard add in extra precautions on removing any existing metadata (especially original metadata), and make the implications very clear on the modifying of existing (original) metadata. It is my opinion that changing the metadata is like changing how a CD cover or insert was printed. Once you remove it, it is gone.

[jtpavlock]

So to clarify, separate releases for digital releases isn’t a confirmed feature musicbrainz would like to implement, and this topic is just mockups for if we did decide they are their own special releases?

[Alex1]

My thoughts on all this have progressed and I might describe another approach soon. If I would sit down to create a mock-up today, it would look different.

But one take-away is definitely about this:

These two data bits don’t belong together. The country data is supposed to identify the release of the album, not the “release” of the digital version. The word “release” should not be confused with availability. “United States” in the context of this digital media only means that an editor noticed its availability when looking up this page: ‎My Life (Bonus Track Version) - Album by Mary J. Blige - Apple Music.

The digital album is a derivative of an album that was first released 1994-11-29.

An album that was first released as digital media is an actual release, though.

The release date refers to the release of an album and has nothing to do with the format. When you rip from vinyl, the release date is still the release date of the vinyl.

The digital version is an entity described as “release” here at MB, but it is not actually a release. It will have a different UPC but that is just a detail for tracking sales. It does not make this digital version a new release.

When you obtain the digital album, you would want the metadata from the original release (except for release country), but you would not want to match it against the CD or vinyl release. A solution to this problem is currently brewing in my mind…

It follows that change “1” in the mockup should be corrected, because that is not the “Release date”. It is a “Sales start date”.

Change “1” was a nod to what @HibiscusKazeneko said:

@HibiscusKazeneko

Often times when submitting an album to iTunes, labels will include an album’s original release date (or what they think is the original release date, depending on the age of the album) rather than the date the album was made available through iTunes, which is what we prefer here at MB.

This confused me. I’ll say again: release date should not be confused with sales start date. Labels are correct to give the original release date. When an album becomes available through iTunes, that does not make the offering a different release. Adopting the sales start date as the release date is not a good idea. There is only one case in which this is correct, and that is when the album was first released through this vendor.

I now regard my submission of My Life (Bonus Track Version) as a wrong release entry, because the album was not released as digital media.

When I submit a fingerprint from the iTunes version via Picard, ideally, I could select to match against the original album, but without having to bother to pick a particular country release, because that is not something I can know, unless the album was only ever released in one country.

My thoughts are that a digital media release should only be submitted if the album was first released in digital format. All other cases are just digital derivatives and not “releases” in a strict sense of the word.

When you submit a fingerprint of a file that was already digital, when you obtained it, it might be deemed (based on AcoustID) the same recording as the CD release, with which it would be wrong to match, because you just don’t know how the digital file was created in the fist place. I would want the Media tag to remain “Unknown” or left out.

When all you have about the original album is the release date, the album title, the track list, the cover, and you don’t have the label, the country, the original release media, that is the situation when buying from Apple. A solution, using Picard, might be to match against the whole release group to avoid getting metadata tags “Release Country”, “Media”, “Label”.

[Alex1]

@jtpavlock

So to clarify, separate releases for digital releases isn’t a confirmed feature musicbrainz would like to implement, and this topic is just mockups for if we did decide they are their own special releases?

This mockup is motivated by feeling that the presentation of digital media data is not ideal. The question you ask is very much the question I also ask: Should digital media offerings be seen as separate releases?

I am leaning to “no”. If an album was first released in digital media, only then can you speak of a “release”. It is the only case in which the creation of a new release entry is justified.

The freedom you currently have to create release pages for digital media offerings based on the same template that is used to create release pages for physical media releases leads to confusion. Some editors might use this freedom to make a digital offering appear as a release, which I tend to regard as false.

My own submission of My Life (Bonus Track Version) is in a way false, because that album was not released as digital media. Yet it is convenient to use this release when matching via Picard.

[Alex1]

Thank you for reflecting on this topic once again!

@thwaller

There is other information in the metadata that I find very useful. In the early days of my joining MB, I had some long discussions with @fmera on labels. After a while, I began to understand better what MB is actually wanting. The issue is that personally I find that option less useful compared to the “vendor” as is in metadata, but it is also sometimes the same as “label”.

I don’t understand - could you edit your post and provide a link to a previous topic?

@thwaller

The quality of the release is a bit outside the scope of MB…

A quality “a” version delivers the same song as a quality “b” version. The experience is different, but not the song. Another quality version of a release is still from the same release. I don’t think that quality is an aspect that justifies creating a separate release entry.

@thwaller

A last comment … I would suggest that Picard add in extra precautions on removing any existing metadata (especially original metadata), and make the implications very clear on the modifying of existing (original) metadata. It is my opinion that changing the metadata is like changing how a CD cover or insert was printed. Once you remove it, it is gone.

That is very interesting and deserves its own topic. Is it possible to export all the metadata to a plain text file? That way I could match with Picard and still have a way to look back at the previous metadata.

[outsidecontext]

@Alex1

The digital album is a derivative of an album that was first released 1994-11-29.

An album that was first released as digital media is an actual release, though.

I think you confuse the release date for a specific release with the date the “album” was first released. Let’s take an album that was first released in 1975 on Vinyl. In 1995 it was released on CD. What is the date to set for the CD release? 1995, right? In 2005 it was made available the first time as a digital download. IMHO the date is 2005. Or what is the significant difference between the date a physical and a digital release is first available?

The original release of the album is of course is 1995 1975. But this is the same of all releases of the same album, and it is the original release date MB makes available on the release group level.

[kellnerd]

@outsidecontext

The original release of the album is of course is 1995

Now you’ve confused the dates yourself – but I still got your point.

[Alex1]

Hi. Glad to see you here, I was looking forward to a reply from you.

Your example is easy to follow – in theory. When an album first appears in the world in 2005 and it is sold in digital format, its release year is 2005. We can all agree on that.

In post #1 I adopted this point of view and showed (among other things) that the release event data filled in by a-tisket is just totally in the wrong place.

In post #4 I made that clear once again and then looked at the cases where a digital release follows after previous releases of the same album and how tracking availability could be more practical compared to viewing every digital offering in every store on the planet as a separate release, even though they refer to the same album. That just seems insane. I see no value in that.

OK. Let’s extend your example. The 2005 album first appeared on Spotify. How would you know when it was released? Give me a real-world example, if you have one.

3 months later, somebody notices the album on Apple Music. Does the appeareance on Apple Music justify adding another release to the release group? And again, how would you know when it was released?

[outsidecontext]

@Alex1

And again, how would you know when it was released?

Just like for physical releases labels and musicians sometimes put out announcements for digital releases, see e.g. Kirjaudu sisään Facebookiin | Facebook

Also some stores provide this date as well. Sometimes it might not be possible to track it down to the exact day or even month, but this is no problem specific to digital.

@Alex1

Does the appeareance on Apple Music justify adding another release to the release group?

I’m among those who think we should only have one release for a digital download available on multiple stores. Sometimes there are really different digital versions of one album, then it should be also multiple releases in MB of course. See for example:

Believe in Nothing

vs.

Believe in Nothing

[Alex1]

Your source of information - 7digital.com - is not even mentioned on the UI. Apparently the concept is to abstract from the seller as much as possible and fit digital media data into the same molds as phycial media data. I see how this can work with your example of “Believe in Nothing”.

I thought I was on to something. My frame of reference is Apple. (I’m always mentioning Apple because that is my focus right now and I have not researched the submission standards of other services).

Would you even add a digital album to MB, as I did, not knowing when it was released? Because without further research, that imperfection applies to all albums obtained through Apple.

Apple gives you the original release date (ord) and that’s what I have to work with when narrowing down a release to match with in Picard. I was thinking that the ord is helpful, because it might indicate that the digital files were mastered from the same studio recording as the album indicated with the ord.

When I wrote that digital versions are derivatives, that applies to every album that was previously released in another format. Wouldn’t it be great to know which recording was used to create the digital version? Well yes, and that is why I thought the ord is more useful information compared to the sales start date (which would be taken as the release date here on MB).

To stay with “Believe in Nothing”, we see that ord “2001-02-26” is actually in reference to the original 12-track album. The ord is therefore wrong, not helpful at all. Wow.

@outsidecontext

Or what is the significant difference between the date a physical and a digital release is first available?

I have already said that the “release date refers to the release of an album and has nothing to do with the format”.

The point is that most vendors do not regard the sale of a digital version as a release, if the album already existed (feel free to object). That is why it makes sense for Apple to not fuss around with sales start dates, which is just trivial data. What we wanna know is when the album was released, and that leads back to the original release.

So that is why I proposed to remove the pain of figuring out the release date and instead just focus on availability.

I regard the availability of information as a (significant) difference between physical and digital media.

You can hold the packaged good in your hands and compare to an MB release page. “Holding” a digital album in your hand entails going to the source of information - the metadata or the vendor, or label website, etc.

For testing, I just bought a song at the iTunes Store and there is an XID tag that includes the ISCR. Well, that’s something. With most files I am upgrading to iTunes Plus, I have much less to work with.

[aerozol]

I like the thought put into this, but I don’t know if this reshuffling of the UI really solves the core problem that I see:

Some people want to see just one ‘digital release’
vs
Some people want to store more granular information

I would imagine something more along the lines of (just a rough mockup as food for thought… don’t get into the details/weeds of these please MBers!):

[peterhbg]

I (as still a newbie to MB) would prefer a different approach for
a) the exact presentation of a digital release, perhaps divided in several unique releases on different platforms (soundcloud, Deezer, Spotify, AppleMusic …) and
b) the availability for buying and/or streaming on these platforms

I’m still not really into this subtle differences between different digital releases. I would like to see a unified info point for b) – and this should appear on the release group (!) page, because there I get all the info about the album itself, and there I would like to see if I can buy or listen to it on different service platforms.

Another solution would be in combining a) and b): Every platform get’s its own digital release, so we would end up in 5 or more digital releases. But then we need a column for the service title (as “AppleMusic”, “Spotify” etc.) in the releases overview of the release group page – otherwise I end up in clicking on every digital release until I get to my preferred service.

[Alex1]

(I should have broken down this topic into smaller pieces…)

The current system is actually amazing, giving you much flexibility. Look at Sound Mirrors, for example. Somebody added a digital media release about a 13-track version that was available on eMusic in 2008. This information can now co-exit next to the digital media 12-track release, which you currently find on iTunes, Spotify, Deezer, …

This is a case of sentence 2:

@outsidecontext

I’m among those who think we should only have one release for a digital download available on multiple stores. Sometimes there are really different digital versions of one album, then it should be also multiple releases in MB of course.

@kapomuk

I’m still not really into this subtle differences between different digital releases. I would like to see a unified info point for b)

I am more concerned about evidence for the data. I want to see where an editor took information from. With physical media, we can look at the packaging to verify. With digital media, we might actually need screenshots or snapshots of apps and webpages - see for example my annotation on this release of Sound Mirrors.