Digital releases

MusicBrainz
,
73

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.

3 Likes
74

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.

3 Likes
75

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

1 Like
76

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

77

I’ve added format options to some URL relationships (but only on test.musicbrainz.org). You can try them out by going to an edit URL page such as https://test.musicbrainz.org/url/b6a1f92c-4eb8-46a3-8444-c9ce16154da2/edit
fip2f2pij

2 Likes
78

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)

2 Likes
79

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.

80

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.

7 Likes
81

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
82

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
83

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

1 Like
84

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.

3 Likes
85

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.

4 Likes
86

This is my thoughts as well. There is so much detail tracked for physical releases, some of which really don’t make a difference, like this one has the insert printed in US and this one in UK. I see why that information is great to have, but it is a lot of extr work to make it useful, especially the need of images to make it really meaningful.

With digital releases, the format (MP3, M4A, etc) is in my opinion the same as a cassette to a CD to vinyl. It is the delivery medium of the release/recording. As a Linux user for example, M4A files give me difficulty at times whereas MP3 is nearly problem free. I can relate that to needing a cassette deck for cassettes and a CD player for CDs. The different formats of a digital release determine what you need to use that file.

In reference to the barcode of a digital release or recording, I find it secondary information vs it being primary for physical releases. For a digital release, I find the STORE part number far more useful. Using iTunes, which is quite popular, the iTunes ID will get you to the release you want quickly, assuming it is not discontinued (they do not retain history). But when it comes to a barcode from iTunes, there is no direct references to any barcode.

It is my opinion that if you look at a release from an artist, an indication of Digital -> MP3 does quite well to direct me. Yes, that MP3 can have different bitrates, different barcodes, different stores, etc, but at the end of the day, what really makes it different? Aside from the bitrate, it is basically all metadata. While metadata is the ideal identity of a file, there is an issue. If I purchase an iTunes release today, and in 2 years time, purchase that same release again, the metadata will not match. So it is my opinion that you need to look at the metadata and determine which pieces actually make the file different from the others.

I might think of a entry like this:
Paul Simon - Graceland
Digital -> MP3
Sources (where each source would have an associated bitrate, etc - like say 320, 44.1, etc, maybe a source barcode, etc)
Tracklist and etc.

1 Like
87

Just a funny, messy pop release to add to the neverending story of digital media handling here on MB…

I’m sorry if I chose the wrong “digital media” thread, but there have been just so many throughout the years :wink:

  1. Aluna Francis previously from electropop/lovestep duo AlunaGeorge went solo and released her debut on a quite established label Mad Decent:
    https://musicbrainz.org/release/fda9bbc7-4dd1-48c8-8f6f-aecd4275cbad

  2. What we have on MB pretty much follows the Bandcamp listing, except for tracks 2 & 7, where BC-not-mentioned “SG Lewis” and “Rema” appear as featured artists: https://alunaaa.bandcamp.com/album/renaissance

  3. But then we move to her official SoundCloud: https://soundcloud.com/aluna/sets/renaissance-440881527
    And suddenly 2nd and 8th tracks seem to be credited to the old duo, “AlunaGeorge”, whereas in the last track we have a previously not mentioned artist, “Mr. Carmack”.

  4. The streamers, Spotify and Apple Music (https://open.spotify.com/album/0cFJfTwmx4KOM9zEy9i2nB, https://music.apple.com/us/album/1522795234) are almost the same, except iTunes doesn’t recognize “feat.” artists as recording ones, while Spotify does so. The old duo “AlunaGeorge” is no longer mentioned, but I suppose that may have been some nostalgic mistake on Aluna’s SC account.

  5. So what about digital download stores? JunoDownload offers yet another view on the tracklist: https://www.junodownload.com/products/aluna-renaissance-explicit/4721994-02/
    “Mr. Carmack” clearly should be credited in the last track, however “SG Lewis” was completely ignored in the track number 2.

  6. In the end, something more tangible, the physical release. The sources for that would be Mad Decent’s store listing (https://shop.maddecent.com/products/aluna-renaissance-2xlp-digital-album), Juno vinyl store listing (https://www.juno.co.uk/products/aluna-renaissance/785882-01/) and the tracklist from Genius, which is (I presume) taken from the vinyl back cover (https://images.genius.com/ec04d10889e2e8e3800646d217cf6b4e.1000x1000x1.jpg)
    Conversely to JD track list, “SG Lewis” was kept in track 2 on the vinyl cover, but “Mr. Carmack” is absent in the final track. We also have a different set of join phrases here, as track 6 is with “Princess Nokia” while track 7 was prod. by or produced by “Kaytranada”.

The cherry on top is the fact that Juno claims the vinyl is released by Because Music France, but bears a Mad Decent catalog number, MAD 496V, whereas Juno Download claims the digital is released by Mad Decent US, but it bears the Because Music catalog number, BEC 5676247.

…

So who’s right, who’s wrong? :wink:

2 Likes
88

If I did all that research and checking I would add a release for each of them.

And the world would keep turning :stuck_out_tongue:

89

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!

90

@ 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
91

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.

2 Likes
92

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