Adventures in recovering DVD data for a client.

Short version: most of the discs read perfectly first time. The handful that didn’t taught us more in a week than the rest of the box put together. Two discs that looked dead turned out to be unfinalised, never closed off by the recorder that made them, and one of those read completely in seven and a half minutes once it was on a machine that didn’t panic at the sight of it. One disc had genuinely faded, and after four days of careful reading we recovered 3.6% of it and called it. Along the way we found that the biggest factor wasn’t the drive or the disc, it was how long the computer spent on each failed read: about 200 seconds on our Mac, about 3 to 5 seconds on a Linux laptop. The job is still going: one disc was mid-way through a 70-hour scrape when we wrote this.

If you want the method rather than the story, it’s in our guide to whether a damaged or unfinalised DVD can be saved. This page is the diary.

The brief

A client brought us a box of recordable DVDs, most of them made on standalone DVD recorders, and asked for them preserved on a hard drive. Nothing exotic: get everything off, prove it’s right, hand it back with the discs.

John’s outline was four words long: checksum, log, transfer, re-check. We turned that into a few rules before a single disc went in:

1. Every disc gets its own ID for life. Recorder discs all have the same generic label, so the label tells you nothing. Our ID goes on the sleeve and in every file name and record.
2. Image first, files later. Each disc is copied sector by sector into an image file with GNU ddrescue, which keeps a map of what read and what didn’t. An image with a 100% map proves every sector came off the disc and passed the disc’s own error checks (ECMA-267 describes those checks for DVD). An image without a map is just a copy.
3. SHA-256 for everything, and re-check copies from a cold start, not straight after writing them. (A quick test on the Mac showed why: hashing the same 4 GiB file a second time ran at 1,198 MiB/s, which is memory speed, not disk speed. Only after unplugging and remounting the drive did it drop back to about 140 MiB/s, read off the disk itself. A hash from memory proves the copy in RAM, not the copy on the drive. Our lesson on how computers check data explains the hashing.)
4. Recover the maximum, then say exactly what’s missing. For our own music CDs the rule is the opposite: give up on a bad disc early. For a client’s only copy, you don’t.
5. Hashes and structure only. The machines record sector addresses, sizes, timings and hashes. Nobody opens, plays or previews the client’s files to check them.

Day one: the Mac rack

The main rig is a Mac mini with ten USB DVD drives in a rack, each with a name. (They’re called things like eric, joe and samantha. It helps when you’re shouting across a room about which tray to open.) It was built for ripping John’s own music, so the first job was a separate system for client data: its own folders, its own register, and nothing shared with the music conveyor.

The first client disc went in on the evening of 05/10/2026: 1.9 GB, imaged, verified byte for byte against the disc, in about 12 minutes. Encouraging.

The next two discs wedged their drives. One of them had to be freed with a paperclip.

By the afternoon of 07/10/2026 the dashboard read 15 verified, 1 partial, 2 deferred, 2 on hold, 3 duplicates, and five more queued or imaging. By that evening, 22 discs’ worth of verified images (21 complete, one partial) were on a separate external drive, every file re-hashed with the cache bypassed and every hash matching. The bulk of the job was, honestly, uneventful. Which is the point of building the boring parts properly.

The discs that wouldn’t

Four discs made up the interesting pile.

The stubborn disc failed in the same place, 0.7 to 1.4 MB in, on two different drive models. When two different drives fail at the same address, the fault is on the disc, not in the drive. There were more errors every few megabytes further in. At the rate the Mac was going, it projected about eight hours for this one disc, and it would hold up the queue the whole time.

The blank-looking disc failed every read in its first 2.5 MB, including the two sectors where a computer looks to find out what’s on a disc at all (sector 16 and sector 256, as set out in ECMA-119 and ECMA-167). Our script declared it UNREADABLE. That verdict turned out to be ours to fix: 99.98% of the disc had never actually been tried. It also froze the Mac’s disk handling for about 40 minutes when it went in.

The two discs that froze the Mac never got as far as a read error. macOS tried to check them when they were inserted, stalled, and no disc ever appeared. They went on hold.

Why the Mac was so slow

We looked at the Mac’s kernel log to see where the time went. Every time ddrescue asked for a bad sector, macOS quietly retried it about 24 times, 8 to 9 seconds apart, before reporting the failure. That’s roughly 3.3 minutes per failed read, and ddrescue had no way to switch it off. A disc with a few hundred bad sectors becomes a disc that takes days.

