copy undamaged part of damaged CD/DVD to a file

[Winston]

A DVD+R disc I recorded (i.e., not copy protected) many years ago
appears to have developed an uncorrectable error in one of its low
numbered blocks. As a result, it gets "unreadable" or "bad format" on
all the DVD drives and stand-along DVD (or blu-ray) players I've tried
it on.

When I put the disk in a DVD drive on a system running FreeBSD, and on
which automount is never enabled or run, some presumably low-level part
of the system tries to read the first few blocks of the disc and
fails with:

[the exact CDB numbers change a little from error to error]

(cd0:ahcich3:0:0:0): READ(10). CDB: 28 00 00 00 00 00 00 00 01 00
(cd0:ahcich3:0:0:0): CAM status: SCSI Status Error
(cd0:ahcich3:0:0:0): SCSI status: Check Condition
(cd0:ahcich3:0:0:0): SCSI sense: MEDIUM ERROR asc:11,5 (L-EC uncorrectable error)
(cd0:ahcich3:0:0:0): Error 5, Unretryable error
(cd0:ahcich3:0:0:0): cddone: got error 0x5 back

and, despite what the error message says, it retries and retries and
retries to the point that it almost ignores the Eject button.

My goal is to copy all the readable blocks to a file, in the hope of
recovering as many of the video recordings on it as possible.

Is there a way to stop (or prevent) that tray-just-closed
read-fail-retry loop and leave things in a state where I can run
"dd -noerror"?

TIA!
-WBE

[Bob Eager]

Two things to try:

- ddrescue (ports: sysutils/ddrescue). This will copy what it can and
you can ask it to keep trying.
- dvdisaster (ports: sysutils/dvdisaster). Graphical interface. Really
for generating recovery data but has a simple copy-all-it-can mode.





--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

[Winston]

Bob Eager <news...@eager.cx> kindly replied:

> Two things to try:
>
> - ddrescue (ports: sysutils/ddrescue). This will copy what it can and
> you can ask it to keep trying.
> - dvdisaster (ports: sysutils/dvdisaster). Graphical interface. Really
> for generating recovery data but has a simple copy-all-it-can mode.

OK, those are good to know about and sound better than "dd -noerror".
Thanks!

After reading the descriptions for them, though, I didn't see anything
regarding halting or preventing the read-fail-keep-retrying problem I
saw:

>> Is there a way to stop (or prevent) that tray-just-closed
>> read-fail-retry loop and leave things in a state where I can run
>> "dd -noerror"?

Is there some kernel setting or command to say "don't do that" (don't
keep trying to read the DVD when the tray closes)?

TIA, again!
-WBE

[Bob Eager]

On Sat, 07 Nov 2020 21:16:56 -0500, Winston wrote:

> Bob Eager <news...@eager.cx> kindly replied:
>> Two things to try:
>>
>> - ddrescue (ports: sysutils/ddrescue). This will copy what it can and
>> you can ask it to keep trying.
>> - dvdisaster (ports: sysutils/dvdisaster). Graphical interface. Really
>> for generating recovery data but has a simple copy-all-it-can mode.
>
> OK, those are good to know about and sound better than "dd -noerror".
> Thanks!
>
> After reading the descriptions for them, though, I didn't see anything
> regarding halting or preventing the read-fail-keep-retrying problem I
> saw:

Let's just say that I don't observe that in practice, certainly with
dvdisaster. (I am the port maintainer). I can't remember what happens
with ddrescue.

I was testing dvdisaster, and took a Swiss Army knife to a CD-R after I'd
written it. Carved lots of deep grooves in it. dvdisaster read as much as
it could, fairly quickly. Since I'd added recovery infortmation in that
case, I got all of the data back, which you wouldn't of course.

Anyway, just try them and see.

[Winston]

Bob Eager <news...@eager.cx> kindly replied:
>>> Two things to try:

>>> - ddrescue (ports: sysutils/ddrescue). This will copy what it can and
>>> you can ask it to keep trying.
>>> - dvdisaster (ports: sysutils/dvdisaster). Graphical interface. Really
>>> for generating recovery data but has a simple copy-all-it-can mode.

I replied:

>> OK, those are good to know about and sound better than "dd -noerror".
>> Thanks!

>> After reading the descriptions for them, though, I didn't see anything
>> regarding halting or preventing the read-fail-keep-retrying problem I
>> saw:

Bob Eager <news...@eager.cx> writes:
> Let's just say that I don't observe that in practice, certainly with
> dvdisaster. (I am the port maintainer).

Wow, then especially thanks for replying!

> I can't remember what happens with ddrescue.

