Present Perfect

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...

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:

• lossless ripping
• accuracy is the number one goal
• speed is always second to accuracy
• hands-off one-click/command ripping
• separate ripping from metadata fixing
• rip hidden track one audio automatically

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:

• checks if the current CD is in the AccurateRip database
• if it is, rip the first track with various offsets
• if any of the AccurateRip checksums match, that is most likely the offset for your drive

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":

[gst-git] [thomas@ana trunk]$ PYTHONPATH=$PYTHONPATH:`pwd` python examples/ARcalibrate.py
CDDB disc id 8a0aa10b
AccurateRip URL http://www.accuraterip.com/accuraterip/9/f/f/dBAR-011-00112ff9-00976269-8a0aa10b.bin
4 AccurateRip reponses found
ripping track 1 with offset 46
AR checksum calculated: b880421e
ripping track 1 with offset 47
AR checksum calculated: 4a29a173
ripping track 1 with offset 48
AR checksum calculated: 903b390e
MATCHED against response 3
offset of device is 48
ripping track 1 with offset 49
AR checksum calculated: e7c008f1
[gst-git] [thomas@ana trunk]$


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.

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...

A few weeks ago a few neurons tragically misfired, causing me to click a buy button on a 20 item shopping cart at Amazon.

Really, I just wanted to buy Overqualified, after reading how Joey sold out his first run already and realizing I did not want to wait for a second print. But somehow I thought I'd optimize my costs if I added some more stuff from my wishlist.

Anyway, the post office had trouble finding the books I had ordered. Probably because instead of a normal box, the books were packaged in this:
71068

Inside was the traditional Amazon box:
71071
Sadly, things that look like a bag are thrown around like a bag. The soft carton inside the bag was not strong enough to protect the books inside of being damaged.

If your spine reading is good, you can see what I ended up ordering:
71077

The problem is I already had stuff I still have to read; I have a special hole in my bookshelf just for that:
71074

Maybe it's time for another week of stay-at-home-holiday...

(This post brought to you by the Gallery2 for WordPress plugin)

A few weeks ago a few neurons tragically misfired, causing me to click a buy button on a 20 item shopping cart at Amazon. Really, I just wanted to buy...

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:

[gst-git] [thomas@ana trunk]$ PYTHONPATH=$PYTHONPATH:`pwd` python examples/readhtoa.py
Found Hidden Track One Audio from frame 0 to 15220
runner done
Checksums match
[gst-git] [thomas@ana trunk]$ ls -l track00.wav
-rw------- 1 thomas thomas 35797484 2009-05-01 21:56 track00.wav


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.

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...