Amazon unfortunately doesn’t have barcodes that are easy to find. Amazon is typically the same release as the Deezer equivalent. I use the following to search for other sites, such as Amazon: https://odesli.co/
Thanks for the update Kellnerd!!!
This morning all TIDAL releases are returning the following:
Cannot read properties of undefined (reading ‘map’)
5 Likes
That seems to have done the trick. Haven’t had this problem since then.
Improvement suggestion:
Spotify pre-releases are not supported by the API but I noticed that it’s possible to find them with the web search.
https://harmony.pulsewidth.org.uk/release?itunes=1794799332®ion=US&ts=1745243319
So instead of showing an error Harmony could suggest to manually search for it:
https://open.spotify.com/search/upc%3A810129811551/albums
(Yes, this draft is old)
A while ago I saw a commit preparing for special purpose entities.
Especially DistroKid is problematic where hundreds of people add the endless amounts of “variations” and using them as the release label. Due to the many merges it’s now probably one of - if not the - most subscribed entities.
It’s an impossible task for voters to explain this all the time. Disambiguations don’t seem to help either.
I hope in the future Harmony can handle these better and deter people from blindly copy-pasting what they see.
(This is also one of the rare cases where it’s not helpful Harmony automatically resolves entities.)
An anecdote on barcode extraction issues:
Currently Harmony tries to extract the barcode for Apple Music releases from the cover art URL for confirmation but this is not reliable. Example:
https://harmony.pulsewidth.org.uk/release?gtin=190295820954&itunes=®ion=GB&ts=1744273271
Yet Harmony sounds convinced (except for the subtle warning) it’s 190295820954 when it’s actually 190295795986 per Apple Music API. This can be a serious problem when people rely solely on Harmony to add data that’s otherwise “invisible” to them.
7 Likes
Just a quick technical question
From which service Harmony can Extract ISRCs? I know it can do it on Spotify and beatport but is there any others?
Deezer and Tidal too.
Only Bandcamp doesn’t provide any ISRCs. iTunes/Apple OTOH does store them but if I’m not mistaken you need a different API for it, hence why Harmony or A-tisket were never able to report them.
2 Likes
@RustyNova @DenizC I know Bandcamp can store ISRCs (there’s a field in the album upload form), but I don’t know how exposed it is (or more importantly, how often artist actually enter them)
1 Like
I’m just looking for when I can be certain a release can provide ISRCs when using harmony. Just to link that~
You can see the ISRCs on Apple by using ToadKing’s Apple Music Barcodes/ISRCs script. This script is very important with Apple Music releases. It shows the correct barcode, which is sometimes reported incorrectly as described by Chaban above, and also ISRCs, labels, copyrights, and other audio qualities, such as Apple Digital Masters or hi-res release, etc. It can be found here: GitHub - ToadKing/apple-music-barcode-isrc
I’d recommend that anyone entering a release that involves Apple Music use this FIRST to verify that the reported info Harmony or a-tisket gives match it. I’d also use a-tisket if it’s an Apple Music exclusive as it’s the only one that returns country availability if you check the box to run iTunes in every country.
2 Likes
Uh, where do I start? There have been quite a few small but important updates recently and also a couple of posts I haven’t replied to. Let’s start with the updates:
Recording link types are now properly detected for Bandcamp tracks (thanks to arsinclair!) and Apple Music songs.
I finally did the massive refactoring of the MBID resolver to make use of MBS-13943: Lookup multiple URLs at once with the API.
This should bring a notable performance gain in many cases, especially for releases with multiple artists. Usage of the MB API went down from up to a few dozen requests (for compilations) to one request per release lookup on average.
Only very few releases need more than one request (with 100 looked-up URLs included) and as a bonus I could finally implement a search for release links as well to detect potential duplicates (without any additional requests).
An info/warning box is shown for each potential duplicate on MB.
Good point, I’ve added alternative values for label/catno combos (as you probably have noticed already).
Since it is trivial to show alternative values for (almost?) every property, please let me know if there are any others where it would be useful.
(I had thought about ISRC, but I haven’t seen any case where they were different, so it would be pointless computations without a guarantee to ever find an alternative value.)
Unfortunately Tidal have messed up their API again, it suddenly no longer returns image links. Again an unannounced breaking change…
I’ve hotfixed the provider to return at least the remaining data, cover art support has to be reimplemented in a backwards compatible way 
Thanks for letting me now, I was totally unaware of this issue. Harmony now automatically replaces DistroKid placeholder labels with [no label]. It still shows the source data as alternative values but never uses them. Let me know when you encounter any placeholder format which is not caught by this.
P.S. I’ve copied your Spotify prerelease suggestion and the iTunes anecdote to the relevant GitHub issues.
8 Likes
I just noticed an issue with this (and will try and make a ticket for it today or tomorrow) where it missed that a track was also free to download, specifically this track (and the rest of the album, but I’ve added links to the other tracks already), it didn’t add the download for free relationship
edit: I just saw that the above is a known issue already: feat: populate track relationship types for Bandcamp by arsinclair · Pull Request #118 · kellnerd/harmony · GitHub
glad to see a more comprehensive duplicate detection tho, it’ll really help with both Bandcamp in general as well as streaming releases added by editors who don’t know how to find streaming barcodes~ (as well as DistroKid detection, didn’t know that I needed that one, lol)
1 Like
There’s a similar issue with labels starting with iMD- (see Search results - MusicBrainz), not sure exactly if they should belong to a parent or [no label], but it seems to me those are specific to each artist, so that’s more or less the same thing than with DistroKid.
2 Likes
That’s iMusician Digital
1 Like
Hi, I just have a quick question about GTIN harvesting from Bandcamp: Does Harmony harvest the GTIN directly from Bandcamp, and if so, where is it?
I tried to look through the code for this, but I don’t know TypeScript well enough to figure out what it’s pulling from.
This came up for me, because I was editing this release: Give Water To Birds – Harmony Release “Give Water To Birds” by ZÖJ - MusicBrainz and removed the Barcode, because I didn’t see anything about it on the Bandcamp page, or anywhere else, for that matter. I was voted no on this, and poking around found that it was imported from the Bandcamp page using Harmony. The GTIN isn’t on the bandcamp page, either in the browser rendered page or the HTML. Searching the web for it yields some websites with an order for the physical release.
I cancelled the edit on removing the barcode, because I don’t really care enough to argue, but now I’m just interested in how this utility is looking it up. Thanks!
It’s part of the metadata embedded into the page. There is a MusicAlbum schema embedded in the LD+JSON format.1)
A easy solution to make this visible is using the schema.org validator tool:
The GTIN is available as identifier there:
UPDATE: I didn’t notice this originally. But the MB release has two separate Bandcamp URLs assigned.
This one has the GTIN: Give Water To Birds | ZÖJ
This one doesn’t: Give Water To Birds | ZÖJ | Gelareh Pour
I don’t know. Technically this might be a reason to split one out to a separate release. But I personally think this is too much nitpicking.
1) To be correct, Harmony actually doesn’t read the metadata from this LD+JSON but from the embedded player. But that’s an implementation detail, the data should be the same.
3 Likes
Oh, wow! I had no idea! That makes crosswalking a lot easier 
(I thought you were having to crawl through the HTML, and was like, wow, that doesn’t seem like the best idea )
Having put some stuff up on Bandcamp, I suppose I do remember there being a field for UPC/EAN, but I never really paid attention to it.
God, wouldn’t it be nice if Bandcamp had richer credit fields, then?
As a metadata librarian, this is the stuff I need to be more aware of. Very cool. Thanks a lot!
Now, I want to poke around in this all day, but I suppose I should be doing the job that I’m paid to do.
As to this particular case, I haven’t seen the actual physical release, so I’m not sure if the GTIN is the same for it. I’ll note that the Galareh Pour link does not have a physical release available for it, so it may be that the creator of the metadata for the Parenthèses Records release just use the GTIN of their CD version. Bad practice.
3 Likes
Some small (cosmetic) issues:
- If the only provider has no ISRCs it shows as
: Submit ISRCs from Beatport to MusicBrainz
https://harmony.pulsewidth.org.uk/release/actions?release_mbid=4413a026-6b0b-499d-947e-472c38562630 - Various artists can’t be edited by normal editors so there is not much sense in Harmony offering to add links
- If possible the ISRC submission link should be hidden if all ISRCs are already added.
3 Likes
Spotify look-up seems down
1 Like
It’s working on a-tisket still. So, looks to be Harmony specific. Which his odd.
I have no idea what has changed this weekend, but there have been thousands of 429 Too Many Request errors from Spotify. About 1.5k yesterday and 1k today, both times during the night and early morning (UTC). Interestingly there have been zero of these rate limit errors in the two weeks before that… Traffic to Harmony can’t have increased that much, so I guess it is more likely that Spotify lowered the global limit (temporarily?).
Of course the rate limit errors disappeared almost immediately when I started to debug the issue today (by adding more logging and restarting the server). At least I was able to collect one more of these errors and could deploy a potential improvement, let’s wait for some more Spotify rate limit errors to confirm 
The provider should now handle the Retry-After HTTP header and retry the request after a delay. (All further Spotify requests should be blocked by the same delay.)
a-tisket uses a different API token and receives less traffic as far as I know, that might explain it.
5 Likes