I know, from first hand experience, how difficult it is to launch and bootstrap a software project. How difficult it is to estimate how long development will take and how daunting it is to learn how to market and promote your project. Then there's managing all of those development risks: making sure different platforms and configurations are supported, proving that certain solutions can work, and keep working.
And that's while you're trying to manage costs too. If you are a bootstrapped or minimally funded enterprise you cannot simply " throw money at the problem". Bootstrapped companies developing solutions that require music metadata need a low cost way of getting at that metadata.
OneMusicAPI provides a low cost way of accessing this data. But given that most of the downstream APIs that OneMusicAPI aggregates are free anyway, why use OneMusicAPI? It comes down to making savings in time and effort; not just initially, but actually more significantly longer term.
n is the number of music metadata sources you intend on integrating with.
You might say "fine, I was only going to integrate with MusicBrainz anyway". If you are only integrating with one metadata source you might as well just do so direct.
The problem is that free music metadata sources are useful but don't cover as much data as the commercial, expensive ones. To give you an idea, the current totals are running at:
|Database||Cost||Number of releases|
|Gracenote||$ * lots||7m|
Only by combining them, thus writing multiple integrations, thus increasing
n, can you get the coverage
you require. For this reason, OneMusicAPI saves you a lot of initial development cost.
But actually, the savings come mostly from the long term. I know, from my own experience writing these integrations, that most work can be filed under "maintenance"; be it tuning of queries to get best results, or recovering from when the API is changed without notification. So yeah, if you think you'll only EVER need one integration, go direct. Otherwise, consider the ongoing costs...
The tuning of queries takes up a bulk of the cost in writing integrations to music metadata services. Such tasks include changing the way you send requests to the service, and how you interpret the results. The goals of tuning are to increase the number of successful queries you make whilst also keeping accuracy high.
I've written up some examples for Discogs; hopefully this gives an idea of the level you go to for tuning these queries. Multiply that by MusicBrainz, Wikipedia and you will soon realise you are spending a lot of time tuning queries.
With OneMusicAPI, we do the tuning. We've half a decade's experience writing these integrations. We keep informed of these aggregated APIs' changes and idiosyncracies. So when you query through OneMusicAPI, you're using all of that experience.
You'd be correct to say "but I still have to tune my own queries to OneMusicAPI". Only we like to think this will be pretty straightforward, given OneMusicAPI's first use case was the practical case of being called direct by software. Basically, we've eaten our own dog food.
Tuning can probably be considered a special case of general maintenance. Which brings me to...
Unfortunately, when you use a free music metadata API, the providers of said API are not really beholden to you. API changes happen, sometimes with little warning. When you are concentrating on delivering your own project, this kind of distraction can disrupt your flow and compromise your own schedules.
At OneMusicAPI we can react to any API changes and issue immediate fixes, without you having to do anything.
We never change existing APIs for paying customers. Only when all paying customers have moved off a particular API version do we shut it down.
When you're writing your own product, you want to concentrate on the problem your software or hardware solves. You don't want to be tied up with integrating with external services, or keeping those services running. You want to concentrate on your core competencies.
Essentially, outsourcing your music database integration to OneMusicAPI helps achieve that. You can get on with building your software and we'll do the boring, ongoing work of keeping your music metadata coming in, with high accuracy.
Thanks to Leyram Odacrem who made the the image above available for sharing.