Present Perfect

Today we had some friends over for probably the last barbecue this summer...

This was probably our best this year. Well-prepared, all the preparations ready before people arrived, nice chunks of meat, ... We started off with frozen strawberry daiquiris and this fresh ceviche made yesterday evening: 71113

The pièce de résistance was a nice chunk of côte à l'os of 1.5 kg:
7110771110

Good food, good company, our first bottle of Perfum de Vi Blanc, the great wine we got in the Penedes, and no stress. Even Kristien was surprised - she hardly did anything and still everything went smooth!

Today we had some friends over for probably the last barbecue this summer... This was probably our best this year. Well-prepared, all the preparations ready before people arrived, nice chunks...

Dear lazyweb,

Together with the cdrdao developer, I'm trying to get my hands on the Red Book spec for Audio CD's - also known as IEC 60908. The spec can be found on the IEC website. This spec is still not freely available, even though it's been what, 20 years ?

It seems a spec like this is offered from several different places, at different prices, and I don't know where the cheapest version usually can be found. Or maybe IEC, or Philips, offers the spec for open source developers at a more reasonable price ?

Who out there has had to get IEC specs for their open source projects, and how did you do it ?

Dear lazyweb, Together with the cdrdao developer, I'm trying to get my hands on the Red Book spec for Audio CD's - also known as IEC 60908. The spec can...

Today I took the time to fix an elusive off-by-one bug in cdrdao. I had to dive into the code quite a bit and I'm no C++ expert, but I figured out the bug in the end.

Basically, CD's put some information in the Q channel. This is a channel that has 16 bytes of information per CD frame (with 75 frames to a second). Among other things, that channel stores track and index number, the relative time (for display in a cd player), and the absolute time on the disc.

Pre-gaps have the relative time counting down; so the code detects a pre-gap as the point where a track goes up by one and index resets to 0. Then it stores the pre-gap length as whatever the relative time is at that point (which on disc is a positive nummer that should be displayed as a negative, and counts back). On some discs this counts back to 00:00:00, and on some it counts back to 00:00:01. The next track then starts at index 01 with 00:00:00 as the relative offset.

In the case of counting down to 00:00:00, the pre-gap is actually one frame longer than cdrdao calculates in that case. That took a while to figure out, basically by ripping a bunch of different discs and comparing to Exact Audio Copy.

Here's the bug report , and here's the patch.

This also made me realize that I have made patches to over 30 projects. Maybe it's time to trawl through those directories and follow up on some of them...

With this bug out of the way, I should gear up for a first morituri release.

I have one CD that troubles me though - José Gonzalez's first. EAC thinks it has a 7 frame pre-gap on track 3 (on two different machines), while cdrdao can't find anything there, and the Q-channel info doesn't seem to have a pre-gap either. All I can see is a lot more CRC errors than usual...

Today I took the time to fix an elusive off-by-one bug in cdrdao. I had to dive into the code quite a bit and I'm no C++ expert, but I...

I subscribe to the dream. I think a lot of features PulseAudio brings to the table are long overdue and very welcome. I even manage to be amused at Lennart's abrasiveness when it comes to defending the software he writes (though it might help that I know the guy). So I have the right mind set, which is why I persevere.

But one thing PulseAudio definitely lacks is transparency. Too much of it feels like black magic. I certainly pretend to know more about Linux audio than the average user, and even then I'm mystified by simple things as 'why does pulseaudio sometimes not seem to be running ? What is responsible for starting it at login time ? Why doesn't it get started when some app starts playing sound ? How do I figure out why sound doesn't work for this application ?'