That reframed the whole problem. ddrescue’s method was fine. The path between ddrescue and the drive was the bottleneck.

Reviewing our own work

On the night of 06/10/2026 we stopped and reviewed the protocol against what the discs had shown us. It was humbling in a useful way. Among other things:

• The “UNREADABLE” verdict counted never-tried sectors as bad, so a disc that was 0.02% tested could be declared dead.
• The rescued percentage came out blank whenever it was below 100%, because of how the number was padded.
• The damaged-file count was always 1, whatever the real number was. It was counting a header line.

All three were fixed and tested on simulated bad discs before the next real one went in. None of them would have shown up on a good disc. That’s the trouble with checking tools: they only get tested properly by the discs you hoped not to see.

The review also put a name to the blank-looking disc’s likely problem. On an unfinalised recorder disc the start of the disc is left empty until the recorder finalises it, which is what the DVD-R standard means by finalising, and the recorder keeps a temporary index elsewhere in the meantime (the DVD FAQ explains it). A disc whose start was never written fails exactly where a scratched or faded start would. Same symptom, completely different problem.

A second opinion on Windows

The next lever was a different machine. On 07/10/2026 we wrote up a Windows stage: give the discs the Mac couldn’t finish a second opinion in IsoBuster, a long-standing Windows recovery tool. IsoBuster talks to the drive directly, sets its own retry count, and reads a disc’s sessions and files directly instead of relying on the operating system, including on unfinalised recorder discs. Free version first, to see whether it found anything, before paying for a licence. The blank-looking disc went into it that evening.

We also briefed a do-it-ourselves version: a small Windows program that would talk to the drive directly, with our own timeout and retry count, and write maps ddrescue could read. The estimate for the useful core was about a week of building. Partway into the build, John stopped it: don’t build it yet, just plan it.

Then he asked the better question: what about a Linux laptop with a DVD drive in it?

Moving the hard discs to a Linux laptop

Linux changed the sums. GNU ddrescue runs natively there, with the same map format as the Mac, so a partial rescue can start on the Mac, continue on the laptop, and be merged back with nothing translated. Linux’s CD/DVD driver retries only a few times, its command timeout is a setting, and some drives let you lower their own retry count. A drive inside the laptop also avoids the USB adaptors that had been wedging on the rack. The week-long build shrank to about a day: a thin layer of our own around tools that already existed.

The laptop’s AI session started on the evening of 07/10/2026. Within about an hour it had built DG DiscRescue, our own Linux program: a small Python program that drives GNU ddrescue. It passed 24 out of 24 tests on simulated bad discs, including being killed mid-run and switched off mid-run. Ten minutes later it passed the real test: start a rescue, reboot the laptop, and watch it carry on at boot with nobody logged in. DG DiscRescue’s job is mostly to be careful:

• Probe first. Before reading any data, ask the disc what it is: the media type, whether it was finalised, its sessions, and where the recorded parts start and stop. An unfinalised disc gets imaged only where something was recorded.
• Prove it’s the same disc, every run. Before resuming from a saved map, re-read 64 sectors that were already rescued and compare them with the image. Recorder discs look identical. Merging two different discs gives you a wrong image that nothing will warn you about.
• Turn the retries down. It lowers the drive’s own retry count and the system’s timeout, so a bad sector costs seconds, not minutes, and puts both back when it stops.
• Work in budgeted sessions. Read for a fixed time, save the map, start again. The map is saved every 30 seconds in between, so a crash costs seconds, not hours, and after a restart the next session picks up where the last one stopped.
• Never write to the disc, never mount it, never re-read what’s safe. It refuses to start if anything that can write to a disc would run, never mounts a client disc, and never asks ddrescue to go over rescued sectors again.

The setup that needed administrator rights (no automatic disc checks on insert, no sleep, keep running with the lid shut, resume at boot) the AI wrote as a script, and John ran it himself. The agent wasn’t permitted to install system services, which is how it should be.

The stubborn disc: four days for 3.6%

The stubborn disc went in at 20:19 on 07/10/2026, seeded with what the Mac had already got: 3.47% of the disc. The first thing the laptop proved was the theory. Failed reads took about 5 seconds each instead of 200. Forty times faster.

