Verifying a CD rip against AccurateRip correctly

This writeup comes out of the work behind RE-MOCT, a terminal music player and AccurateRip-verifying CD ripper. It is aimed at anyone building a ripper, a verifier, or a now-playing display for physical media. The audio always rips fine — the hard part is proving the rip is bit-perfect, and that part is buried in undocumented binary formats and a single number that everyone misreads.

01The 150 is physical, not a constant

AccurateRip does not checksum each track from zero. It accumulates a position-weighted sum where every stereo sample is multiplied by its disc-absolute position — a running mul_by that counts samples across the whole disc timeline, not per track.

Because the weight is disc-absolute, track 1's CRC includes a fixed 150-sector lead-in preamble that sits before the offset-corrected start of track 1. That is 150 × 588 = 88,200 samples of positional phase baked into where the accumulation begins. The 150 is fixed by AccurateRip's design as a disc-geometry anchor. It is not a per-drive value, and it is not something you “fix” when checksums disagree. This is confirmed in the long-running HydrogenAudio discussion (topic 97603).

02Three things people conflate

Almost every “AccurateRip won't match” thread is really a mix-up between three different quantities:

1. Drive read offset — per-drive, in samples, looked up from a drive-offset table. Corrects where your optical drive physically starts reading relative to the disc.
2. Pressing offset — per-pressing, in samples, detected rather than looked up. Different plants stamp the program area at slightly different positions.
3. The 150-sector preamble — not an offset at all. A fixed phase anchor that decides where the disc-absolute weight starts. Constant for every disc, every drive.

The drive offset and pressing offset are real, signed, and applied to the read position. The 150 preamble is not tunable. Muddling the three is the root cause of most of the folklore around this number.

03The disc ID — the handshake key

AccurateRip is keyed on a disc ID computed entirely from the TOC — the track start positions, the leadout, and the track count. The one thing to get right is the reference point. AccurateRip works in LSN (logical sector numbers), so a fixed 150-frame lead-in is stripped from every absolute LBA — each track start and the leadout — before the values are hashed.

It is tempting to instead normalize against track 1's own start. That is wrong: it zeroes track 1's pregap and 404s on any disc with a non-standard pregap. Joan Osborne's Relish is the textbook case — track 1 sits at LBA 182, so its relative value is 32, and that 32 has to survive into the ID for the lookup to hit. Fixed 150, not track-1-relative. It is the same physical 150 from section 01, showing up a second time.

// LSN: strip a FIXED 150 lead-in, NOT track 1's start
const uint32_t PREGAP = 150;
uint32_t id1 = 0, id2 = 0;
for (int i = 0; i < n; ++i) {
    uint32_t rel = track[i].start_lba - PREGAP;
    id1 += rel;                    // sum
    id2 += max(rel,1u) * (i+1);    // weighted
}
id1 += leadout - PREGAP;
id2 += (leadout - PREGAP) * (n+1);

The lookup is a plain HTTP GET (http, not https). The path buries the IDs in a specific shape: the directory components are the last three hex digits of disc-id1, in reverse, and the filename carries the track count and all three hashes:

http://www.accuraterip.com/accuraterip/
  a/b/c/dbar-NNN-<id1>-<id2>-<cddb>.bin

Here a, b, c are hex digits 8, 7, 6 of id1 (its three lowest nibbles, reversed); NNN is the track count zero-padded to three digits; id1 and id2 are the two AccurateRip disc IDs above; and cddb is the FreeDB/CDDB disc ID — a third, separate hash. Everything is lowercase. HTTP 200 means the disc is known and the body is the verification data; a 404 means this exact TOC is not in the database — not that your rip is wrong, just that nobody has submitted this pressing yet.

04The response is a binary blob

The .bin body is a packed binary structure, not JSON or text. Parsed out, it gives you — per track, across all the pressings people have submitted — a confidence count and the expected v1 and v2 checksums. Confidence is just how many independent rippers agree; a match at confidence 200 means two hundred other people ripped the same pressing to the same bits.

05Computing the CRC (v1, v2, and the one nobody mentions)

Each stereo sample is packed into 32 bits — left in the low half, right in the high half — and multiplied by its disc-absolute mul_by. The 64-bit product is split: the low 32 bits feed the v1 accumulator, and v2 adds the high-32 accumulator on top. That is the whole formula (the “whipper” formulation):

// s packs L|R (16-bit); mulBy = disc-absolute pos
const uint32_t s = (uint32_t)(uint16_t)l
                 | ((uint32_t)(uint16_t)r << 16);
const uint64_t product = (uint64_t)s * (uint64_t)mulBy;
csumHi += (uint32_t)(product >> 32);
csumLo += (uint32_t)(product);
// v1 = csumLo ;  v2 = csumLo + csumHi

There is also a third checksum that most explanations skip entirely: a CRC over a single sector at frame 450 of track 1 (samples 450×588+1 through 451×588), computed two ways — a local weighting and a disc-absolute one. It exists purely to detect the pressing offset by sliding this small window until the two forms line up with the database. It is a forensic probe, not part of the pass/fail verification.

06Why the naive offset handling breaks

The total offset (drive + pressing) is a single signed sample skip that has to be split into a whole-sector LBA advance plus a sub-sector sample skip. The obvious way — C's / and % — is wrong for negative offsets, and it fails silently:

// FLOORED: sub_skip stays 0..587 for either sign
int adv = total_skip / SECTOR_SAMPLES;  // 588/sector
int sub = total_skip % SECTOR_SAMPLES;
if (sub < 0) { sub += SECTOR_SAMPLES; --adv; }

Truncating division on a negative offset produces a negative sub-sector skip, which does two damaging things at once. It underflows the preamble source pointer into an out-of-bounds read, and on the main rip path (gated “> 0”) it is silently dropped, so samples get fed at the wrong disc-absolute mul_by — the wrong CRC phase. You get a deterministic wrong answer, not a crash, which is the worst kind of bug. The same reasoning forces the preamble bounds check into signed space: a track close to LBA 0 must decline gracefully, not wrap a negative advance up to ~4 billion. This is the AccurateRip equivalent of “just take entry 0” — the version that looks right and desyncs in the wild.

07The retry pass

On a no-match, the answer is usually the drive's own read cache handing back a previous read instead of fresh optical data. The retry is not an algorithm change: flush the hardware cache, re-read the track at 1x, and recompute. Match found on either pass → bit-perfect verified. The full flow:

08Takeaway

The one thing to remember: AccurateRip weights every sample by its position on the whole disc, so track 1 carries a fixed 150-sector preamble before its corrected start. That 150 is disc geometry, not a knob. Build the disc ID by stripping a fixed 150 from every LBA (not by normalizing to track 1), apply the drive and pressing offsets with floored (not truncating) division, compute v1 and v2 by the packed-sample position weighting, and use the frame-450 window to find the pressing offset. Do that and a genuine bit-perfect rip matches the database — and when it doesn't, you know the failure is real, not a number you forgot to tune.