A multi‐source seeder for digital releases

I found a couple of streaming services we could potentially add support for:
http://music.migu.cn/
https://y.qq.com/

1 Like

Spotify has updated their country list again.

If editors have noticed the past couple of days of a blank country being added by the seeder, that is Kosovo. Which isn’t on the country availability pull down list on MB. That needs to be added. I reopened (https://tickets.metabrainz.org/browse/AREQ-269), but I’m not sure if area request is where this change comes from as that is typically just places for relationships.

3 Likes

A second ticket is needed to add release countries. I made one for this case:

@marlonob will have to update the “countries where available/excluded” automated message to include Kosovo and any other newly-supported territories.

It already shows up on a-taskit for Spotify. I guess because it’s straight from the API. Though I don’t think it does for iTunes which he probably needs to add to his query.

1 Like

When a search with an iTunes album ID reveals a release date that differs from the date (year) on the album page, can I conclude that a-tisket’s data sources are outdated?

Invisible Girl: 2000-02-10 is not on the album page.

This Is Me…Then: 2002-11-26 is not on the album page nor on the MB release with that UPC.

The Look of Love: 2011-01-01 is not on the album page.

1 Like

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.)

1 Like

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.

2 Likes

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.

2 Likes

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.

2 Likes

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.

5 Likes

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.

5 Likes

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):

Screen Shot 2020-08-05 at 23.21.24

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).

5 Likes

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.

6 Likes