Works great. This is a big help. Thanks for the work.
There is a limit, but not by me. Spotify’s API lookup accepts up to 50 entities at a time.
What’s happening here is that all of the tracks are being requested, and Spotify is only returning the first 50. This is just an oversight on my part, that the logic doesn’t batch them.
That will probably be fixed by the end of today. Done.
Basic artist view is now also available – like the tracklist issue, this does not batch the requests so will clip at the 50th release for now
5 Likes
perfect.
thanks again for the hard work.
A very small update today.
The current endpoints are now:
/artist/<Spotify artist ID URI> – returns the first 20 releases of the artist in Spotify’s catalogue* along with market availability as an ISO 3166-1 alpha-2
/album/<Spotify album ID> – returns the album info with ISRC, copyright info (market availability will be added to this later today)
/uri/<Spotify URI> – a limited auto parser, which will be built on in future. If you copy a Spotify URI (only available on desktop apps as far as I know) which appears in the format of spotify:artist:ID (or same for an album), it will save you the small but annoying step of manually pulling out the ID and attempt to parse the type, and ID, and send you to the correct view. e.g. tatsumo.pythonanywhere.com/uri/spotify:artist:1z4g3DjTBBZKhvAroFlhOM
2 Likes
Great job. This helps me a lot.
I made a tool (desktop application in .NET) to help me few years ago to retrieve ISRC’s from Spotify.
Unfortunately, since they changed the Web API to use OAuth, of course my tool didn’t work anymore and I’ve never found the time to change the code in order to use authentication (token, and so on)… and I must admit that I’m fed up with implementing (again and again) such big changes (authentication) just to retrieve the list of ISRC’s for an album (they already changed their API years ago in order to use JSON objects instead of XML…). If only I had enough time to to do this 
(as I always add ISRC’s into meta tags for my FLAC files).
So I am very happy to find your Web application 
As it’s sometimes difficult to find them for few albums…From now on, I can use again ISRC’s from Spotify. Thank you again for your hard work! I really appreciate this.
1 Like
I’ve just updated it again. Now you can push the ISRCs to MB directly from an album view. You can paste either the release ID in MB, or its URL.
Note: if there’s a typo in the URL, it will crash the cause an error in the request. Also parsing the ID from a complete MB URL is not very robust definitely don’t be surprised if it doesn’t always work.
When you attach a MB release, it will do a shallow comparison of the track names, and the track lengths, to warn you if they are potentially not the correct targets. It doesn’t check existing ISRCs though. For the shallow comparison, it will ignore case and compare the strings, with certain characters stripped out (punctuation mainly). It’s very very flakey, but that’s why you can see the track names side by side as well to use common sense.
4 Likes
This is so awesome!!!
Great job!!! Thank you so much!
I’m still going back and just copying the new URL. Hope that’s good enough. But yes, I have to go back and do that.
1 Like
That’s very good 
but I see many other ISRC edits without notes (even from some editors I keep telling them).
And when we don’t know for what release it was added and from what source, it’s then difficult to trust them and to later fix or merge with no mistakes.
4 Likes
This tool is really neat. Just an odd observation: after submitting the edit to MusicBrainz, the app gives me a 0 byte randomly named file to download. Not sure why that happens. This is on Firefox, if that matters.
Yeah the MB server sends that. I can’t do much about it except look at moving to the newer API, which is roughly on the roadmap but only for the same reason as you suggest: the “download” files are annoying to cleanup all the time.
Another thing I noticed is that the MusicBrainz API expects ISRCs to always be uppercase, but Spotify doesn’t always return them that way (example). This results in an invalid ISRC error upon submission.
I’ve been using a quick JS hack to uppercase them before submitting:
(function() {
var a = document.forms[1].getElementsByTagName('input')
for (var i = 0; i < a.length; i++) {
if (a[i].type == 'hidden') {
a[i].value = a[i].value.toUpperCase();
}
}
})();
Pop that into the console, or a userscript, and smooth sailing from there.
Note: This doesn’t attempt to fix the ISRC anywhere else on the page, just the hidden form inputs. It also uppercases the entire input, including MBID, but a GUID is a GUID so MB doesn’t complain.
This should now be patched. Do you have any examples of albums with lowercase ISRCs, out of curiosity?
Besides the one linked above, pretty much every album by The Cog is Dead is returning lowercase ISRCs. Some of those albums don’t exist on MB yet, so I can’t test the patch at the moment.
Actually, the server ignores duplicate ISRC edits, so I just tried it, and I got a successful response.
Also, the ISRC in the form field is now uppercase, but the ISRC URL next to each entry is still lowercase, and returns “ISRC not currently used” when clicked. Perhaps the proper solution would be to file a bug with MB to treat ISRC as case insensitive?
Only the form submission is patched. Lookup and display remain the same.
I agree that it’s silly that a data type that is case insensitive according to its own standard is looked up in a case sensitive manner by MB (particularly since entering them by hand on recording pages has logic to handle this) but in the meantime I’ll patch again to convert ISRCs to upper case before they are used anywhere, for better consistency.
2 Likes
And now the latest bit of weirdness: The Vice Quadrant: A Space Opera - an album in two parts. On MB, it is listed as a single two-medium release, but on Spotify, it is two separate albums (Part 1 and Part 2).
Part 1 entered just fine into the tool, and populated the first medium. Part 2, however, not so much. It would seem that the tool only pulls and displays the first medium in a multi-disc release. Even were that fixed, in this case, it would still need to accept multiple Spotify album IDs to work correctly in this situation.
Or to just uppercase on paste. Either way, yes, please do 