Introducing Rip Rip Hooray!

Traditional CD-ripping software takes a stern, law-and-order approach to error recovery: when a drive won't give up the requested data, they simply beat it senseless for hours or days straight until it confesses.

That naive and abusive strategy doesn't work any better against machines than it does against people1, but it persists for systemic reasons.

CD-ripping software is optimized for violence work quick and efficient data transfer. By repeatedly filling and flushing tiny read buffers, vast amounts of information can be copied with minimal fuss and overhead.

But playing hot potato with the data comes with an important tradeoff: data can only be inspected and reacted to in realtime, and at the expense of everything else.

The design constraints leave no room for nuance. If the software looks for trouble and finds it, it has no choice but to slam on the breaks and deal with it then and there.

Hence the brass knuckles.

Thankfully, there's more than one way to design a cat.

Rip Rip Hooray!

The new Linux command-line2 audio CD-ripper Rip Rip Hooray! is specifically designed and optimized for track recovery.

Unlike traditional CD-rippers, Rip Rip doesn't need to grab every last bit in any single all-or-nothing session. It's stateful. It keeps track of each and every sample value and status returned by the drive so that if/when it is re-run, it can pick up from where it left off, focus on the areas that need improvement, and ignore the rest.

Iteration frees Rip Rip to read what it can, as it can, without having to grind to a halt for each and every little error. If there's a problem, it simply notes it and moves on. It'll export the best-available track data after each pass, complete or not, in minutes rather than hours or days.

And because Rip Rip can be re-run at will, you can actually do things in between the passes to improve your chances of successful recovery. You can inspect the disc, give it a clean, switch optical drives, adjust the thermostat, sacrifice a goat to Athena, try CUETools repair3, or simply turn off your computer and go to bed.

Rip Rip Hooray! is all about working smart, not hard.

It will recover at least as much data as a traditional CD-ripper4, significantly faster, more accurately5, and with less wear-and-tear on the drive.

By any metric, Rip Rip simply does recovery better.

But optimization is a double-edged sword, and Rip Rip's design choices came with their own set of challenges and constraints.

The Cost of Thoroughness.

Rip Rip Hooray! assumes the worst, and plans for it. It can't simply hand off data and forget about it; it needs to see the Big Picture.

Rip Rip keeps track of every sample value, status, and contradiction returned by the drive. It holds these in-memory while processing a track, and saves them to disk for future reference.

And all that data adds up.

Rip Rip's peak runtime memory usage6 and (temporary) storage requirements are several times higher than traditional CD-rippers', and its best-case read speeds are usually slower7.

Its preparation pays off when there are problems. Rip Rip can selectively focus its efforts, make informed decisions about which values are most likely, and avoid getting bogged down by each and every little error.

But ironically, when everything's fine, all that effort amounts to just so much unnecessary overhead.

Ripping a pristine, perfectly-readable disc with Rip Rip is overkill.

Closing the Tray.

If you're still ripping audio CDs in 2023, good news! It has just gotten a little bit easier to rip discs that have lived a full and wild life.

Rip Rip Hooray! is uniquely focused on recovery, and as such, is noticeably better at dealing with iffy data than other CD-rippers.

On the other hand, that focus makes it less efficient at dealing with the day-to-day discs that don't require all that effort.

As with anything, the trick is to choose the right tool for the job.

Most of the time, a solid, traditional CD-ripper like fre:ac will get the job done. Just make sure you disable its advanced error recovery options, or you could be in for a very long ride.

For everything, there's Rip Rip Hooray!TM


1. Which is not to say it never works. Surficial wear-and-tear can affect sector readability in extremely subtle ways. Minute variations in the alignment and intensity of the laser, the position of the disc within the tray, the ambient temperatures, etc., can all make a difference. By re-attempting reads dozens of times, it's remotely possible that the right combination of environmental factors will miraculously fall into place.

2. Rip Rip Hooray! is developed and tested under 64-bit Debian/Ubuntu, but is built with Rust and libcdio — both of which are cross-platform — so will probably also work on plenty of other Unix-y platforms, and maybe even Windows WSL. Check out the project page for more information.

3. CUETools is a completely separate program developed by other people, but if anybody happens to know how its repair functionality actually works — CUETools is very poorly documented — I would definitely consider integrating that functionality directly into Rip Rip Hooray!

4. The upper limit — how much data can potentially be recovered — is ultimately determined by the optical drive rather than any particular software, but since Rip Rip Hooray! allows you to change any number of environmental factors between reads, including the drive itself, it can get you closer to that ceiling.

5. Audio CDs have lossless storage fidelity, but in practice it can be extremely difficult to actually read that data losslessly. The reasons and workarounds are definitely interesting, but require an article all their own. Stay tuned!

6. Rip Rip Hooray!'s memory usage varies based on the length of the tracks being ripped, peaking with the longest. Most of the time a few hundred megabytes of RAM will suffice, but in a worst-case scenario, like the 74-minute, single-track album Delirium Cordia by Fantômas, it'll gobble up nearly 3GiB!

7. Rip Rip reads aren't so much slow as steady. It doesn't have anything like a "burst mode". It reads data carefully, block by block. It neither stops nor soars.

Josh Stoik
9 October 2023
Previous Installing CUETools 2.2.4 on Linux via WINE
Next Building a Custom XanMod Kernel on Ubuntu 23.10