With editors using Deezer references for releases, and using them to create releases that are different only by Deezer data points, how does MB approach this? Deezer links, those used for album references, are not public access. This is my finding, I may be wrong, so please correct if this is not the case. I have clicked on many of them and just get redirected to their home page. This males these references useless to me as a normal user. To view them, I need to subscribe. There is a free version I believe, but you need to sign up for a trial first to get it.
Point being that these releases/references, without some other reference to verify all the data, is of no value to normal users and cannot be archived for the case that it might be taken down as access to these pages and data is restricted.
Yes, I agree with that. I may have not been clear enough thoughā¦
I mean where in the release references section, the reference for the release is a Deezer release. It has a barcode from Deezer, etc and is listed in notes as not a dup of another due to Deezer barcode difference. As an editor, this is problematic for me. If I want to merge a recording, edit a release, etc, nothing about the release is available to me at all. With physical releases, I can lookup the barcode, do to the label, etc and see info about the release to see what it was. I can āshopā the release. Same with iTunes. I may not be able to go into iTunes and buy it, but I can view it in the store, so I can āshopā it and see what it is. With Deezer, there is nothing available, at all.
So, maybe these releses need to be marked in some way, lkike those that are āMastered for iTunesā as they will never (at least at this time) share any other references? Any time a Deezer reference is used, and the editor is not a Deezer subscriber, I really cannot involve anything with a Deezer reference as I cannot ever see what anything is.
This is getting into the digital issue further where there are just no guidelines. We are mixing Amazon and iTunes which could very likely have different barcodes, and now using Deezer links (with barcodes) and mixing some in and keeping some separate. We have no way of knowing if these are barcodes specific to Deezer, used by other retailers, etcā¦ so it kind of creates a need to have Deezer releases always a separate release in that sense. Maybe I am missing something?
I always err towards creating new digital releases and disambiguating them if I donāt have access to all the information from an existing one/storefront.
I think itās where MB style will eventually go, but until then itās up to the editor I suppose. Some editors donāt care, we do, so inevitably thereāll be a mix of approaches.
That makes sense. I was hoping there would be a more formalized guideline by now, but I guess not. It would seem to me that leaving the guideline āfreeformā will just create more inconsistency which will create more work to clean up later.
In regard to me and my collection, I find MB more technical on physical releases and way less technical on digital releases, which just seems odd for a goal of music identification unless it is sticking with physical releases as its focus. I do not use Deezer at all, but I have a lot of iTunes filesā¦ and I can say that if I leave the tags as provided by iTunes, my tags are in better shape than if I tag them in Picard. I just wonder if MB is obsoleting itself by not advancing with technology, I mean the MP3 file has already been ādeclared obsoleteā by its founder Fraunhofer, and MB has yet to have guideline on how to deal with a digital file at allā¦
Anyway, I think I am agreeing with your statement, that digital releases should be much more separated. I think a UK and US, NZ, etc iTunes store mix would be fine, but store differences like iTunes, Amazon, HDTracks, Deezer, etc, they are all different releases in some way as it relates to digital. So much that I will delete an Amazon release if I can get an iTunes release, etc., that is a big difference as it dorectly impacts the product itself. The only solution at this point for as you stated, editors that care, is to stop caring. Not that we enter junk, but a goal of quality and consistency is impossible at this time.
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.
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.
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
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?
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.
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.
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?