Present Perfect

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