![[lang]](/images/eye.png)
|
Present Perfect |
|||||||||||||||||||||||
|
Somehow I spent all this time on this planet without ever learning that in C, 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!
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?
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:
CDDB disc id 21115314 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...
While I'm working on the ripping software, I find myself going back and forth between various references to figure out the small details and the pieces that subtly get interpreted differently between them. As is the case with other projects, I can easily see myself forgetting about these details soon, and cursing myself a year from now for not having written down my clear understanding of today. So, in an effort to appease my future self, I've started writing down a condensed form of the important information I've come across. On that page, I'm also comparing various ripping programs and how they handle the various details I consider important for correct ripping. I'll use that information and that chart as the basis for the features of my ripping program. I'm trying to stay as objective as possible on that page, so feel free to tell me about mistakes, omissions, software I should be adding, ... By now, I have a good set of goals for my ripping program:
With this in mind, I thought yesterday how I could figure out the drive's read offset the way EAC does it. I've come up with a simple program that:
It took longer to test the program than to write it, since my AccurateRip checksum calculation is currently done purely in Python and thus rather slow. In any case, using Bat For Lashes' "Fur and Gold": I made the program scan from 46 to 49, knowing that my drive has a +48 read offset. Now I'm going to add an option to choose the range, an option to start with the most common offsets, and think about including using online databases of drive features to start with the one most likely to be correct for your drive.
After another day of on-and-off hacking, wrapping cdrdao and cdparanoia binaries in my task interfaces I mentioned before, I inserted a CD by Bloc Party called 'Silent Alarm', ran a command, and saw the following output on my screen: I'm going to guess this is the first piece of Linux code that is able to automatically find and rip the hidden track at the start of a CD. (Feel free to correct me using your choice of alliterative insult if I am wrong!) It's time to start collecting all my new-found wisdom in something more permanently written down, but that will be for tomorrow. |
|||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||