> I was testing dvdisaster, and took a Swiss Army knife to a CD-R after I'd
> written it. Carved lots of deep grooves in it. dvdisaster read as much as
> it could, fairly quickly. Since I'd added recovery infortmation in that
> case, I got all of the data back, which you wouldn't of course.

> Anyway, just try them and see.

OK, then I have a really basic operational question:

Do you start dvdisaster first, issue the rescue command so that it takes
control of the drive, THEN close the tray, so that that's how it avoids
the read-fail-retry problem?

OR, when you close the tray with your knifed CD-R in it BEFORE starting
dvdisaster, does the system eventually stop trying to read the bad
sector on its own, or will starting up dvdisaster stop that
read-fail-retry loop?

If the grooves you carved were all in the outer/data tracks, then maybe
your test CD-R didn't test the issue I'm having? If you've gotten it to
work even when there's a defect in the innermost tracks, maybe the
read-fail-retry issue is some sort of configuration issue here on my
system I'll have to find and change.

[I've looked very carefully at my DVD under a bright light, and I see no
obvious scratches, lint, fingerprints, etc., in the region, so it looks
like it's just bit errors.]

Thanks again!
-WBE

[Winston]

New info:

I decided to try letting the read-fail-retry loop run to see if maybe it
would eventually stop on its own. IT DID (yay!), but it took more than
4 1/2 minutes and issued lots of MEDIUM ERROR (L-EC uncorrectable error)
complaints before doing so.

Now that that's stopped, I've been able to try recovery. It looks like
a lot more of the low-numbered sectors than I'd guessed have errors, but
once it got past those, some 96.4% has been recovered so far. :)

Thanks Bob!
-WBE

[Bob Eager]

Glad to hear it. You are right...the low numbered tracks were OK. I had a
lot of old CDs that had an error in the same place, a few 'tracks' in -
result of a buggy bit of writing software I used for a while. Managed to
read them, then see which files had the standard replacement pattern that
dvdisaster put in those sectors.

What did you use? dvdisaster or ddrescue?

[Winston]

Bob Eager <news...@eager.cx> writes:
> What did you use? dvdisaster or ddrescue?

Since you'd said you were the port maintainer for dvdisaster, I looked at
that first, but pkg said installing dvdisaster would also require
installing gcc9 (I have no idea why a pre-compiled executable would
require installing a compiler), binutils, and mpc, which came to almost
400M, so I checked ddrescue. It's only 134k and had no other
dependencies, so I went with that.

* ddrescue question:

The last portion of my DVD+R is blank because there wasn't enough
space left for another recording. Visually, the disc has an outer
ring of 2mm of blank recording surface.

When ddrescue got to about 142MB "non-tried", it instantly changed
from reading successfully at full speed to getting read errors on
every sector.

Does that mean it's read all the useful data and it's now reading the
blank sectors at the end, or could "non-tried" sectors be interspersed
throughout the recovered data? Should I expect to see MEDIUM ERRORs
when something tries to read never-written sectors on a CD-R or DVD+R?

I didn't run "ddrescue -n" first. I ran
"ddrescue -b2048 -d /dev/cd0 /tmp/rn1 /tmp/rn1.mapfile"
I saw passes 1 and 2 happen but not 3 or 4 (they were either really
brief or were skipped), and it's now in pass 5.

I've halted it for the moment. At the current rate, it looks like
it'd take another 90 minutes for pass 5 to finish. It's getting a
100% read error rate on over 1000 consecutive reads.

The DVD+R label says 120 min and 4.7GB.
ddrescue created an output file that is 4,422,959,104 long.

* Good news: when I inserted the disc, closed the tray, saw the read
errors start, and immediately started up ddrescue -d, it successfully
took over the drive and resumed running almost immediately, without
waiting for whatever it is that normally spends 4 1/2 minutes trying to
read the disc.

* It'd be nicer if there weren't 6 lines worth of error messages written
to the system log file for every one of these hundreds of read errors,
though ... :-/

* And despite using -d, I can't tell if the /dev/cd0 reads are using the
system cache or not. Even after I kill ddrescue and see the command
line prompt, something keeps reading the drive and logging read errors
for another 15 seconds or so.
-WBE

[Bob Eager]

On Sun, 08 Nov 2020 23:48:31 -0500, Winston wrote:

> Bob Eager <news...@eager.cx> writes:
>> What did you use? dvdisaster or ddrescue?
>
> Since you'd said you were the port maintainer for dvdisaster, I looked
> at that first, but pkg said installing dvdisaster would also require
> installing gcc9 (I have no idea why a pre-compiled executable would
> require installing a compiler), binutils, and mpc, which came to almost
> 400M, so I checked ddrescue. It's only 134k and had no other
> dependencies, so I went with that.

That would be my fault, although I'll have to look into gcc as a build
time dependency as it isn't quite specified in the normal way.

> * ddrescue question:
>
> The last portion of my DVD+R is blank because there wasn't enough
> space left for another recording. Visually, the disc has an outer
> ring of 2mm of blank recording surface.
>
> When ddrescue got to about 142MB "non-tried", it instantly changed
> from reading successfully at full speed to getting read errors on
> every sector.
>
> Does that mean it's read all the useful data and it's now reading the
> blank sectors at the end, or could "non-tried" sectors be
> interspersed throughout the recovered data? Should I expect to see
> MEDIUM ERRORs when something tries to read never-written sectors on a
> CD-R or DVD+R?

I suspect it's playing safe, because it doesn't know if it's the 'real'
end or just a bad patch.

I'd just leave it be, not that I have much experience with it.

> * It'd be nicer if there weren't 6 lines worth of error messages written
> to the system log file for every one of these hundreds of read errors,
> though ... :-/

That's the driver, not the program! I get fed up with that too.

[Bob Eager]

On Mon, 09 Nov 2020 14:40:19 +0000, Bob Eager wrote:

> On Sun, 08 Nov 2020 23:48:31 -0500, Winston wrote:
>
>> Bob Eager <news...@eager.cx> writes:
>>> What did you use? dvdisaster or ddrescue?
>>
>> Since you'd said you were the port maintainer for dvdisaster, I looked
>> at that first, but pkg said installing dvdisaster would also require
>> installing gcc9 (I have no idea why a pre-compiled executable would
>> require installing a compiler), binutils, and mpc, which came to almost
>> 400M, so I checked ddrescue. It's only 134k and had no other
>> dependencies, so I went with that.
>
> That would be my fault, although I'll have to look into gcc as a build
> time dependency as it isn't quite specified in the normal way.

OK, I see why now.

I'm using gcc because that's what the dvdisaster author said. Given that
this is all about data integrity, I didn't want to risk using clang and
subtly breaking something that might not be noticed until someone tried
to recover data.

gcc is a run time dependency because it carries run time stuff with it
that may be used. The other things are there because gcc makes them a
dependency.

dvdisaster does a lot more than read bad discs, though. Its primnary
purpose is to take a CD or DVD (no more than about 80% full) and
calculate recovery data that it sticks in all the spare space - the more
the better. If you get errors, you can read the disc back into an image
file (as you did with ddrescue). Then you can tell it to use the recovery
data to recover the lost data. And it works.

[Winston]

Bob Eager <news...@eager.cx> asked:

>>>> What did you use? dvdisaster or ddrescue?

I replied:

>>> Since you'd said you were the port maintainer for dvdisaster, I looked
>>> at that first, but pkg said installing dvdisaster would also require
>>> installing gcc9 (I have no idea why a pre-compiled executable would
>>> require installing a compiler), binutils, and mpc, which came to almost
>>> 400M, so I checked ddrescue. It's only 134k and had no other
>>> dependencies, so I went with that.

Bob initially replied:

>> That would be my fault, although I'll have to look into gcc as a build
>> time dependency as it isn't quite specified in the normal way.

but after looking into why added:

> OK, I see why now.

> I'm using gcc because that's what the dvdisaster author said. Given that
> this is all about data integrity, I didn't want to risk using clang and
> subtly breaking something that might not be noticed until someone tried
> to recover data.

This just sounds like there needs to be a way to ensure the executable
is compiled with gcc instead of clang.

> gcc is a run time dependency because it carries run time stuff with it
> that may be used. The other things are there because gcc makes them a
> dependency.

The binutils and mpc parts made sense. It might be nice if gcc's C
.so startup library code (Foo: I'm forgetting the name of that) and libc
could be copied out as a package separate from the rest of the compiler,
but no matter ...

> dvdisaster does a lot more than read bad discs, though. Its primnary
> purpose is to take a CD or DVD (no more than about 80% full) and
> calculate recovery data that it sticks in all the spare space - the more
> the better. If you get errors, you can read the disc back into an image
> file (as you did with ddrescue). Then you can tell it to use the recovery
> data to recover the lost data. And it works.

That's great as long as one does it before the disc goes bad. :)

I skipped "scraping" because it looked like that would take a week or
so. ddrescue said it recovered about 97%, with about 2.8MB of bad data
in several hundred bad areas. Unfortunately, many of them were low
numbered sectors, and I was unable to mount the image. That leads me to
my next thread...
-WBE