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, for speed, 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, a few seconds on a Linux laptop. When we first wrote this on 13/10/2026, one disc was mid-way through a 70-hour scrape. It finished the next day, and on 15/10 a Blu-ray drive read its last bad patch, and a disc no other drive could start, in about a minute each. One disc is still being read; the results below are as of 20/10/2026.
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:
- 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.
- 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.
- 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.)
- 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.
- 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.)
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. (Update, 15/10/2026: DG DiscRescue can now ask for that last sector directly. It reads back as zeros, so the disc is 100% read.)
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.
At 00:24 on 13/10/2026, when we first wrote this, 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, and John chose to let it run.
How it finished: sooner than that. The scrape ended at 10:52 on 14/10/2026 at 99.61%, after 18 sessions and just under 34 hours of reading. What was left was 15.8 MB in one stretch, about 1.2 GB into the disc, where every retry failed at 6 to 7 seconds a go. The next morning that stretch read in about a minute in a different drive (the next section has the story). The disc is now 100% of the recorded area, with nothing bad, and its two recordings, about 97 and 122 minutes long, convert to video files with no decode errors.
Update: a Blu-ray drive and the last discs
We first wrote this on 13/10/2026 with three discs still open. This is what happened next, from our job notes up to 20/10/2026.
The disc no drive could start
The disc whose layout the Mac’s drives couldn’t read was a rewritable DVD (DVD+RW). In the early hours of 15/10/2026 it failed in the laptop too, even after cleaning: the drive turned down every read in a few hundredths of a second with “Unable to recover table-of-contents”. It never got as far as the surface.
Later that morning John fitted a different drive to the laptop, an LG BU40N Blu-ray writer. In that drive the layout came up straight away: a recorder disc holding 136 MB of video. It read in 52 seconds, 100%, without one failed read. A second read from scratch gave an identical SHA-256, so it went into the job as verified.
The new drive then took on the 15.8 MB stretch the first drive couldn’t read on frozen-Mac disc 2, and read all of it in about a minute. The stubborn disc got two minutes in it too, with no gain at all. Its dye has failed, and a better reader barely changes that. It stays at 3.60%.
The blank-looking disc: not blank, and not unfinalised
We’d guessed the blank-looking disc was another unfinalised one. It wasn’t. In the Blu-ray drive on 16/10/2026 the probe found a properly finalised DVD-R, 4.04 GB, the same make of disc as the stubborn one. Most of it reads. The very start doesn’t: sectors 0 to 383, where the file system lives, haven’t read in any drive so far. That’s why every computer took it for blank. It also means there’s no index to the recordings, so playable video has to be cut straight from the raw recording data. The longest unbroken piece plays for about 34 minutes.
IsoBuster had already read 32.45% of the disc on the Windows PC. The laptop’s read and IsoBuster’s overlap on 414,515 sectors, and every one of them matches: two programs, two drives, two operating systems, the same bytes. Each found sectors the other couldn’t. Combined, as a separate labelled merge that leaves both originals untouched, they covered 72.56% of the disc in the merge made on 18/10/2026.
The gains have since dried up. The laptop’s first full run stopped at 02:53 on 18/10/2026. John asked it to keep going, and since then it has found just 195 sectors (about 0.4 MB) that neither read had. From 20/10 it has worked only on the 1.11 GB that neither has, at about 8 seconds per failed read, and in almost 11 hours on that it found nothing. Getting through it at about 400 sectors an hour would take seven to eight weeks. The AI recommended stopping. John said keep going, and it was still running on the evening of 20/10/2026.
Results so far
From our job notes, updated to 20/10/2026. Of the 28 discs in the box, 23 are verified. Three were never finalised and everything recorded on them was read; they’re logged as partial only because the start of each disc, where a finalised disc keeps its index, was never written. The faded disc stopped at 3.6%, and the blank-looking disc is still being read.
| Disc | First machine | What was wrong | Where it ended up | Result |
|---|---|---|---|---|
| 21 discs | Mac rack | Nothing | Imaged and verified on the Mac rack, minutes per disc | Verified |
| The stubborn disc | Mac rack, then Linux laptop | Recording dye failing right across the disc | 3.60% after four days and 190 sessions; first ~3 minutes of video playable. Two minutes in a different drive on 15/10 added nothing | Partial, delivered |
| Frozen-Mac disc 1 | Mac (never appeared), then Linux laptop | Never finalised | 100% of the recorded area: 7 min 27 s with no failed reads, plus the last sector on 15/10 | Partial in name only: everything recorded was read |
| Frozen-Mac disc 2 | Mac (never appeared), then Linux laptop | Never finalised, plus some bad patches | 99.61% after 34 hours of reading; the last 15.8 MB read in about a minute in a Blu-ray drive on 15/10, giving 100% of the recorded area | Partial in name only: everything recorded was read |
| The blank-looking disc | Mac rack, then Windows, then Linux laptop | Finalised after all; the start of the disc, where the file system lives, hasn’t read in any drive | 72.56% combining the laptop’s read with IsoBuster’s (18/10 merge), plus 195 sectors since; every sector both read matches | In progress: still being read on 20/10/2026 |
| The disc with no readable layout | Mac rack, then Linux laptop | The Mac’s drives and the laptop’s first drive couldn’t read its table of contents | Read in full in 52 s in a Blu-ray drive; a second read from scratch was identical | Verified |
| Two more: a CD-R and another unfinalised DVD | Mac rack, second read on the Linux laptop | CD-R: two unreadable sectors after the data, left by the way it was written, which no file uses. DVD: never finalised | Both read in full; the laptop’s second reads matched | Verified (CD-R); partial in name only (DVD) |
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.
- A different drive model: an LG BU40N Blu-ray writer in the laptop, which read a whole disc and a stubborn stretch of another that the other drives couldn’t.
We have no connection with GNU ddrescue, IsoBuster or LG beyond using them.
What we learned
- 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 had to be read twice, apart from deliberate second reads to check the first.
- Measure seconds per failed read. For speed it was the number that mattered most, and it was about the operating system, not the drive or the disc: about 200 seconds on the Mac against a few seconds on Linux. If a rescue tool seems slow, find out what’s happening underneath it.
- Try a different drive model before giving up. The Mac’s drives and the laptop’s first drive couldn’t even read one disc’s layout; a Blu-ray drive read the whole disc in 52 seconds. The same drive read, in about a minute, the 15.8 MB the first drive still hadn’t got from another disc after 34 hours. It did next to nothing for the faded disc, though: a better reader can’t bring back dye that has failed.
- “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. The third, the blank-looking one, wasn’t unfinalised after all, but it wasn’t blank either: about 72% of it has been read. Its start and about a quarter of the rest still haven’t.
- 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.
- 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.
- 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.
- 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.
- 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.
Got a box of discs like this?
Reading scratched, ageing and unfinalised discs is part of our media transfer service in Sydney, done the way this page describes: image first, nothing re-read once it’s safe, different machines for the difficult ones, and a straight answer about anything that couldn’t be saved. You get your files back, a record of what was and wasn’t recovered, and your discs. If you know a disc was never finalised, or it’s cracked or peeling, tell us when you get in touch.
Common questions
How long does it take to recover data from a damaged DVD?
Why did a Linux laptop do better than a Mac?
Can every DVD be saved?
Did the AI recover the data?
Did the AI agents look at the client’s files?
What do you get back from a partial rescue?
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 (07/10–20/10/2026), task register. All figures on this page about the job come from these. Checked 13/10/2026 and 21/10/2026.
Software
- GNU ddrescue manual, GNU Project. Mapfile, resuming,
-m/--domain-mapfilefor 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