Developing music apps, OneMusicAPI announcements and more.
While preparing a data extract I recently discovered a set of Discogs data which I've begun calling "special entities". These are artists or labels which aren't actually artists or labels, but are intended to work as a meta-entity for grouping or classification purposes.
Why is it worth calling these out? Well, depending on the way you are using the Discogs database or API, it may cause performance issues if you link to these artists or labels with little benefit; some are huge in the number of entities they link to.
A new release of OneMusicAPI is in production, and we've rolled in a whole bunch of changes and useful new features to the API. As well as a few performance improvements, we've added support for returning the record label for a release, the composers for the tracks on a release and also whether the release is a compilation or not.
We get a lot of visitors to the OneMusicAPI blog looking for tips working with Discogs' API. Our tips on better Discogs searching article is one of the most visited on the site.
Discogs is a great resource and contains a wealth of musical metadata. However, they are known for making breaking changes to their API, and they've recently announced a new one: going forward, all queries to Discogs should be made over HTTPS.
As a result, app developers need to update their own apps so they work with the new changes. That can be a pain for certain types of apps, because the cost of getting the new versions of the apps to their users is high (not just financial cost; I'm talking about the effort and time it takes to announce new versions etc). This is why OneMusicAPI exists of course!
We've recently been doing some work on reducing the time it takes to perform an import from MusicBrainz, Discogs and our other sources into ADB.
Before, the import would take a long time. The Discogs import on its own, for example, would take over 24 hours! It was easy to see why: the import process was highly network-bound. Despite optimising the way we write to SimpleDB and CloudSearch, much of the time during the import was waiting for uploads to be made to these services.
A letter in the mailbag this week:
So one thing I noticed when performing some test queries from the browser is that at first I got a couple of "No rule matched" errors until I decided to include the "20150623" part (a date?) in the query URL.
I didn't see a reference to this string in the intro docs. Is this an API version identifier? If so, where are allowable values documented?