1

I'm having a very strange behavior reading data files from a CD: The data is inconsistent if I do several copies of the same file from the CD. I don't know the reason (there're no read errors notifications, and other CDs work fine on the same unit).

Errors happen at different places each time, so my guess is that these errors could be repaired if I do several copies of the file, and take each byte with the value that most copies agree with.

I tried to use ddrescue, but it detects no errors (it gets wrong data, but detects no errors). However, if ddrescue checked the data it reads, then it would obviously find inconsistencies.

So, can I use ddrescue (or other tool) for repairing the files from this CD by verifying the copied data and repeat the copy as many times as needed for guessing what's the correct value for each byte?

Thanks!

1
  • As you mentioned, there are no read errors, but what about write errors? I might be wrong, but I believe ddrescue only tells about read errors. What if your output media has bad sectors? Prior to cloning, have you done sector by sector check that our destination drive had no bad sectors? As Tino mentioned, check your hardware, especially cables and there connectors. For SATA cables, preferably use those with a clip.
    – OuzoPower
    May 19 at 11:16

1 Answer 1

Reset to default
1

Check your hardware

I do not have a good solution, but usually, if data is read differently every time from a CD-ROM, it sounds more to a hardware issue to me than actually a issue on the defective CD, as CDs involve ECC, which means, either the sector can be read or not, and if it can be read, it will show stable data.

Also perhaps use the ddrescue option -d to access the source, because some operating systems might hand out random data after a read-error occurred on the readahead (which is done in the background).

Try to us a different computer not sharing any hardware of the other computer and see, if you still get this puzzling result.

But note: Doing 2 runs of ddrescue can happen to create two different images, because if there are read errors, perhaps different parts of the source were recovered. (You write, there are no errors. Perhaps things are different with option -d.)

Tool to compare ddrescue images

If you can exclude faulty hardware and want to compare the image with the source again without pulling another image, you perhaps can try my tool ddrescue-verify to diagnose the differences.

ddrescue-verify is source only (and probably Linux only), so you need to know how to use a development/compile system

Today, ddrescue-verify is not designed to be an easy to use diagnostics tool. It was created to be able to quickly verify, if the image was taken correctly over a slow network link, so in a situation where you definitively cannot await the full image being transferred over the slow line more than once.

If the existing documentation for ddrescue and ddrescue-verify is not enough for you, I am afraid I cannot help you further (no time, sorry). The only thing I can offer is an excerpt from the Wiki hopefully adapted a bit to your needs:

The original command to create the image from the source was something like following, run in the current working directory:

ddrescue -d /dev/source image.img image.log

Now create the verification data:

ddrescue-verify image.img image.log > image.verify

Now run the verification/compare process:

ddrescue-verify -udis0 /dev/source image.verify > image.diff

This is fast, as ddrescue-verify tries skips over the source parts, which are marked unreadable in the image.log (hence option -d).

The output will tell you differences.

You can also look into image.diff to see the differences. This file has the same format as the ddrescue log file with the differences marked as "unread", so you can analyse it with ddrescuelog.

possibly: Pull differences into the image

To pull in the differences, you also can do following:

# The next 2 commands take a snapshot of your original image
# Probably use lvm or ZFS snapshot to not duplicate all data:
cp image.img image.orig.img
cp image.log image.orig.log
# Now pull in the differences
cp -f image.diff image.log
ddrescue /dev/source image.img image.log

Now you have updated the image.img and image.log to the changes found. This is fast, as this only tries to read only the changed parts (difference is detected on each 1MB default, so it will copy a bit more).

Note: This last step is designed such, that you can repeat this whole process as often as you need.

This is not a complete solution

I'm sorry that I cannot present you with a full solution. But recovering data by guessing in an unclear situation is nothing, which can be done out of the box.

However using snapshots (I recommend ZFS or BTRFS, as those are much faster than LVM) in combination with a way to compare and pull differences, you perhaps can figure out what's correct and what not.

1
  • +1 for the hardware check, this is why distros came with memory testing tools, and even today why we check hash digest values. There are tools, such as dvdisaster that rely upon before the fact error correction data and others that rely upon you having multiple copies of the CD.
    – mckenzm
    Nov 13, 2021 at 6:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .