I have just pushed the Gstreamer plugin for aubio to git.aubio.org. No official release just yet, but you can fetch the latest gst-aubio branch using:

git clone git://git.aubio.org/git/gst-aubio

So far there are two elements: aubiopitch and aubiotempo. Here is an example of how to use them:

gst-launch-0.10 filesrc location=uri://to/soundormovie.file ! decodebin \
   ! audioconvert ! aubiopitch silent=FALSE ! aubiotempo silent=FALSE \
   ! fakesink

Many thanks to the nice folks at Ubicast, who sponsored the development of these elements. They used it for instance to automate camera switching on the video stream of their party events, but also to control lights and camera. Check out this test.

Thorwil just posted a few ideas on his blog. Suggestions, comments, opinions? All welcome!

Converting the branches was as easy as:

git init
bzr fast-export . | git fast-import
git reset

gitweb is now installed at http://git.aubio.org. You can clone a branch using:

git clone http://git.aubio.org/git/aubio

Hopefully this should also prevent trac eating most of the available memory. Still, the trac site remains really slow compared to gitweb, and has no support for multiple projects. So I am considering switching to Indefero or Redmine. They are written in PHP and Ruby, which are not really my preferred languages, but both have built-in support for multiple projects and are actively developed. Any suggestions?

Tempogram for Havana Cultura: New Cuba Sound, a 45:31 minutes mix by Gilles Peterson

At the latest ISMIR conference, Peter Grosche and Meinard Müller presented a paper called A Mid-Level Representation for Capturing Dominant Tempo and Pulse Information in Music Recordings. I was told to give it a look, as Meinard Müller gave an impressive presentation with several sound examples of difficult but successful beat tracking.

The method they describe is somewhat intuitive: build an onset detection function, or novelty function, detect the pitch, or fundamental period, on this function, and synthesise the result using an overlap-add technique. The approach is elegant, efficient, and present several advantages over existing methods, such as the one currently implemented in aubio: versatile, computationally efficient, it does not depend of previous context, is easy to implement, and can be easily configured for different situations, with independent tempo and time resolutions.

Last week-end I gave a shot at implementing this algorithm and got pretty impressive results right at the first attempts. I managed to get 82% of correct tempo (BPM) over my test database; not bad compared to the 72% reached with the latest aubio version ‒ the database, constructed by Stephen W. Hainsworth, consists of 222 musical extracts of various genres.

I thought about titling this post "Harder, better, faster, stronger", but that sounded a bit déjà-vu, and the musicians from Cuba are much harder to follow than the famous French duo. The figure above shows a tempogram of a 45 minutes long mix by the amazing Gilles Peterson.

There is more than tatums and tactus coming out of these tempograms: some interesting patterns emerge, describing the rhythmic structure of the sound. More about this later, as soon as I find time to complete my implementation, adding the precise beat locations so they can be played.

Most of the vector functions become ambiguous. For instance, should fvec_min return the minimum value over all channels, or a vector containing the minimum values of each channel? I started using things like fvec_median_channel in the latest branch, but that's really ugly and unclear.

In practice, in aubio we almost always want to mix down to mono before running any algorithm on the signal. All the applications using aubio I heard of were using only one channels. There might be some algorithms where we need multiple channels as input, for instance pan descriptors, but that's a corner case, and using 2 vectors for input is easy.

Now there are some optimisations concerns, as I have measured that running 10 channels in parallel is slightly faster with the current implementation, which allocates the FFT buffer only once for all 10 channels. I got about 3% slowdown when creating 10 times the required objects, instead of using objects with 10 channels ‒ this went down to 2% when running over a ten times longer period, so the performance loss is probably not only due to memory allocation.

Anyway, premature optimisation is the root of all evil.^* So I created a branch, and published it here:

http://bzr.aubio.org/aubio-mono

Unsurprisingly, this makes the code base a little bit shorter (1695 insertions(+), 1800 deletions(-)). Unless someone convinces me there is a very good reason to keep this feature, I will merge the mono branch in the master branch within the next few days.