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
-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
Tool to compare
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
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-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
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
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.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.