redumper dumps a CD byte for byte, and tells you when it could not

Why a disc dumper needs to be slow and honest

redumper is described as a cross-platform command-line tool for creating accurate optical disc dumps, and its feature list makes the priorities obvious. Low-level, byte-perfect acquisition for CDs comes first, with incremental refinement, SCSI and C2 error recovery, raw subchannel preservation and automatic audio-offset detection. DVD, HD DVD and Blu-ray dumping is supported at a higher level, alongside raw DVD and Blu-ray sector dumping, console disc dumping, CSS key extraction and Xbox media handling.

The tool was originally created for the Redump disc-preservation initiative and is now the default dumping software used for Redump optical disc submissions. That origin explains a great deal about the design. A preservation dump is not a copy: it is an acquisition in which every sector is read, every error is either recovered or reported, and the result is a file whose hash can be checked against every other dump of the same disc. A tool that quietly skipped the sectors it could not read would be worse than useless, because it would produce plausible images that differ from the disc.

Two details make that concrete. By default redumper records errors but performs no sector retries, so the default behaviour is to tell you what went wrong rather than to hammer the drive hoping a retry succeeds. And existing output files are protected unless `--overwrite` is supplied, so a second run cannot quietly replace a good image with a partial one.

It is written from scratch in C++ and runs on Windows, Linux and macOS.

The quick start is one command, and the defaults are conservative

You download the archive for your platform from the latest GitHub release and extract it. The release workflow publishes x86, x64 and ARM64 builds where supported. There is no installer and no configuration file to write first.

Insert a disc and run the tool with no arguments:

redumper

That is equivalent to `redumper disc`, the aggregate workflow that dumps the disc and produces the applicable output files. Unless you configure it otherwise, redumper selects the first available drive containing a disc and generates an image name from the date and the drive identity.

The retries default is the part to understand before you start, because it is the difference between a diagnostic run and a preservation run. To retry SCSI and C2 errors, you give it a count:

redumper disc --retries=100

The complete option reference is in the tool itself:

redumper --help

The feature list also names the verification and analysis side of the tool: protection analysis, image information, hashing and skeleton generation. Hashing is what closes the loop on the whole exercise, since a preservation workflow is only meaningful if two independent dumps of the same disc can be compared byte for byte, and the README does not document a rollback or a resume procedure for a dump that fails halfway, so a failed run is a failed run.

Per-platform drive selection, and the Linux block device trap

The same command has a different shape on each platform, because the drive is named differently, and one of these distinctions causes real errors.

On Windows you give the drive letter, and the trailing colon is optional:

redumper --drive=E:

On Linux you give the generic SCSI device, and the README is explicit about the difference:

redumper --drive=/dev/sg1

Use `/dev/sgN`, not `/dev/srN`, because redumper sends SCSI commands that change drive state, such as the requested read speed. A block device path will not give you that access. The disc must also be unmounted before redumper touches it, and if automatic drive detection fails on a distribution whose sysfs layout differs from the kernel convention, you pass the path explicitly. On a dedicated dumping system, disabling removable-media automounting is recommended, which stops the system from trying to mount a disc mid-acquisition.

On macOS you give the BSD name, which `diskutil list` will tell you:

redumper --drive=disk2

The macOS archive is worth understanding before you copy anything out of it. It contains `bin/redumper` together with private C++ runtime libraries under `lib`, and the executable resolves those libraries relative to its own location through `@executable_path/../lib`. Move the whole directory tree rather than copying the executable alone, or it will not start.

The macOS IOKit error that does not mean what it says

macOS 10.15 and later place Desktop, Documents and Downloads behind a privacy-controlled Files and Folders policy, and that policy applies to command-line programs through the terminal that launched them. redumper needs more than ordinary file access: after unmounting the disc it asks IOKit to create an MMC device user client, obtains a `SCSITaskDeviceInterface`, and requests exclusive access so it can send raw SCSI commands straight to the drive.

When the tool is launched from a privacy-controlled directory and macOS blocks that IOKit user-client plug-in, `IOCreatePlugInInterfaceForService` returns `kIOReturnNoResources`. IOKit formats that generic status as a resource shortage, so the error message reads like the machine is out of memory or disk space. It is not. The tool reports it as:

error: failed to create service plugin interface, MACH ((iokit/common) resource shortage)

The fix is positional, not technical. Move the entire extracted redumper directory to a normal local location outside Desktop, Documents and Downloads, for example `~/Applications/redumper`, and run `bin/redumper` from there. That preserves the executable-to-library layout and avoids the privacy boundary while redumper establishes its IOKit SCSI connection.

This is the clearest example of the project's documentation style. It names the exact API call, the exact status code, the misleading plain-English reading of the status, and the concrete directory to move to, which is more useful than a sentence telling you to check your permissions.

Drive support is a database, and you can read it from the binary

For accurate CD dumping you need a drive redumper recognises, and the requirement is specific rather than generic. Compatible PLEXTOR drives use vendor-specific negative-range D8 CDDA access, which is what allows redumper to recover the complete disc lead-in. Supported LG, ASUS, LITE-ON and other MediaTek-based drives use the BE CDDA path and, where available, vendor-specific cache access.

The authoritative list is the `drive.ixx` file in the repository, and the installed executable can print it, either the recommended set or everything known:

redumper --list-recommended-drives
redumper --list-all-drives

Generic MMC drives can be used experimentally, but firmware limitations may prevent a complete or byte-perfect CD dump. DVD, HD DVD and Blu-ray dumping generally does not require a specific model. Xbox and Xbox 360 DVD media are the exception, needing a compatible drive with Kreon or OmniDrive firmware.

OmniDrive firmware opens the raw acquisition paths, which you enable explicitly:

redumper disc --drive=<drive> --dvd-raw
redumper disc --drive=<drive> --bd-raw

With OmniDrive in place, redumper also dumps Xbox, Xbox 360, Nintendo GameCube, Wii and Wii U discs, detecting those proprietary formats and using the appropriate raw path on its own, with Nintendo discs descrambled as part of the dump and no extra raw-mode option required. The one adjustment the README suggests for SCSI errors under OmniDrive is a lower transfer length through `--dump-read-size`.

drive::test replaces the guesswork of an unknown drive

If you own a drive that is not in the database, the README describes a diagnostic that has replaced the older manual generic-drive evaluation procedure. `drive::test` is the command, and it needs a known-good mixed-mode CD containing at least one data track and one audio track:

redumper drive::test --drive=<drive>

What the test probes is listed explicitly. It checks the supported READ CD variants and sector layouts, D8 support, PLEXTOR lead-in access, readable pre-gap and lead-out ranges, and the MediaTek F1 cache-read command. A `--verbose` option is mentioned for more detail.

This is a genuinely useful piece of tooling, because the two capabilities it checks, lead-in access and the pre-gap and lead-out ranges, are exactly the ones that determine whether a CD dump can be byte-perfect. A drive that reads the main programme area fine but cannot reach the lead-in will produce an image that differs from the disc in a way that is easy to miss unless you know to look. The test tells you which capability is missing rather than leaving you to infer it from a hash mismatch weeks later.

The repository layout backs this up. The top level is a wide spread of modules: `cd/`, `dvd/`, `drive/`, `scsi/`, `readers/`, `hash/`, `crc/`, `filesystem/`, `systems/`, `utils/`, `tests/` and `analyzers/`, alongside the `.ixx` interface files such as `drive.ixx`, `hash.ixx`, `offsets.ixx`, `options.ixx`, `range.ixx`, `rings.ixx` and `skeleton.ixx`. The `CMakeLists.txt`, `cmake/` directory, `.clang-format` and `.clang-tidy` files show a C++ project with the tooling to keep it consistent, and `version.ixx` explains where the build numbers come from.

Incremental refinement, subchannels and what the image actually contains

Several features only make sense once you know what a preservation image is trying to be.

Sample-granular dump state for incremental refinement across multiple drives is the headline. Because a dump is recorded at sample granularity rather than as a whole-block pass, a second drive can be brought in and asked to fill in the sectors the first one could not read, instead of starting over. For a disc with a damaged region, that is the difference between one attempt and a collaboration.

Raw, uncorrected subchannel storage is the other. Ordinary ripping tools tend to reconstruct subchannel data from what the drive reports, and the reconstruction can differ between drives. Storing it raw and uncorrected preserves what the drive actually returned, with TOC-based and Q-based track splitting available. Lead-in, pre-gap and lead-out extraction on supported drives is listed separately, again because a complete image needs the regions outside the tracks.

Automatic drive read-offset correction and disc write-offset detection handle a different problem: drives read at slightly different positions, and a disc may have been written with an offset that a consumer player silently compensates for but a byte-exact dump must reproduce faithfully. Getting this wrong produces images that play correctly and still differ from the disc.

The full feature list also includes protection analysis, which is how you find out that a disc is protected before you wonder why the dump failed.

Editorial conclusion

Adopt redumper if you are preserving optical media and need a dump that is byte-perfect and verifiable, particularly for CDs where the drive and the error recovery path decide whether the image is correct. Do not adopt it as a general disc ripper for personal listening copies, and do not expect it to work on a generic MMC drive, because the documentation says firmware limitations may prevent a complete or byte-perfect CD dump there. Before your first attempt, run `redumper --list-recommended-drives` against your own drive, keep the disc unmounted on Linux, and on macOS move the extracted directory out of Desktop, Documents and Downloads before the IOKit SCSI connection is refused.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. superg/redumper on GitHub