One important change on the website is addition of email and website fields to applications. If you are an author of an open source application that uses the AcoustID API, please fill them in so that I can contact you in case there is a problem with your API key. These fields are not displayed anywhere publicly.

Contributor statistics were also removed from the website. They were interesting when the project was small and had a couple of contributors, but recently I’ve had a increasing number of people asking to had their account removed from the statistics, so I’ve decided to remove the statistics completely.

The /v2/lookup method supports a new option sources in the meta parameter. It’s only applicable when meta includes also recordings and it tells the server to return also the number of sources for each returned recording (corresponding to the Sources field on the website).

There are also two new methods /v2/user/lookup?user=X and /v2/user/create_anonymous?client=X&clientversion=X, to support anonymous user accounts. They can be used from applications that can’t ask the users to log in on the Acoustid website, but there are a number of rules that such applications should follow:

• The returned API keys must be stored in the user’s settings and re-used. Do NOT create a new API key every time the application is started.
• You can’t assume the saved API key still exists. Unused anonymous accounts will get deleted after some time. Use the user lookup call to verify the API key still exists.

Download:

• Source code tarball (91KB)

Download:

• Windows application (7.5M)
• Mac OS X application (14.4M)
• Source code tarball (70K)

Changes since version 0.4:

• Unicode filename support on Windows.
• Support for 24-bit sample formats.
• Reading MBID tags from foobar2000-written MP3 files.
• Added .desktop file for Linux.

Download:

• Source code tarball (530K)
• Static binaries for the fpcalc tool:
  • Windows (695K)
  • Mac OS X, 32-bit, 10.4+ (582K)
  • Mac OS X, 64-bit, 10.4+ (582K)
  • Linux, 32-bit (711K)
  • Linux, 64-bit (689K)

Changes since version 0.5:

• Support for 24-bit file formats in fpcalc.
• The fpcalc utility now uses 120 seconds of audio data by default.
• Python bindings moved to a separate project (pyacoustid).

What makes me more happy than that the project is being useful is that the decisions I’ve made regarding the server architecture turned out to work very well and the server generally very fast and scalable. The average lookup processing time is around 60ms and I expect the number to go down, not up in the future.

As the post about Chromaprint says, the audio fingerprints used in Acoustid are basically vectors of numbers. For performance reasons on the client side, applications are now calculating these fingerprints only from the first two minutes of audio files. That means that when the server scores the results, it only considers the first two minutes of audio. If two tracks have the same intro that is over two minutes long and then they get different, Acoustid will unfortunately see them as the same. This doesn’t cause too many practical problems though. The MusicDNS service that MusicBrainz currently supports also use only the first two minutes.

Before scoring the results, the server must somehow get the results in the first place, and this is where normally things get slow. The database currently has more than 10M fingerprints. If we assume all fingerprints have at least two minutes (which means 948 numbers per fingerprint), that’s 9480M numbers to search in. Just saving these numbers on disk, together with the pointers to the fingerprints they come from, would require 76GB of space. And since the search must be fast, the data must fit in RAM. This is obviously not the way to go if we want to be able to host the service on a single server and yet get response times below 100ms. The search space must be reduced.

Because Acoustid is meant to be used for file identification, I don’t necessarily need to search anywhere in the fingerprint. I know that the fingerprints I get are from the start of the song, I know that if the two fingerprints are similar enough, they must match across the whole length and I can assume that they also must match a specific (smaller) part. So even though the original fingerprints are two minutes long, I decided to search only in the part between 0:10 and 0:25.

The sub-fingerprints that cover these 15 seconds are stored in the Acoustid index database. Whenever I search for a fingerprint, I extract the 15 seconds long sub-fingerprint (“query”) and send it to the index server. The server returns a list of matching fingerprint IDs (“candidates”). These candidates represents fingerprints that might match the original fingerprint, but to not necessarily have to, because all I know about them is that they matched the extracted 15 seconds long query.

The next step is to take these candidates and compare them against the original fingerprint. This is done in PostgreSQL, where the full fingerprints are stored. Each of the candidates is compared against the original fingerprint using a function that tries to align the two fingerprints and then calculates the bit-error-rate between the overlapping parts. The result of this function is a score between 0 and 1. Fingerprints with the score above a certain threshold are considered valid matches, MusicBrainz metadata is looked up for them, they are returned to the user and that’s the end of it.

The whole process looks something like this:

This covers the searching side of the server. I’ll try to write another post soon about the data management side (importing, merging, etc).

Some time ago I added overall search statistics. This release adds similar statistics for individual applications. For example:

Of course, these statistics are only available to the owners of the applications.

