By the way, recently I also discovered why a-tisket does not set the release event to just [Worldwide] in some cases although there are no excluded countries listed at all. This happens e.g. if a release is not worldwide on Spotify but worldwide on Deezer, in a way that the missing Spotify countries are available on Deezer.
However, the code checks whether all queried vendors are worldwide, not if there are no excluded countries.
As a first step I changed the “Only a few countries have been excluded from the release” message (which is confusing when there are no excluded countries listed below) to “Only a few countries have been excluded from the release (by at least one vendor)”.
I think we should also change the behavior and set the release event to [Worldwide] in these cases nevertheless, what do you think?
I can address this straight away.
810026072734
810026072710
810026072697
810026072727
810026072703
810026072680
Maybe you can find a release that actually has these barcodes in the metadata?
EDIT: To clarify, those are 6 legit barcodes for the release I mentioned, both the clean and explicit versions, and broken down by the ISRC that I listed… Which releases are these tied to?
EDIT2: I should also clarify I have no interest in indexing streaming releases. Please do take my statements in relation to actual ownership based releases. For the streaming, you can have a barcode for every radio station or whatever, to me it is all the same.
Just because this is absolutely not clear for me from your previous posts: would you consider this just one release in MB, or 2 (explicit vs. cleaned) or 6 (one per barcode)?
First code isn’t on iTunes, Spotify or Deezer, so no result was found. ISRC reports barcodes for other services as well and even other medium types. Second code is seeded above, to give new release that I just added for you: Release “Deception Szn 1” by Angelica Vila - MusicBrainz
Not sure what else to add to this. I know other than the barcode, the releases are basically the same, but the barcode is enough to make it a different release, just like it would be on a physical release. If editors say a pressing code is enough on a physical release to be considered a different release, I’m really not sure why a barcode wouldn’t be enough on a digital one.
Also, just because a release is streaming doesn’t mean that it can’t also be purchased. If the only difference is streaming vs. purchasing but everything else is the same, it’s still the same release, just on a different service.
One of the very few issues surrounding the submission of digital releases where there appears (to me) to be a significant consensus is that a separate barcode equals a separate release. So can we not expend any more energy relitigating it?
Also, the repeated mention of ISRCs in the context of barcodes make no sense to me. Barcodes are a release level attribute and ISRCs are a recording level attribute. It’s perfectly possible for a recording with a given ISRC to be included on multiple releases with different barcodes. ISRCs can be helpful with regards to identifying releases, but only under very specific circumstances.
Also, can we try to keep this thread on topic please? If you wish to continue the discussion could I ask that you post on this thread:
I see the release, in reference to the 6 barcodes I provided as 2 releases, 3 bar codes per. The bar codes are sort of irrelevant to me as they relate to nothing of value, but here the bar code is a new release indicator.
There seems to be some confusion here as I agree with you, the ISRC is recording and the barcode is release. What you stated here has no disagreement at all. In fact what you say is becoming more true than ever before, the cases where a recording is assigned multiple ISRCs is far less than it was historically.
My intent on originally posting this here was made clear, but is overlooked. i was suggesting to add in the pulling of the bar codes I mentioned, which is currently not don in this tool. I then provided an example on why it would be useful vs just saying “hey add this”.
I believe the difference here is that many barcodes are never referenced in store fronts, replaced by a different barcode. As @atj mentioned though, the details of these items are not really for this thread, and I agree with that. Again, these details on this release were added to provide an example to support my request of adding in a resource to obtain barcodes, since that is what people here insist makes a new release. For that to work, people need a way to query and get these barcodes that often do not appear anywhere on releases or stores, referencing the ones I listed, not the ones obtained from the three in this tool.
This is frustrating to me as the system currently with majority is very unusable to me. It would help if more barcodes could be referenced from other sources so the barcode could be more relevant, but this will not help me, or any other, identify a release in hand at all. While I disagree with using barcode for digital, I am trying to work with that decision.
No problem at all. It appears to me that one issue is that there is so much conversation on this, and it is spread out and fragmented, it is very easy that things are missed, left out, incorrectly assumed, etc.
Also with the statement if ISRC and bar code, I believe that is another that just ended up confused in the mix simply due to lack of structured conversation.
Yes! These barcodes specifically are from the ISRC database, https://isrc.soundexchange.com/. While I have no solid proof of statement, I was led to believe that these barcodes are not actually different releases than that which the retails sell, but the barcodes get changed along the way as distributors, vendors, etc see fit… in a similar manner that vendors apply their own part numbers to things. NOTE: This does not apply to physical releases, the barcodes on those are clearly on the physical product and stay from the manufacturing of it to the end (in most cases that is).
I would like to make a comment about this statement. Barcodes are something arbitrary at the end. When reissuing our releases on digital media we choose use the same original barcodes from our original physical releases It was a convenience because our physical releases does not exist for retail sale anymore and because generate a new barcode for something digital do not make any sense. So, two equal barcodes does not mean the same release at all.
No one is saying that only the same barcode is the same release. We are saying that a different barcode means a different release, not the same. If all barcodes, labels, artwork, number of tracks, etc are the same from site to site, than we say it’s the same release. And while in the beginning of digital it was common place for digital releases to share the same barcodes as CDs, it’s becoming much less frequent and is only really seen anymore except for maybe the some indy or self-distribution releases. Yes, most digital releases have barcodes. No, they aren’t just randomly given by the retailer/stream service. If they are not the same, than they are not the same release. Period.
Any chance writer and producer credits from Spotify could be included somewhere? Perhaps on the post-submit screen? API endpoint (currently, at least for me) is https://spclient.wg.spotify.com/track-credits-view/v0/experimental/{track-id}/credits. The only required HTTP header is the auth token.
The responses also seem to contain more information than what is displayed in the credits modal. It seems these writers and producers have a Spotify artist page, even when they don’t have any tracks on which they’re the artist.
It’s possible that some of this information may be inaccurate, but for many digital releases, it’s the only information we have.
I hope this is the correct place to report this bug. I don’t do digital uploading, but the script needs to be fixed to avoid obvious errors in the data.
Obviously that Digital Album was not released in 1981, but there is the release date on Apple’s website. This then got imported as 1981 when the digital release is clearly much later.
Deezer and Spotify have the more logical 2005 dates.
With re-releases like this, there’s usually 2 dates provided by Apple/Deezer/Spotify/etc, the original release date and the re-release date. A-tisket has an option to change the release date if you know it’s wrong, and it’ll say the date has been changed in the edit note when submitting.
The “option” is no good if it is uploading bad data like that. This one is obvious due to the huge gap, but other times it will be more subtle. Can this script not use a bit of logic and pick the NEWEST date as this will usually be the correct one for the digital? Or at least put a much more obvious warning up for the uploader when there is a difference?
Or plain ignore Apple now they are giving data not connected to the Digital Version? With THREE sources like that script has it should be able to compare and drop the one that is different.
People trust scripts like this too much and often don’t even look at the data. Clearly if this uploader had looked they should have known that 1981 was all kinds of wrong and not only did none of these companies exist, we didn’t even have digital CDs at that point
eh, people have put in the wrong year for cd’s for aages.
on the flip hand, i do believe that MB has a warning for early digital and early cd, but I think you can ignore sometimes,I suggest pebcak here.
That is not an excuse to continue the bug into the Digital world And I thought there was now a block to stop dates like 1981 for CDs?
This surely is a bug in the uploading code. When there are three dates available, why can the routine not discard the clearly bogus one? Yes it is PEBCAK, but the users mistakenly trust this digital script. they have to actively type in a bad CD date, whereas they are more likely to trust a script as correct.
If Apple sends the original release date for old albums rather then the digital date it does make their dates a bit useless… at least any digital Apple dates pre-2003 can be safely discarded (If we’re being generous and look at when the iTunes store started), otherwise pre-2015 (Apple Music start).
In the … menu on each track on an album page of open.spotify.com there’s a “Show credits” option. Inspecting the network requests via your browser’s dev tools when clicking it shows the requests, from which you can find the endpoint. AFAICT it’s not documented anywhere, and since it says “experimental” in the path, it’s probably internal and will may/will change in the future.
And I thought there was now a block to stop dates like 1981 for CDs?