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.
my point here is that it’s whoever imported the release’s fault. not the scripts/tools fault
sure, we can improve the script and make it better/easier to not do wrong, but the onus is always on the editor to enter correct data, not on the tool they use (unless the tool is malfunctioning or introduces errors) you could argue that’s happening here, but since it is the user who is choosing the “wrong” date, that isn’t so, imho.
Myself I haven’t used this tool because i don’t understand how it works (and also I don’t usually work with spotify/itunes etc) precisely because I don’t want to do introduce any errors (and also because I have yet to need it, but that’s a different thing. 😸)
This is especially true since MB has now warnings to help prevent these kinds of things. the user is the one to blame for failing to use the correct date, failing to heed warnings in mb and probably just doing thinks quickly without noticing errors. it can happen and it’s easily fixable.
For what it’s worth, we don’t have warnings for early dates for digital because we don’t know what’s the earliest legit digital release. Probably something amateurish in the early networks of the 70s or 80s
fair enough :D
but maybe we can set a date of “probably only special cases before this date” warning?
like "the date is a very early date for digital, most releases are probably after $YEAR -ish, are you sure this is the right date?
since in the wast majority of cases, a 1970 digital release will be wrong.
I also don’t use this tool or do much digital editing, but the tool must help in flagging up this clearly bad data. The users are not checking the countries, so why are they going to check the date?
I agree it is PEBCAK - but this is no excuse for the tool to create bad data when it has three sources it is bring in dates from. If iTunes is now doing data that is not compliant to MB guidelines, then it should be flagged up as needing to be checked.
If three sources have different dates they that needs to be in big flashing lights are part of the import to be checked by the user.
@CatQuest - I guess you don’t work with many normal users if you think everyone is checking the data this script it producing. Like you I would like to think they are, but clearly they are not.
In this example the date was 1981 - way before most of these companies existed and certainly before anything digital was being sold. If the user failed to see a 1981 error, then they won’t notice errors in dates in the 21st Century.
Yeah, that’s fine and MB is correct with that. This is not a MB issue. This is a script issue. This is a script adding something from 1981 was supplied by three stores that did not exist at that time. This is why it should be a script issue to fix.
For the script writer, would it be that hard to add a line that checks if (Deezer date) == (Spotify date) == (iTunes date) and if there is a big difference to discard the date with the largest variation from the average?
Nobody’s saying that the tool is at fault, but the tool has many many excellent features to make editing life easier, far above and beyond what I would have expected. So it doesn’t feel unreasonable to ask/advocate for something like this
… this is exactly my *point* auuugh…
look this is pointless. I’ve said my bit.
aerozol: no actually that’s exactly what’s being said, that the tool is at fault.
my gripe here wasn’t that improvements were asked for or suggested, but insultingly demanded.
as an aside; just today I had to go and correct something I had imported using a Tool, the bandcamp importer.
I neglected to check script/language and had to go back and fix it.
it’s that simple. human error. tools are tools. not AI.
SURELY they can be improved, and should be.
but these are improvements, not " the tool create(ing) bad data "
EOM. I’ve said my bit, I won’t reply further.
I am very sorry if you think that was an insult. It was not supposed to be in any form an insult to anyone in any way. You have misunderstood my meaning here. Sometimes I just care a bit too much about the quality of the data.
Again, I am very sorry to anyone I may have upset by these comments. That was NEVER the aim.
And I thought there was now a block to stop dates like 1981 for CDs?
