Harmony: Music Metadata Aggregator and MusicBrainz Importer

Because it’s not a worldwide release. See all the “unavailability” there. That is not a worldwide release and shouldn’t be set as such. It’s not even in the US or CA.


Actually I would have expected at least that the available information about "country availability’ be seeded in the annotation … At least as an option … For now I used atisket to store the unavailable countries in the annotation… Otherwise what is this info good for if it’s not used for seeding at all ?

1 Like

Definitely agree with that. Should be blank but needs the exempted countries in the annotation if the release country is blank.


A question from someone who uses Atiscket very rarely.

Does Harmony put the (p) and (c) in the right relationship, or is it just left in the written annotation like Atisket does?

It has always confused me as to why Atisket does that.

Annotations. It’s not possible to seed (internal) relationships.

Regarding Tidal:

I don’t know much about it yet but this appears to be a pre-release entry:

Note how it says 3 tracks (3 Titel) and lengths don’t add up.

Harmony gives no warnings whatsoever unless you attempt to merge it with other provider’s listings and will happily let you add it standalone:


Providers have returned incompatible track lists: 2 tracks (Beatport), 3 tracks (Deezer), 1 track (Tidal)


And @outsidecontext did it again, I am sure many of you will appreciate it: With today’s release Harmony finally has a Spotify provider!

We have even solved a long-standing Spotify issue which a-tisket has when a barcode search sometimes does not return the release while the Spotify website does.
The issue is unrelated to the zero-padding of the barcode which is sometimes necessary, instead the API has a region parameter…
For lookups by Spotify ID leaving away the region parameter returns the release with a list of available regions, but for the search API it apparently defaults to the US silently and only returns the release if it is available in the US.

An example which perfectly illustrates this:

So that is one more reason for you to fill Harmony’s region input with the region you are interested in. (Having said that I should finally make that input remember its last value, just like the provider checkboxes do…)

Additional changes include Bandcamp license URLs now being extracted and aditional or improved warning messages, see the full commit changelog.

As a first step Harmony now also displays alternative values for the copyright property. It still seeds only the main value since merging of copyrights or the feature to select alternative values still have to be implemented.


Thanks for reporting, I have created a ticket with permalinks, so even if we don’t implement it in time before the release date we can still use the examples for testing:

There will be an option to include the available and/or unavailable regions once there are options for the annotation at all. In fact I already had a request for an option to remove the copyright from the annotation.
Currently the whole website is static and rendered on the server, but as soon as it is dynamic this should be one of the first/Implest things to add.

P.S. I can’t promise an ETA for any of these features as I will busy with other things for the next months, but I hope that I will always be able to review contributions.


All iTunes requests are currently failing on the server. Still works when running Harmony locally. I wonder whether something got blocked or some rate limit applies.

Update: Seems to work again

iTunes is sometimes returning 403 Forbidden responses for a while, but their body is empty. No idea about the purpose of these, if it would be a rate limit, the API should return 429 reponses?
We are not logging every outgoing request, but the traffic to iTunes should be pretty low at the moment, only one request per release lookup since we are not even querying every region like a-tisket does.


I’m guessing Harmony doesn’t use d.ontun.es for ISRCs because it’s spotify only, but would it be possible to switch from keepstin’s MagicISRC to reubot’s MagicISRC?
The latter lets you add an edit note, I use it to keep the source of where the codes are from, example https://musicbrainz.org/edit/112787164

1 Like

There is a pull request to bring edit notes to the original MagicISRC for which I am waiting:

There are a few critical issues which are blocking the merge and haven’t been addressed by @reubot, so I will also not switch to their forked version.
For now you have to manually copy the description which is offered by Harmony, sorry.


it seems the same is happening for a-tisket right now too (tho a-tisket might be running on the same server as Harmony, I don’t know)

Unfortunately I didn’t notice there were changes requested - I’ll have a look on the weekend.


It seems for Bandcamp Harmony is lacking the check if a barcode is used for another edition like the userscript does:


According to the listing at Apple Music it should be 3617389461901


This release is doing weird things, durations are totally off, I didn’t investigate much but Harmony doesn’t work well for this one (not yet imported).

Weird, Apple Music has a completely different track order, some tracks are even shuffled from medium 1 to medium 2. If I unselect the iTunes provider, the result looks plausible (besides the 1900 release date from Tidal :grin:).

What is concerning me more are the processing times, each provider takes about 1000 ms while these durations should go down to about 10-20 ms for cached results… This generally seems to happen for all permalinks right now, but most are “only” taking 300-400 ms to process, I will investigate.
Edit: Restarting the app did not help unfortunately. Using my local server brings the processing times down to about 20 ms once the API results are cached. The main difference is that my local server’s snapshot directory only contains 25M of data (400k sqlite DB) while the pulsewidth server uses 150M already (3M sqlite DB), but the performance can’t scale that badly!?

1 Like

Since the userscript does not check the barcodes of physical packages at all, I guess we can do better and only unset the digital release’s GTIN if it matches one of the physical releases:

1 Like

It you put the Apple Music URL as the provider URL it works as expected. I think it’s likely because newer releases can’t be found using the iTunes API by barcode lookup, only by the store ID. See how it’s stating that another release was skipped that was also found by API. That release has a completely different barcode. Same issue with a-tisket. Always have the Apple Music ID as a provider or it sometimes doesn’t work correctly.