I am actually discussing with an editor which used a Deezer reference on this topic. I am unable to view the album via link provided, but he is. So I am hoping we can find out why this is and resolve this issue. Neither of us are logging into the site, so there is more going on there. I will share the results should they have any use.
1 Like
As stated, the results are revealing, so I wanted to share them. The edit in which this was discussed is here:
https://beta.musicbrainz.org/edit/50187374
The results show that IP addresses that come from the US are not allowed to view the album page used in that edit. If I use an IP from UK, Netherlands or Singapore, the page will display as the proper album page. So I can only conclude that Deezer is not allowing US visitors (or those with a US IP) to view their pages.
I believe this is something that should be considered in digital releases. The distribution is at least limited for the US, as I cannot even shop the store without (assumingly) signing up for a free trial account, which I also assume will require my CC or other payment info.
1 Like
Another example is HDtracks (1.2K URLs in the MusicBrainz database) which does not sell (and is not fully browsable) outside of the United States. https://www.hdtracks.com/faq#19
3 Likes
Interesting, thanks for sharing that, I was unaware of this.
I can understand the not selling by country, so I guess if the site provides samples, that cannot be displayed as the content is prohibited to that country. It almost seems like references should be added in the same as release events, where a reference is added to a release event. So then, a Deezer reference could be added to a FR release event for example, thus making the Deezer reference only valid for the release events it is assigned to. In this case though, I would think this is not a additional release event, but a separate release in the release group, just the same as a physical CD in US vs FR. Instead of the barcode and catalog number being different on the CDs, we have metadata that differs and stores that sell and/or allow visitors with possible barcode differences too.
Is anyone looking into this stuff? It seems that this data is there for many, but is not being captured reducing the quality of digital releases represented in the DB.
That MB guidelines seperate two CDs with a slight cover misprint, but will happily merge digital releases that are 128kb and Flac, is short sighted to say the least.
When it has come up the editors who don’t care about digital data say “I don’t care about this data”, and then no consensus is reached.
But if you want to put together some parameters for new digital releases, eg different barcode, release country, format, storefront with no available information/can’t compare etc, that can actually be put into the style guide and be decided on, I’m not sure if a specific discussion has happened before? Might be a good idea.
This is exactly one of my points, but you have worded it a nit better than I, thank you. I also agree on the editor standards, there are editors right now that are ignoring guidelines despite notifications to them, etc. There is nothing that guidelines can do to fix that, only admin action.
I would love to put together a style guide start for this. I think one issue is that I, and others who have mentioned this, just assumed that the ruling powers have been in process with this. If that is not the case, I would much rather try to help than complain 
Is this something that would be done in a new topic here, or is there a special place for something like this where collaboration is more structured?
1 Like
Admin action against what? It has never been agreed or made official (to my knowledge) that different digital media releases shouldn’t be simply merged.
I think what needs to happen is a new discussion with:
- What can be agreed on to constitute a new release with digital media - eg cover art (easy), format (this is going to be contentious), different release country (very tricky), different barcode (easy… actually probably not - does iTunes always get a new release even though we can’t see the barcode?)
Then we can confidently add or split digital media releases without getting into edit arguments.
People can still add digital releases all together, but there will be an understanding that adding them separately is not “wrong”.
Following on from that:
- If there is an appropriate place in the guidelines and/or docs to spell out what these differences are. I thought I would find a good example in the guidelines, but not really. Here are the relevant pages that I found:
Release - MusicBrainz
Style / Release - MusicBrainz
The only distinct mention of when to create a new release is under cover art, which is generally a good loophole to add new digital releases (that have different cover art).
2.5 What the text should say, how prescriptive it should be, and where exactly it should go.
I’ve actually been meaning to start that discussion for a while but haven’t gotten round to it. If you want to pick it up and see if it can get somewhere that would be awesome
This is a past discussion that I started and got nowhere:
I think we just crossed waves. I was referring to users not caring and/or not following guidelines. There is nothing we can really do but accept the fact that such users will exist. Should such behaviour violate anything, the only possible action is admin action to resolve such issues if the user is not responsive to notes or messages from their peers.
Let’s say you are able to download tracks in 5 different quality settings from a site like Bandcamp (192, 256, 320, vbr and flac), would this mean we need to have 5 different digital media releases in MusicBrainz?
My opinion would be no, the release would be a FLAC release… I personally see it no different than me taking a CD and ripping it. I do not call that a digital release, as it is derived from the real release. Same as if I were to buy a FLAC from HDTracks, then convert to MP3s or M4As, it is still a digital FLAC release.
No, I don’t see why anyone would want that.
In any case we don’t need to have any separate digital releases, just like we don’t need to have seperate releases for different colour vinyl. But a consensus that splitting the releases where a user wants to is allowed would be very helpful to me, and encourage me to add more unique digital media releases.
Ideally we would be able to have digital media sub-formats, and be able to assign more than one to each release, but that’s just wishful thinking.
1 Like
I am not sure I can verify this statement, so I will call it an assumption… Many of those are nothing but a FLAC with a quick conversion to present to the customer. So the release is actually a FLAC, and if you want a MP3 320, it will convert them and give them to you. Also, for those that actually know the differences in such files and care about them, I am not sure such a person would ever download anything but the best option available. I would assume they offer such options for those who are unaware of the workings of conversion to lossy formats. If I would want a BandCamp release in MP3 320 format, I would download the FLAC and make it myself… because
- If I want a M4A later, I can easily do that
- I am quite sure I can produce a better MP3 file from the FLAC than the one I would download.
An example of this are the many YouTube converters out there. You can download a YouTube video (or other) to an MP3 and save it on your computer. Thing is, most of these sources are not at all MP3 encoded, but are actually OPUS or AAC within the webm file. So in these cases as well, you are getting a system converted product handed to you derived from the actual source. My point in this statement is only to show that systems automatically making conversions on demand is a fairly common thing.
So, I would call that a FLAC release. But if the same release is at Amazon, I would call that an MP3 release, and in the same, iTunes an AAC release. Then as aerozol has stated, we could (should) have subtypes. Something like a quality identifier (low, mid, high) to show the general quality of the file.
Off topic a bit, if MB would be open to a more significant change, one could add a release (one release) and editors would have the ability to add releases matching the release date, track listing, etc… but you could add references with attributes. So under this single release, I could add iTunes as AAC v256, Amazon MP3 c320, HDTracks FLAC 16bit, etc. This would both provide a less cluttered release group and provide a solid record of the attributes of the individual store front releases.
I think this muddies the water* a bit. Why do we have to decide what format exactly a Bandcamp release is?
I think the main thing (for me anyway) is should/can we split different formats/digital storefront releases.
*For example, why call a Bandcamp release FLAC and not WAV? And I would personally be against adding a ‘quality identifier’ as opposed to specific formats. Perhaps if the identifiers where ‘lossy’ and ‘lossless’, but even that might prove to be shortsighted as digital formats continue to evolve. I guess the point is that I would be careful of opening possibly bottomless cans of worms in the same thread 
Re. adding different references with attributes, I think the current system is fine, because it lets us tracks other notable things such as different cover art, different release dates (some day someone might want to know when a band made their release available as lossless digital), and country restrictions for releases. I even find it interesting to track subtly different track titles across different releases… but maybe that’s just me!
If there were to be a distinction category of lossless and lossy, I would call it lossless, not FLAC or WAV. But if you look at it differently, it does not matter, since you can, theoretically, covert between lossless formats with no loss of musical bits. So it really does not matter, but in this case, the actual files provided are in fact FLAC files. But if you wanted a WAV (which no online store I hope would ever sell), just convert it. Same for APE, ALAC, etc. So I would think lossless itself is just fine, although it should be marked somewhere that the reference provides FLAC files. The reason for this is that for some people, it matters. Not all systems/softwares/etc can read all formats. To those people a FLAC vs a WAV is the same as a cassette vs 8track. It is a different container holding the musical product.
I know how those formats work and what they are…
Bandcamp does ‘sell’ WAV’s, which is why I mentioned the issue. You prefer FLAC and want to know if something is FLAC, but some people will want to know other things.
Which is why it’s a bad idea to specify anything except for the exact format/s and bitrates available. I don’t see a need for the database to simplify things instead of just calling it exactly what it is, which caters to everyone’s needs, and removes the need for any discussion of personal preference, guesswork, or pages of discussion and guidelines.
I did not know Bandcamp provided WAV files. I do not use them much, but for the times I have, it has always been FLAC for the lossless option.
My statement was on that interpretation, I would call it FLAC because it is FLAC. But is a specific Bandcamp provides a WAV, I agree it should be called a WAV. There are a few different types that could be offered, there is about half dozen formats that can be used, I would tend to agree that the type used should be defined as a sub of Lossless. WAV is sort of outdated for distribution as it is uncompressed, which is wasteful on storage and bandwidth. But if sources do exist from sellers (including “sellers” of free material), then it should be described as such.
1 Like
https://www.beatport.com/ sells wav and mp3 files.
It is a little annoying to need to convert this to flac but occasionally they are the only store where I can buy a lossless recording.
I am a bit shocked that Beatport would sell WAV files, but I do not use them for anything so I cannot say much. It is shocking though… the image I have of the company is modern and advanced in technology. Yet here they are selling WAV vs FLAC or really any other compressed lossless, and MP3s which are technologically obsolete. Good to know though, thanks for sharing.
I was really surprised to find out that an audio engineer I know prefers wav.
I don’t know why, but I do know that he knows what he’s doing. But it might be hubris to assume that people (or entire store fonts) who use wav simply know what they’re doing.
If you have the HDD space I suppose there is no difference, perhaps a step less of encoding with wav…
1 Like
I do not want to speak for those on that side, but that makes sense to me. When you are doing audio editing, you will be editing in an uncompressed format, typically WAV. For me, if I am going to sample audio in another track, I will be doing this work with WAV files. So if my audio is stored in FLAC format, I am decompressing this audio to WAV to work with it, Same is true for audio analysis tools, Some of these tools only accept WAV and some of the tools will decode the compressed format for you so it can use the WAV. The thing to remember is that a compressed audio file needs a decoder to work. Sort of like those clothing vacuum storage bags… you can store all your clothing in much less space, but to use your clothing, you need to release the vacuum from the bag in order to get the clothes.
The big difference is who the user is, like pre-production or post-production. People like your friend will not want to ever use a lossy compressed format like MP3 or M4A since sound quality will begin to deteriorate quickly from generation loss. Maybe others have a different view point from other areas of the industry, but this is mine from where I use audio.
1 Like