I’d say it’s incomplete rather than outdated.
a-tisket gets its data straight from the iTunes API, so it only shows whatever dates iTunes has. Often times when submitting an album to iTunes, labels will include an album’s original release date (or what they think is the original release date, depending on the age of the album) rather than the date the album was made available through iTunes, which is what we prefer here at MB. iTunes didn’t launch until April 2003, so a release date of November 2002 would not be appropriate for a release imported from iTunes.
For cases like these, I would either check a different source for a more plausible date (e.g. Deezer or Amazon) or just leave the date field blank. (You can do this by typing “0” in the “change date” box.)
What exactly is the purpose of the date box? (I am hesitant to try without knowing. How does setting a different date affect anything - which data source gets changed and is this a temporary change or a permanent one?)
iTunes doesn’t always have the correct date. Since atisket is showing a different date for iTunes than it is for Spotify/Deezer, I’d investigate.
https://isrcsearch.ifpi.org/#!/search?upcCode=696998623125&tab=lookup&showReleases&start=0&number=10 shows a date of 2002-11-19 as does both Spotify & Deezer. That’s the date I’d go with. That also matches the date of the CD release, so it’s more likely that date.
The purpose is to override the date give. Many times digital releases may actually have a date newer than shown because they sometimes use the original release date instead of the actual release date. If uncertain, check ISRC.net.
Thanks for the isrcsearch link as another way to validate.
I don’t favor this conclusion. The iTunes guidelines ask for the original release date.
In the case of This is Me…Then which we looked at here, there is different information out there:
Wikipedia: November 26, 2002 (United States)
Discogs: November 26, 2002 (United States)
fnd.io: November 26, 2002
iTunes: November 19, 2002
Fandom: November 19, 2002
ISRC Search: November 19, 2002
a-tisket shows 2002-11-26 instead of 2002-11-19, which brings me back to the question. If a-tisket gets its data straight from the iTunes API, as @HibiscusKazeneko said, then why is the date different?
The current iTunes album ID for the album “No More Drama (Version 1)” is 1440817211. a-tisket returns UPC 602547111470 for it. This UPC does not correspond with the UPC of the release in MB, which otherwise represents this digital release exactly (with occasional 1-second track duration differences though).
Btw, Apple has been changing the album ID numbers over time, and as you can check, the old iTunes Store link on the MB release page will be redirected to the current album ID.
So, I am thinking I should edit the release and update the UPC and update the iTunes Store link. But first, I would like to know from you @marlonob please:
Why do you think the barcode might be different? This album has been available from iTunes at least since 2007. Why would they change the barcode?
I am asking because I would like to have some reassurance that a-tisket uses up-to-date data sources and the correct data source. Reading iTunes UPC Database, I got the impression that it might depend on the copy of a database. How sure are you that the UPC is correct?
I can see in the editing history, that the release was added by @a23bed 2 years ago with a script. That too might be a source of error, and there is no information how this script obtains the UPC…
I think that is a potential problem with this (currently) closed-source script. I can guarantee that nobody using this is actually verifying every detail it adds, and nobody can see the actual code to make sure it’s doing the right thing.
I am definitely checking all information it adds. So, you can’t guarantee that.
Not sure why you don’t favor this conclusion. MB is not iTunes. MB wants the actual date of release for all releases, not the original release date. Apple only shows the original release date most of the time. This is not what we want. iTunes didn’t even exist before 2003, so there should be no dates returned before 2003. But of course there is all the time because they want original release dates. I get that for tagging purposes, but there are scripting in Picard, etc that can take care of that problem. When an iTunes ID is changed many times it changes the barcode as well. If a release is being forwarded to a new id, this is NOT the same release. The old ID is just no longer available and the link on the release should be marked as ended. It’s not a perfect system, for sure, but it’s what we have. Do not update UPCs. Instead create a new release with the date ISRC or other sources give. However, if the barcodes do match an existing release and only the Apple ID has changed, than simply add the new link and mark the old one as ended. Believe it or not, I’ve also found dates by simple Google search and places like Steve Hoffman or even Wayback Machine. If you are unsure and you know it’s not the date that Apple is giving on their page leave it blank.
You check to make sure every release is actually on every listed country’s spotify/itunes/deezer page?
The API is the API. If it says it’s available in a country. It’s available in a country. But to answer you question, I’m so anal about the data that I have created a Word file with every date that iTunes/Deezer/Spotify debuted in that country to make sure that it doesn’t say things like release date in 2002 in Kosovo, when Kosovo didn’t have iTunes or Spotify until 2020. The APIs only use one release date for every country. As far as iTunes, atisket is actually doing that very thing. It queries every countries page to see if it exists on that page, as they don’t list countries on their API.
Of course, that’s not to say that I don’t miss a mistake here and there that it might have. As I’ve said many, many times, this site and other import scripts, must be a tool to help speed up time. It doesn’t take away the role of the editor. We must still be diligent and check the data.
This is one topic, and certainly something I am reflecting on. About “most of the time” in that sentence: Could you give an example of a date that is not the original release date?
Anyhow, this is not the topic I have raised here. This is the a-tisket thread, so I’d like to stay on topic and I will make a third attempt to clarify the issue I see.
After you run a search with a-tisket (link):
That is not the date provided by Apple (link):
For more examples of mismatching dates, see post #136.
What could be the reason(s) for this mismatch?
- a-tisket does not return the original release date
- a-tisket does not even use Apple API to find the release date
- a-tisket uses Apple API to get the release date
We know for a fact, that Apple makes the original album’s release date visible. If they keep another release-specific release date variable invisible to the public, but available through their API, and a-tisket gets this variable, all is fine. I just would like to know!
I am not going to pay much attention to second-hand opinion. It is the developer’s response I’d like.
The displayed date (2018-06-29) is the one returned by all of the three used APIs (links directly taken from your cached results page): Deezer, Spotify and iTunes.
In addition to this date the iTunes API also returns the original release date (2001-02-26) for each track:
{
"resultCount": 15,
"results": [
{
"wrapperType": "collection",
"collectionType": "Album",
"artistName": "Paradise Lost",
"collectionName": "Believe in Nothing (Remixed & Remastered)",
"releaseDate": "2018-06-29T07:00:00Z",
[...]
},
{
"wrapperType": "track",
"kind": "song",
"artistName": "Paradise Lost",
"collectionName": "Believe in Nothing (Remixed & Remastered)",
"trackName": "I Am Nothing",
"releaseDate": "2001-02-26T08:00:00Z",
[...]
}, [...]
]
}
This is the one that’s diplayed on the Apple Music page you linked to (and which is not the one that should be used on MB).
This is actually one of those examples where I would find it especially problematic that Apple shows the original release date. Yes, this album was originally released in 2001. But the 2018 rerelease was completely remixed as the band never was happy with the original sound. It also got a new cover. So in my collection I clearly want to see if it is the 2001 or 2018 release I’m listening to. Luckily atisket gets the correct date on import even when Apple shows the original album release date in the UI.
a-tisket doesn’t return the original release date because we don’t use that on MB. It’s irrelevant. It does use the iTunes API, which is not the same as the Apple Music API (but I doubt they would give different results on dates). However, you are correct that even the API isn’t always the correct and true release date. It’s an issue with Apple more than a-tisket, IMO. Marlonob doesn’t seem to be very active on the community boards, but I have sent him personal e-mails through MB that he has promptly responded to. It’s his site. He does post a link to all APIs used on a-tisket. You can see for yourself that the dates that a-tisket shows are the dates that the APIs show. Deezer dates seem to me to be the most accurate. They correspond more often to IFPI (soundexchange or ISRC.net) than others and often time don’t just show the original date of the release.
Why do you say that? I want to soften that statement somewhat: a-tisket returns what the API returns, and in case of the iTunes API, the date represents the original release date of the album. With other words, it should represent that, if no human errors were made while submitting the information to Apple.
From the “Believe in Nothing” example, we can conclude that a-tisket takes the date from the first object of the JSON “results” array, as you would expect. OK. As @kellnerd pointed out, the tracks have their own release date info (which I had not payed attention to - my fault) and it happens that Apple is wrong to show “26 Feb, 2001” as the date.
I am ready to follow the convention at MB to use the release date specific to a release. (I wish the introduction would put more emphasis on this.) So, for example, I just added:
I allowed the release date 2008-05-19 filled in by a-tisket to remain, because I am quite confident this is actually the release date of the digital version.
However, I have retrospectively removed the release event data from:
because I only have information about the original release dates.
There is one thing I want to say:
Because a-tisket fills in the data to help you add a new release to MB, I suspect that some editors will just go with the given dates, that is - they will be submitting original release dates, thinking that is ok. When I first noticed this, it was upsetting. It took me a while to change my judgement from “it is wrong of a-tisket to use this stuff as release events data” to “I should review and change the data as necessary”.
I would like to suggest: Add a word of caution under “RELEASE DATE”, something like this:
“Verify that this date represents the release date of this particular release, rather than the date of the first release event for this album. Before submitting this release to MusicBrainz, you can change the date right here, though you can also edit it later at MusicBrainz.”
I’m trying to import a large (100 track) album from Spotify, and the tool keeps hanging. Can the timeout be increased to support the import?
album: https://open.spotify.com/album/4A0cgtw7ylPOItopuwDTFE
One way to avoid that is to set it to ignore vendors other than the primary one you’re using (in this case, Spotify). Then later, if you want to check other vendors, enter the UPC, set your preferred vendor to Deezer or iTunes and set it to ignore the other two besides your selection.
Great advice! Disabling the other two providers worked like a charm, not only did it import the album, but it also handled all five mediums as well. Awesome!