Why did the song Ids change? [explanation inside]

I have saved in a local JSON file some song IDs (So I won't need to call the API everytime I test stuff in my player), and I see that a lot of song Ids have changed and no longer point to their songs when trying to play them via MusicKit, nor when trying to access the metadata via the Web API


What I'm asking is if there's a way of still being able to get songs metadata with the old IDs? (because for me a change of Ids will be very problematic with some of my future features...)

Anyway, here's a couple of songs with their old IDs and their new ones: (You can try and fetch metadata or try to play them with the old Ids, but it won't work, only the new ones work)


Wonderwall by Oasis, old Id: 1456844334, new Id: 895279610

Don't Look Back In Anger by Oasis, old Id: 1456846387, new Id: 895279611

there are more then 10 other songs that I know of, but I don't even know if someone from the MusicKit SDK team will see this so IDK what's the point will be in naming all of them...

Up vote post of 0132 Down vote post of 0132
837 views
Posted by
0132
Reply
Add a Comment

Replies

Unfortunately content with specific ids may become unavailable as rights change or content is redelivered to the catalog. It is not possible to completely rely on ids that are saved off to a separate file.


Looking into your first example of "Wonderwall" by Oasis, I see the id you saved had this information:

id: 1456844334

isrc: GBQCP1400109

album: Rock Clássico (Compilation)

This album and its tracks are not currently available in the Apple Music catalog in the US. There does not appear to be a direct replacement for this content available.


The best match in the US storefront for this song I could find is currently:

id: 917104593

isrc: GBQCP1400149

album: (What's the Story) Morning Glory? [Remastered]


What's interesting is the original song you were using was off of a compilation album and does not share the same ISRC as the best available match that is currently available.

Typically a good way to save a song like this would be to use the ISRC and look it up using the .../songs?filter[isrc]={some-isrc} lookup, however this case shows that even though the song seemingly is the same it was actually a different version of the recording.


The latter song with ISRC GBQCP1400149 currently appears on 2 albums, the remastered and deluxe versions (ids [917104593, 895279612]).


There is no way outside of the ISRC lookup to find some content that has become unavailable. Searching for content is notoriously unreliable due to the nature of music metadata and search functionality returning the best match(es) based on some text term.


We welcome feedback and consider supporting additional use cases when possible. Please consider submitting your report using the resources at https://developer.apple.com/bug-reporting/


Thank you for the question.

Posted by
jr.
Up vote reply of jr. Down vote reply of jr.

  • so is it better to relate an album in our own database to an ISRC rather than an ID? it seems like albums dont return ISRC's though

    —
    coratype
Add a Comment

Thanks for the response.

I already reported it as a bug few days after I posted this question, so let's hope the MusicKit team decide to add a fix to it... maybe they can reuse the same Id for the songs themselves or add another sort of global Id, for example if "Wonderwall" is both in the album "What's the story?" and in "Rock Clássico", then when the api searches for that Id the result will contain both of these songs from different albums... Which technically that's what ISRC Ids are for (but they are clearly not working well enough as you said... and you can'r relay on them... :/ )

Posted by
0132
Up vote reply of 0132 Down vote reply of 0132
Add a Comment