Another change related to external application support is that the submission API call now accepts a new parameter clientversion. This is the first step to allowing a single application API key to be used by multiple versions of the application. In following releases I’ll be changing the API key structure to allow applications to have a number of API keys that can be disabled/enabled any time.

Download:

• Source code tarball (530K)
• Ubuntu packages
• Static binaries for the fpcalc tool:
  • Windows, x86 (634K)
  • Mac OS X, x86, 10.4+ (524K)
  • Linux, x86 (651K)

Changes since version 0.4:

• Unicode command line handling in fpcalc.
• Fixed a crash in fpcalc when FFmpeg was not able to identify the codec.
• Added encode_fingerprint to the Python bindings.

While the Acoustid database is reimporting, I wanted to do something fun, so tried to integrate Acoustid links into the MusicBrainz website. I wrote a simple user script that calls the Acoustid API, loads all IDs linked to a recording and displays the data right next to the list of PUIDs. If you install the script, the “PUIDs” page will now look like this:

It links back to the Acoustid track pages, which you can see for example here. The database is still very small, so you will probably not see the links too often, but that should get better soon.

The next step, which is probably not going to be this easy, will be adding the “Remove” links to the pages also for Acoustid tracks and actually making them work.

Here is a complete list of changes in this release:

• Faster and more robust way of comparing fingerprints.
• Mapping of fingerprints to PUIDs.
• Initial support for storing custom foreign IDs.
• Better tracking of the source for each fingerprint and fingerprint<->ID mapping.
• Tracks now have UUIDs attached to them, so the default result ID format will change in a future version of the web service.

I was introduced to programming as a kid at the elementary school. Seeing that I can use mathematical functions and some funny English words, which I didn’t understand, to draw circles on the TV pretty much changed my life. I wanted to learn more and more about the BASIC language, but it was more theoretical than practical, because I didn’t have any computer at home back then. Even though I could only play with a computer at school, I loved reading programming books and learning more about it. A little later I got a computer and spent days and nights learning “real” programming in Pascal. While my classmates were having fun outside playing football, I was having fun learning about sorting algorithms and data structures. I didn’t believe I could actually work at a programmer when I get older, but I very interested in learning more and more anyway.

Several years later I discovered demoscene, which brought my programming experience to the next level. I was never able to make my own demo, but I found it fascinating to hack on multimedia software, especially in environment like MS DOS which was not multimedia-friendly at all. I spent a huge amount of time learning how you can make a computer produce sound, how module players worked, even experimented with making my own tracker. This was also the time when I had to leave Pascal and (painfully) start looking into C and even some x86 assembler. I made some 256b intros — they aren’t any interesting, but I was very proud of myself back then. :)

The next breakthrough happened when I found MS DOS too limiting and installed Debian on the 386 machine I had. This brought me to the world of open source software, where I could take a look the code of every application that I used. Programming on a real operating system that didn’t allow me to just write to any memory address and reset/freeze the computer by doing that was a great change too. :) Of course, I was still interested by music software, so I starter learning Linux programming by porting the MXMplay module player (and laterMiniFMOD) to Linux.

The next period was pretty boring. I learned a few things about making websites, enrolled at university and needed money, so I started working as a PHP programmer. I wasn’t very good at it, but I quickly learned what I needed to know. This went for a few years, I was working on various kinds of websites, writing content management systems, creating modules for eCommerce systems. I got pretty good at it at the end, so web technologies ended up being the main focus of my professional career. I learned Python and some other languages and programming for me generally started being more about work and less about fun.

This changed when I discovered MusicBrainz. At first I only wanted to tag my files to get better stats on Audioscrobbler, but I realized that it’s an open source project I can contribute to, and it’s about web stuff AND music. I submitted a few smaller patches for the MusicBrainz server, then I was unhappy with the tagger application and started helping with Picard. Eventually I ended up maintaining Picard, which brought me to many other music-related open source projects. Since then, I probably touched the code of every component that MusicBrainz ever used. I worked on the client libraries, learned Perl to work more on the server, introduced many database schema changes, did some coding on the Java version of the search server. Heck, I even designed the graphic layout MusicBrainz is currently using. :)

After I finished the university and switched jobs, I didn’t have that much time for open source projects. I disappeared from MusicBrainz for some time, focused more on my career where I was working on larger and larger projects. I needed something fun to work on though and that’s basically when I started looking into audio fingerprinting and how the Acoustid project was born. It was something new and challenging and yet something that was needed. After a few months of reading papers, I started writing some code, got “good enough” results, wrote more code and that’s basically where I’m today.

During the last two years I started realizing that the web programming I do at work is probably not what I want to continue doing, at least not full-time, so this is actually the last month at my current job. I’ll have to deal with some health issues, then take a longer vacation and we will see what happens next… :)