Today I was reminded again as I ran into some problems with skype (bug filed). PulseAudio asserts and goes away probably because of something Skype does wrong (although one could argue that PulseAudio shouldn't break down completely because of one bad client).

The bug itself is not the point of this post. What I'm lacking in PulseAudio is a way in to understand problems and help create good bug reports. A PulseAudio debugging guide would be excellent to have; one that would tell me 'set up pulseaudio like this to get more info when the crash happens'. Googling doesn't find me a guide, and PulseAudio's website doesn't have one either.

Lennart, if you can give me some starter tips to provide better bug reports I'll volunteer to write up a Trac wiki guide to do the debugging and bug reporting.

No need for the haters to comment on this post - whether it's hate against Skype or PulseAudio :)

I subscribe to the dream. I think a lot of features PulseAudio brings to the table are long overdue and very welcome. I even manage to be amused at Lennart's...

The last few months, as a result of summer, holidays, and catching up with work backlog has made it impossible to spend any useful time on my music programming. I have the various pieces in halfway-finished state. I should do a first release of the cd ripper I made; the mixer sort-of-works-most-of-the-time but is still command line and does not have play controls; a Django-based rewrite of DAD is pretty much functional up to the point where I can rate tracks and migrate the old DAD database; and I bought the LEGO mindstorms set to make the CD ripper robot.

However, I still had one nagging problem I wasn't sure yet how I would end up dealing with. The problem is conceptually simple.

I want to rate tracks on different computers and have this be synchronized to all of them.

There's two parts to this problem. One is 'what is the same track' ? Linking properly to a database of unique id's would be the best way to do this, and it seems MusicBrainz over the years has evolved to more or less solve that problem. I should still run more tests over my collection, but it seems I can resolve most of the duplicate tracks I own to the same 'song'.

The second problem is a technology problem - how do you synchronize database information between the various machines - my work and home desktop, my laptop, the elisa/##moovida box I have, Kristien's ipod, my N800, and my future car player ?

Well, it seems I haven't been paying attention to databases recently, and I also didn't really look into Stuart's musings about desktop CouchDB. Recently when Marc-André Lureau arrived in Barcelona and we went out for dinner, Zaheer and him upon hearing my sad tale of woe brought up CouchDB again.

All I remembered from a brief look at CouchDB is that it was a schemaless document store written in Erlang. For some reason I completely missed the replication mechanism and conflict resolution it has built-in, which to date has been the closest match to what I think I need for my application.

So I've been reading the CouchDB manual recently, which has given me once again that same warm fuzzy feeling as when I originally got turned on to GStreamer (by reading the excellent manual at the time) and Twisted (same thing, the docs did it for me).

And now I'm torn. Switching to CouchDB might be the right move, but I don't know if it is. I have no idea how I should restructure the applications around it, how I should store the data the best way in CouchDB, and so on. The main reason for wanting to switch would definately be the replication model. Not having SQL or a reasonable way of querying the data (at least as far as I can tell currently, unless all data for a track would be stored in a single document) is a big turnoff.

So I'm wondering what other options are out there, or how people have solved similar problems ? Is CouchDB's replication system a side effect of their design and RESTful API ? Or is that kind of replication possible in a more structured database ? Is it possible to put lipstick on the pig that is traditional SQL to have replication between sometimes-online computers a reality ? Are there other database servers out there that may be a better fit ?

I've been Googling a little, finding things like Cassandra (interestingly also an Apache incubator project like CouchDB), Project Voldemort, Persevere, Hypertable, Redis, Tokyo Cabinet, and probably some more.

I'm not even sure what the right search terms are for the features I want. It seems eventually consistent is one of them (as in - eventually the separate databases on each machine will end up having the same data), although in my case the eventually would come from the machines not always being able to directly communicate by design, not just because of an operating failure.

In the meantime, I am paralyzed with the choice between staying with Django for a while more as I develop some more features (and manually syncing the database between computers) or already porting to something like CouchDB.

I am seriously considering learning CouchDB a bit better, possibly starting with a rewrite of yagtd against a CouchDB database - it seems such an obvious match. I currently manage my yagtd todo.txt file in subversion, and having to commit and update is pure mental friction, not to mention resolving conflicts when I forgot to do the commit/update in the first place.

I would think that a GTD task list would be a perfect match for CouchDB's document model and replication strategy, and would definately correctly solve the generic task list problem.

Enrich my vocabulary and choice of options! Suggest stuff in the comments.

The last few months, as a result of summer, holidays, and catching up with work backlog has made it impossible to spend any useful time on my music programming. I...