• copy undamaged part of damaged CD/DVD to a file

    From Winston@21:1/5 to All on Sat Nov 7 17:18:03 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Eager@21:1/5 to Winston on Sat Nov 7 22:45:59 2020
    On Sat, 07 Nov 2020 17:18:03 -0500, Winston wrote:

    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"?

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Winston@21:1/5 to kindly on Sat Nov 7 21:16:56 2020
    Bob Eager <news0073@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Eager@21:1/5 to Winston on Sun Nov 8 09:50:45 2020
    On Sat, 07 Nov 2020 21:16:56 -0500, Winston wrote:

    Bob Eager <news0073@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.



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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Winston@21:1/5 to kindly on Sun Nov 8 09:36:14 2020
    Bob Eager <news0073@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 <news0073@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Winston@21:1/5 to All on Sun Nov 8 12:17:32 2020
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Eager@21:1/5 to Winston on Sun Nov 8 21:22:04 2020
    On Sun, 08 Nov 2020 12:17:32 -0500, Winston wrote:

    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. :)

    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?



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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Winston@21:1/5 to Bob Eager on Sun Nov 8 23:48:31 2020
    Bob Eager <news0073@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Eager@21:1/5 to Winston on Mon Nov 9 14:40:19 2020
    On Sun, 08 Nov 2020 23:48:31 -0500, Winston wrote:

    Bob Eager <news0073@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.

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bob Eager@21:1/5 to Bob Eager on Mon Nov 9 21:49:41 2020
    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 <news0073@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.



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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Winston@21:1/5 to Bob Eager on Mon Nov 9 21:12:43 2020
    Bob Eager <news0073@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)