GStreamer up the Banshee

Way down in native land…

In the last couple of days, I’ve committed some shiny new GStreamer code to Banshee HEAD that has been “in the works” for quite some time (close to 4 months :-(). HEAD now features support for using GStreamer for tag reading, instead of Entagged. I think I am going to fall back on Entagged for certain potential failures in the GStreamer layer (no demuxer for a certain format, like WMA), but for now I’ve disabled Entagged to focus on testing the new GStreamer code.

This means that in libbanshee there is a new GstTagger API that is dedicated to synchronously parsing metadata. I’ve never done any synchronous operations in GStreamer 0.10, so I may not be doing something correctly, but I think it’s mostly right. Nevertheless, this code needs a lot of testing (hint, hint).

I also landed what is currently a static GStreamer element, mbtrm. This is a simple element that uses the MusicBrainz TRM API to calculate an acoustic fingerprint of a raw audio stream. Currently I am using the element in the CD ripping pipeline, like this:

cdparanoiasrc ! mbtrm ! ...

When a fingerprint has been calculated (currently only after EOS, which needs fixing), the element raises the ‘have-trm-id’ signal. I would like to make this happen before EOS so the TRM ID could possibly be set as a tag on the stream, but I’m mostly happy for now. At least the fingerprinting is decent. Currently the TRM ID is just printed to stdout, but eventually it will be used to query MusicBrainz for more track metadata, making it possible to fetch metadata for partial or mixed audio CDs. This too needs more testing.

Of course the element can be adapted in any pipeline to perform fingerprinting on any raw audio stream, not just for CD ripping (wouldn’t it be cool to have a “first pass” kind of option to fingerprint an entire imported library that may suffer from mangled or missing metadata ;-)).

And on the managed front…

I also moved HEAD to use gmcs! This means I will slowly introduce generics into newly written code where it makes sense. The keyword is slowly. Banshee has been running against the .NET 2.0 class libraries for over a week for me and I’ve yet to run into any unexpected problems. The GstTagger managed wrapper features the first snippet of generics, and it’s working great.

I’m really looking forward to introducing code that uses generics, nullable types, etc. where it makes sense and, over much, much, much time possibly migrating existing code to use generics.

Hopefully Banshee against gmcs/.NET 2.0 will re-enforce all of the great development and stability that has been going on in that front in Mono, and maybe we’ll start to see other applications migrate as well.

One Reply to “GStreamer up the Banshee”

Comments are closed.