Present Perfect

Today was not a particularly good day - I woke up with a huge headache around 4, took a dafalgan, went back to bed, and woke up around 8:30, still with a headache. This sort of thing happens once in a while to me, though it happens a lot less since I reduced my disorganization stress a few years ago.

Anyways, that's not the point. On days like these, I can only do small incremental changes, which I guess is good for polishing. My brain doesn't let me do much more.

So, I finished some loose ends in my ripping code. Here's a file listing of a directory:

[gst-git] [thomas@ana trunk]$ ls -l Bloc\ Party\ -\ Silent\ Alarm
total 559364
-rw------- 1 thomas thomas 35797484 2009-05-15 16:25 00. Bloc Party - Hidden Track One Audio.wav
-rw------- 1 thomas thomas 46214492 2009-05-15 13:01 01. Bloc Party - Like Eating Glass.wav
-rw------- 1 thomas thomas 38838620 2009-05-15 13:02 02. Bloc Party - Helicopter.wav
-rw------- 1 thomas thomas 41531660 2009-05-15 13:03 03. Bloc Party - Positive Tension.wav
-rw------- 1 thomas thomas 35519948 2009-05-15 13:03 04. Bloc Party - Banquet.wav
-rw------- 1 thomas thomas 29480012 2009-05-15 13:04 05. Bloc Party - Blue Light.wav
-rw------- 1 thomas thomas 36928796 2009-05-15 13:05 06. Bloc Party - She's Hearing Voices.wav
-rw------- 1 thomas thomas 46854236 2009-05-15 13:06 07. Bloc Party - This Modern Love.wav
-rw------- 1 thomas thomas 37977788 2009-05-15 13:06 08. Bloc Party - The Pioneers.wav
-rw------- 1 thomas thomas 45809948 2009-05-15 13:07 09. Bloc Party - Price of Gasoline.wav
-rw------- 1 thomas thomas 41082428 2009-05-15 13:08 10. Bloc Party - So Here We Are.wav
-rw------- 1 thomas thomas 41846828 2009-05-15 13:08 11. Bloc Party - Luno.wav
-rw------- 1 thomas thomas 44151788 2009-05-15 13:09 12. Bloc Party - Plans.wav
-rw------- 1 thomas thomas 50010620 2009-05-15 13:10 13. Bloc Party - Compliments.wav
-rw-rw-r-- 1 thomas thomas 1769 2009-05-15 22:33 Bloc Party - Silent Alarm.cue
-rw-rw-r-- 1 thomas thomas 1002 2009-05-15 16:27 Bloc Party - Silent Alarm.m3u