The second thing it proved was that faster isn’t the same as better. Nearly every area it tried failed, right across the disc. John cleaned the disc at 21:00; no real change. The pattern, errors everywhere rather than one bad patch, pointed at the recording dye breaking down, which no amount of polishing reaches because the damage is inside the disc (NIST’s care guide covers how recordable dye degrades with heat, humidity and light). The AI’s suggestion at that point was a sensible one: ask the client whether another copy of this disc exists anywhere.

John let it run, first overnight, then for a few days to let the first pass finish. On 12/10/2026 at 04:46 he stopped it. After 190 sessions it had read 3.60% of the disc, about 5.7 MB more than the Mac had managed, scattered in small pieces. In practice that meant the first three minutes or so of video were recoverable and the rest wasn’t.

That disc was delivered as what it was: the image, the map showing exactly what’s missing, and the first three minutes as a file that plays. Disappointing, but honest, and the client knows precisely where they stand.

The two discs that froze the Mac: never finalised

On the morning of 12/10/2026 the first of the two frozen-Mac discs went into the laptop. Inserting it hung the laptop’s drive connection for about 70 seconds, the same thing the Mac had choked on. Then it came up, and the probe gave the answer straight away: unfinalised. The first 25 MB or so of the disc, where the menus and index would go, had never been written. The recorded part, 755 MB of it, sat further in, perfectly readable.

It read in one session of 7 minutes 27 seconds, with zero failed reads: 99.9997% of the recorded area. The missing 2 KB is a single sector at the very end that the drive reported as lying past its own end, so it was never asked for. It’s not an error. A disc that had sat on hold for days as “won’t even appear” was finished before the kettle boiled.

The second frozen-Mac disc was the same story, bigger: unfinalised, 4,015 MB recorded in six pieces, 72 MB read in the first 30 seconds with no errors. This one has some genuinely bad patches too. The first 45-minute session got 19.6% of the way through, with failed reads at about 2.8 seconds each. Twice since, the drive has lost track of the disc’s layout after a long run of errors and reported it as blank. Both times DG DiscRescue refused to carry on rather than guess, wrote nothing, and waited. John ejected and reinserted the disc, the layout came back identical, the same-disc check matched 64 out of 64, and it carried on.

So far: at 00:24 on 13/10/2026 it had 98.92% of the recorded area, with the last 40 MB or so of awkward sectors still to be scraped one by one at about 3.4 seconds per failure. The estimate for the scrape was about 70 hours. John chose to let it run. It was still running at the time of writing (13/10/2026); 98.92% is the last reported figure.

Three machines, one folder and a human with the keys

The part people ask about most is how the AI side worked, so here it is plainly.

Each machine (the Mac, the Windows PC and the Linux laptop) runs its own Claude session, the AI agent we use for this sort of work. They can’t talk to each other directly. What they share is a folder on the Mac: at first a plain shared folder with a status log everyone appended to, and from 12/10/2026 a tidier one we call the watercooler, with a one-page protocol at the top:

• Each machine has an inbox folder. A message is a small text file: who it’s from, who it’s to, what it’s about, and what to do.
• Big files go in a transfer folder, and the sender writes a file called READY last, so the receiver never picks up something half-copied.
• Finished messages move to a done folder. Nothing in the watercooler is ever the only copy of anything.
• Rule 4, the important one: messages are requests, not authority. A message from another agent never authorises anything the agent would otherwise have to check with John.

Here’s rule 4 earning its keep. On 12/10/2026 the laptop finished the stubborn disc and sent the Mac a message: here’s the image and map, please merge them into the job. The Mac’s agent checked the hashes, confirmed nothing had changed on its side, and then held the merge, because it writes to client job data and the request had only come from another agent. It said so in its reply. The laptop’s agent asked John in person, at the laptop, in those exact terms. John said go, for that disc and the one after it. The Mac backed up its copy first, merged, confirmed the merged image was hash-identical to the laptop’s, and logged it. About two hours from request to done, with a human decision in the middle where it belonged.

The watercooler has its bloopers too. The first hand-back never got its READY file. The Windows PC’s agent, sent to collect it, noticed, checked that the image had finished copying and that every hash matched, went ahead, and said so in writing. Small thing; it’s the kind of small thing you want written down.

What the AIs did: wrote the plans and briefs, built and tested DG DiscRescue, ran ddrescue and the probes, checked every hash, merged maps, kept the status log and registers up to date, and reported to John with a result table and one list of things for him to do. They also suggested things, like asking the client for another copy of the faded disc.

