aubio
Meet gst-aubio
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.
Sat, 12 Dec 2009, 15:51. trackback - view/add comments
Logo for aubio
A few days ago I asked Thorsten Wilms, who designed a bunch of fine logos for audio softwares, if he could think about a logo for aubio. As a starter, I mentioned the cover of a previous issue of Computer Music Journal.
Thorwil just posted a few ideas on his blog. Suggestions, comments, opinions? All welcome!
Mon, 07 Dec 2009, 19:10. trackback - view/add comments
Switching to git
I have always been happy about bzr. Recently I started working on a project that uses git, and this first contact was enough to convince me switching my own branches from bzr to git. The main argument is speed! The stage area is also a nice thing. I often rushed to type Ctrl+C with bzr after forgetting to mention which files I meant to commit.
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?
Thu, 03 Dec 2009, 03:50. trackback - view/add comments
Keeping it groovy
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.
Thu, 26 Nov 2009, 01:53. trackback - view/add comments
Ceci n'est pas un vecteur
For the last few days, I have been scratching my head at this question:
should aubio keep using vectors with channels? First of all, the
fvec_t structure currently in aubio is a matrix, not a vector, and
uses float ** arrays. While it may sound nice to be able to run a
phase vocoder or a filter on multiple channels, this leads to several
troubles.
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.
Thu, 12 Nov 2009, 21:05. trackback - view/add comments