Notice the first file - it's the hidden track one audio. The .cue file references it properly as well. The metadata is retrieved from MusicBrainz (that got added some night last week), and the files are named according to a template (I'm still not sure I like having the track number in my file names, but a certain site demands it). The files match the AccurateRip database, so this rip is basically as good as you can get with EAC. CDText and ISRC codes also get written to the .cue file (although this particular disc doesn't have CDText).

Things still left to be done, in no particular order:

• write a command-line frontend
• write a GUI
• have the second step of the read-and-verify task encode directly to flac (or another lossless format)
• write out a log file (involves interpreting cdparanoia's stderr-progress output, which looks a little tricky
• add code to allow choosing a device
• add some kind of config file so that, for each device (by name), an offset can be stored

That's quite enough for tonight. Hopefully I feel better tomorrow.

Today was not a particularly good day - I woke up with a huge headache around 4, took a dafalgan, went back to bed, and woke up around 8:30, still...

Somehow I spent all this time on this planet without ever learning that in C,
numbers[4] == 4[numbers]

Arrays are just simply syntactic sugar.

I feel robbed of my childhood!

Come on, go ahead and tell me how you realized this when reading K&R back when you were 6 and writing BASIC interpreters in assembler for fun!

Somehow I spent all this time on this planet without ever learning that in C, numbers[4] == 4[numbers] Arrays are just simply syntactic sugar. I feel robbed of my childhood!...

To take a break from my personal hacking on CD rippers and jukeboxes, I wanted to hack a little on a Flumotion feature.

Now the feature in question was thought up years ago, just like many features we have. Our problem has never been 'what should we implement', it's always been 'in what order do we implement all the things we could do ?'

Anyway, this particular feature is the idea of being able to request a live stream, but going back in time. So instead of seeing what is on now, you could ask to see what was on 30 minutes ago. And you'd connect, get data from that point back in time, then continue as if it was a live stream.

I of course think all my ideas are great, without question. And I've learned to accept over time getting older that everyone else doesn't realize, and so doesn't pick up on these great ideas I'm having. (Who was it again that said irony doesn't work on the internet ?)

Yesterday, in a boss meeting, I was asked to come up with reasons why we stream over HTTP and not over other protocols. I casually threw in a 'you know, we could do crazy things like rewinding in a live stream, or showing what was on half an hour ago.' Which drew a 'hm, that's interesting' from my boss, instead of a usual grunt while he's typing away on his MacBook and fielding a call on his iPhone.

Today, our product manager mails me and says he heard from our boss about this idea, and told me that would be a killer feature to have. So I dutifully replied to some questions he had.

Now, these days, our development process is a bit more structured, so I have two ways of seeing if this can actually work. I can either create a ticket, draft up some requirements, get it on a roadmap for a development cycle, and work with a developer on the team to explain and help out and maybe have something in a few months.

Or, I could just prototype it myself to see if it works, and go the Far West way!

Coming back tonight from tango class, I had been thinking on how I would actually implement it, and started hacking it in as a proof of concept. Basically, I wanted to extend the burst buffer of multifdsink (the GStreamer element responsible for doing the actual streaming) to, say, an hour, and parse a GET parameter like 'offset' in the HTTP request to start bursting from that time offset in the stream.

An embarassing multifdsink bug fix and some flumotion mutilating later, I have this to show for my evening:

While it doesn't look that exciting, the screenshot shows a flumotion-launch pipeline, and a gst-launch pipeline with three playbin's playing the same live stream, but each with a different offset (a minute away each).

The 3 playback windows thus show 3 streams, roughly offset by a minute from each other. The time displayed is the system time at the time of frame generation. The slight difference from the requested offset is due to the fact that the streams start at a keyframe.

Not bad for a night of hacking.

Now, to actually get this nicely integrated, productized, supportable, and deployed on our platform is another matter. But now I can package up the ugly bits of hacks I did and hand it off to the team for analysis.

Maybe this is what our development manager meant when he said I should go back to hacking Flumotion once in a while?

To take a break from my personal hacking on CD rippers and jukeboxes, I wanted to hack a little on a Flumotion feature. Now the feature in question was thought...

After a weekend full of refactoring code, adding tasks, and putting pieces together, combined with last night's airplane session, I have my first AccurateRip-verified rip done:


[gst-git] [thomas@level trunk]$ PYTHONPATH=$PYTHONPATH:`pwd` python examples/readdisc.py --offset 6 --table-pickle=peel1.table.pickle --toc-pickle=peel1.toc.pickle
Ripping track 1
Checksums match for track 1
Ripping track 2
Checksums match for track 2
Ripping track 3
Checksums match for track 3
Ripping track 4
Checksums match for track 4
Ripping track 5
Checksums match for track 5
Ripping track 6
Checksums match for track 6
Ripping track 7
Checksums match for track 7
Ripping track 8
Checksums match for track 8
Ripping track 9
Checksums match for track 9
Ripping track 10
Checksums match for track 10
Ripping track 11
Checksums match for track 11
Ripping track 12
Checksums match for track 12
Ripping track 13
Checksums match for track 13
Ripping track 14
Checksums match for track 14
Ripping track 15
Checksums match for track 15
Ripping track 16
Checksums match for track 16
Ripping track 17
Checksums match for track 17
Ripping track 18
Checksums match for track 18
Ripping track 19
Checksums match for track 19
Ripping track 20
Checksums match for track 20

CDDB disc id 21115314
AccurateRip URL http://www.accuraterip.com/accuraterip/c/2/c/dBAR-020-00362c2c-031aaa3e-21115314.bin
2 AccurateRip reponses found
Track 1: rip accurate (confidence 11 of 17) [b29a0c41], AR [b29a0c41]
Track 2: rip accurate (confidence 11 of 17) [2ee8800e], AR [2ee8800e]
Track 3: rip accurate (confidence 11 of 17) [9f2dbab2], AR [9f2dbab2]
Track 4: rip accurate (confidence 11 of 17) [467010a7], AR [467010a7]
Track 5: rip accurate (confidence 11 of 16) [f5b0c850], AR [f5b0c850]
Track 6: rip accurate (confidence 11 of 16) [679dbc4c], AR [679dbc4c]
Track 7: rip accurate (confidence 11 of 14) [feddbbef], AR [feddbbef]
Track 8: rip accurate (confidence 11 of 16) [f46adb28], AR [f46adb28]
Track 9: rip accurate (confidence 11 of 16) [cac7a069], AR [cac7a069]
Track 10: rip accurate (confidence 11 of 16) [3f3a1521], AR [3f3a1521]
Track 11: rip accurate (confidence 11 of 16) [80fb00b4], AR [80fb00b4]
Track 12: rip accurate (confidence 11 of 16) [f1534ce2], AR [f1534ce2]
Track 13: rip accurate (confidence 11 of 16) [5953768f], AR [5953768f]
Track 14: rip accurate (confidence 11 of 16) [6e6c2a7e], AR [6e6c2a7e]
Track 15: rip accurate (confidence 11 of 16) [24d519a4], AR [24d519a4]
Track 16: rip accurate (confidence 11 of 16) [21509f9e], AR [21509f9e]
Track 17: rip accurate (confidence 11 of 16) [3e4be9f8], AR [3e4be9f8]
Track 18: rip accurate (confidence 11 of 16) [16ff964f], AR [16ff964f]
Track 19: rip accurate (confidence 11 of 16) [6db5f2b1], AR [6db5f2b1]
Track 20: rip accurate (confidence 10 of 16) [bb898cec], AR [bb898cec]


This version does full index scanning (gap detection) using cdrdao, read and verify using cdparanoia and an offset, .cue file writing (non-compliant .cue, which means gaps/index 00 are appended at end of previous track), and AccurateRip verification.

It doesn't do Hidden Track One Audio ripping yet (which will now be easy to add, but I forgot to bring a CD that actually has a HTOA to test with), doesn't do any kind of metadata lookup (so tracks are named track%02d.wav), no encoding to other formats, and no log file generation.

But those are the easy parts...

After a weekend full of refactoring code, adding tasks, and putting pieces together, combined with last night's airplane session, I have my first AccurateRip-verified rip done: [gst-git] [thomas@level trunk]$ PYTHONPATH=$PYTHONPATH:`pwd`...

Hey all you Unix heads and sysadminny/developer types,

should .pid files be cleaned up on a reboot, because the processes definately went away ? If so, which part of the system should take care of this ? Each and every service script on its own somehow ? If not, why ?

Answers on a postcard or in the comments!

Hey all you Unix heads and sysadminny/developer types, should .pid files be cleaned up on a reboot, because the processes definately went away ? If so, which part of the...