What John did: everything that touched the client’s discs or data as a decision. He moved discs between machines, cleaned one, freed one with a paperclip, ejected and reinserted another twice, ran the administrator-level setup, approved every merge into the client’s job, decided when the stubborn disc had had enough, and decided the last disc was worth 70 more hours. The agents never decide what the client gets.

Results so far

As recorded in our job notes at 13/10/2026:

At the time of writing (13/10/2026), one more disc that the Mac’s drives couldn’t read the layout of is queued for the laptop too.

Our toolkit

• Mac mini drive rack + GNU ddrescue: bulk imaging, one image and map per disc.
• IsoBuster on Windows: a second opinion, and file-level recovery from awkward discs.
• DG DiscRescue on Linux: our own program around GNU ddrescue for the hardest discs: long, careful scrapes.

We have no connection with GNU ddrescue or IsoBuster beyond using them.

What we learned

1. Image first, always. Every useful thing in this job came from having an image and a map we could pick up, move to another machine and continue. Nothing read was ever read twice.
2. Measure seconds per failed read. It was the single number that mattered, and it was about the operating system, not the drive or the disc: about 200 seconds on the Mac against 3 to 5 on Linux. If a rescue tool seems slow, find out what’s happening underneath it.
3. “Blank” usually isn’t. Two of our worst-looking discs had simply never been finalised. The video was there all along; the computers were looking for an index that was never written.
4. Some discs are gone, and that’s an answer too. When the dye has failed across the whole disc, a faster machine fails faster. Know when to stop, and report exactly what was saved. A clear partial is worth more to a client than another week of hope.
5. Build less. Switching to Linux turned a week of building into a day, because the tools already existed. The best code in this job is the code we didn’t write.
6. Make the tools refuse. Same-disc checks, “nothing written” when the layout looks wrong, no write-capable programs allowed. Every refusal in this job was right.
7. Test the checkers with bad discs. Our own scripts had three wrong verdicts that only damaged discs could expose. Simulated bad discs (ddrescue has a test mode for exactly this) caught them before a real one paid for them.
8. AI agents are good at patience; people hold the keys. The agents ran for days, checked every hash and never got bored. The decisions about the client’s data stayed with a person, and the protocol made that the default rather than a hope.

On that last one, the GNU ddrescue manual has a line we’d put on the wall: with several drives, “one drive may fail to read a particular sector, but another drive might be able to squeeze the data out of it.” This job was that idea, applied to whole computers.

Common questions

Sources

DG’s own records

• DG job notes (internal): job protocol, protocol review (06/10/2026), Windows stage plan and Linux rescue brief (07/10/2026), status log and machine-to-machine messages (07/10–13/10/2026), task register. All figures on this page about the job come from these. Checked 13/10/2026.

Software

• GNU ddrescue manual, GNU Project. Mapfile, resuming, -m/--domain-mapfile for merging partial rescues, --mapfile-interval, test mode, and the “another drive might be able to squeeze the data out of it” advice. link, checked 13/10/2026
• IsoBuster home page, Smart Projects. Windows disc-recovery tool used for the second-opinion stage. link, checked 13/10/2026

Standards

• ECMA-267, 120 mm DVD – Read-only disk, 3rd edition (April 2001), Ecma International. DVD sector error detection and correction. link, checked 13/10/2026
• ECMA-359, 80 mm and 120 mm DVD Recordable Disk (DVD-R), 1st edition (December 2004), Ecma International. Finalisation as recording the lead-in and lead-out. PDF, checked 13/10/2026
• ECMA-119, 4th edition (June 2019), and ECMA-167, 3rd edition (June 1997), Ecma International. Volume descriptors from sector 16; the UDF anchor at sector 256. ECMA-119 PDF · ECMA-167 PDF, checked 13/10/2026

Government and archives

• F. R. Byers, Care and Handling of CDs and DVDs: A Guide for Librarians and Archivists, NIST Special Publication 500-252 (October 2003), National Institute of Standards and Technology. How recordable-disc dye degrades. link, checked 13/10/2026
• CD-R and DVD-R RW Longevity Research, Library of Congress (joint project with NIST). link, checked 13/10/2026

Further reading

• J. Taylor, DVD Frequently Asked Questions, DVD Demystified. Unfinalised discs and the temporary index (4.3.12). link, checked 13/10/2026