[mythtv-users] OT DVD ripping software

Tue Oct 28 01:49:49 UTC 2014

On Mon, 27 Oct 2014 16:31:31 +0000, you wrote:

>Stephen Worthington <stephen_agent at jsw.gen.nz> wrote:
>
>>> But DVDs have a normal file system - I always thought that there is no
>>> problem concerning the reading quality. The OS and the DVD drive have
>>> to handle reading errors. And if the disc isn't readable an error will be
>>> reported.
>> 
>> If you are using the filesystem then yes, errors will be reported.  dd
>> does not use the filesystem.  It reads sectors directly.
>> 
>>> But dd isn't a good tool for creating disc images???
>> 
>> No.  Unless you check the logs after using dd, you may never know that
>> a sector had a read error and the data it copied for that sector is
>> bad.  Until you play the bit of the disk image with the error.  So use
>> readom which does report errors and is designed for the job of ripping
>> optical disks.
>
>If there is an uncorrected error it is passed up the stack as a read error *on the block device* and that would get passed up to the filesystem and ultimately to the application layer. While dd doesn't use the filesystem, it will still receive errors and will abort if any are reported.
>Error detection (& correction) is *NOT* a filesystem function, it is a device & device driver function.

dd does not stop on block errors, or retry errored blocks.  I have a
number of bad DVD-R disks, so I just tried dd on one.  This is the
result:

root at mypvr:/mnt/vid3/video/r/optical disk recovery# dd if=/dev/cdrom
of=VD00218.iso
dd: error reading â/dev/cdromâ: Input/output error
8917400+0 records in
8917400+0 records out
4565708800 bytes (4.6 GB) copied, 337.086 s, 13.5 MB/s
root at mypvr:/mnt/vid3/video/r/optical disk recovery# ls -al VD00218.iso
-rw-r--r-- 1 root root 4565708800 Oct 28 14:01 VD00218.iso

As you can see, dd copied the DVD to an image file, despite errors. It
took around the same time as copying a disk without any errors.  It
did give the one final error message, which is easy to miss - I did
this time until I looked hard.  I actually did not see the error until
I had copied the text and pasted it into this email.  But in
/var/log/kern.log, you can see what really happened:

Oct 28 13:53:32 mypvr kernel: [250933.434999] UDF-fs: warning (device
sr0): udf_load_vrs: No VRS found
Oct 28 13:53:32 mypvr kernel: [250933.435003] UDF-fs: warning (device
sr0): udf_fill_super: No partition found (2)
Oct 28 13:53:32 mypvr kernel: [250933.505194] ISO 9660 Extensions:
Microsoft Joliet Level 3
Oct 28 13:53:32 mypvr kernel: [250933.506587] ISOFS: changing to
secondary root
Oct 28 14:01:01 mypvr kernel: [251381.845699] sr 4:0:0:0: [sr0]
Unhandled sense code
Oct 28 14:01:01 mypvr kernel: [251381.845708] sr 4:0:0:0: [sr0]
Oct 28 14:01:01 mypvr kernel: [251381.845712] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
Oct 28 14:01:01 mypvr kernel: [251381.845716] sr 4:0:0:0: [sr0]
Oct 28 14:01:01 mypvr kernel: [251381.845718] Sense Key : Medium Error
[current]
Oct 28 14:01:01 mypvr kernel: [251381.845725] sr 4:0:0:0: [sr0]
Oct 28 14:01:01 mypvr kernel: [251381.845728] Add. Sense: L-EC
uncorrectable error
Oct 28 14:01:01 mypvr kernel: [251381.845732] sr 4:0:0:0: [sr0] CDB:
Oct 28 14:01:01 mypvr kernel: [251381.845735] Read(10): 28 00 00 22 04
38 00 00 40 00
Oct 28 14:01:01 mypvr kernel: [251381.845749] end_request: I/O error,
dev sr0, sector 8917216
Oct 28 14:01:01 mypvr kernel: [251381.845755] Buffer I/O error on
device sr0, logical block 2229304
Oct 28 14:01:01 mypvr kernel: [251381.845761] Buffer I/O error on
device sr0, logical block 2229305
Oct 28 14:01:01 mypvr kernel: [251381.845773] Buffer I/O error on
device sr0, logical block 2229306
Oct 28 14:01:01 mypvr kernel: [251381.845781] Buffer I/O error on
device sr0, logical block 2229307
Oct 28 14:01:01 mypvr kernel: [251381.845785] Buffer I/O error on
device sr0, logical block 2229308
Oct 28 14:01:01 mypvr kernel: [251381.845790] Buffer I/O error on
device sr0, logical block 2229309
Oct 28 14:01:01 mypvr kernel: [251381.845795] Buffer I/O error on
device sr0, logical block 2229310
Oct 28 14:01:01 mypvr kernel: [251381.845800] Buffer I/O error on
device sr0, logical block 2229311
Oct 28 14:01:01 mypvr kernel: [251381.845805] Buffer I/O error on
device sr0, logical block 2229312
Oct 28 14:01:01 mypvr kernel: [251381.845810] Buffer I/O error on
device sr0, logical block 2229313
Oct 28 14:01:08 mypvr kernel: [251389.107684] sr 4:0:0:0: [sr0]
Unhandled sense code
Oct 28 14:01:08 mypvr kernel: [251389.107693] sr 4:0:0:0: [sr0]
Oct 28 14:01:08 mypvr kernel: [251389.107697] Result: hostbyte=DID_OK
driverbyte=DRIVER_SENSE
Oct 28 14:01:08 mypvr kernel: [251389.107702] sr 4:0:0:0: [sr0]
Oct 28 14:01:08 mypvr kernel: [251389.107704] Sense Key : Medium Error
[current]
Oct 28 14:01:08 mypvr kernel: [251389.107710] sr 4:0:0:0: [sr0]
Oct 28 14:01:08 mypvr kernel: [251389.107714] Add. Sense: L-EC
uncorrectable error
Oct 28 14:01:08 mypvr kernel: [251389.107718] sr 4:0:0:0: [sr0] CDB:
Oct 28 14:01:08 mypvr kernel: [251389.107721] Read(10): 28 00 00 22 04
67 00 00 01 00
Oct 28 14:01:08 mypvr kernel: [251389.107735] end_request: I/O error,
dev sr0, sector 8917404
Oct 28 14:01:08 mypvr kernel: [251389.107741] quiet_error: 54
callbacks suppressed
Oct 28 14:01:08 mypvr kernel: [251389.107745] Buffer I/O error on
device sr0, logical block 2229351

So the VD00219.iso file has errors in it, and if you missed that one
little error message (as I did), you would never know.

This is what readom did on the same disk:

root at mypvr:/mnt/vid3/video/r/optical disk recovery# readom
dev=/dev/cdrom f=VD00218.iso
Read  speed: 22160 kB/s (CD 125x, DVD 16x).
Write speed:  5540 kB/s (CD  31x, DVD  4x).
Capacity: 2298496 Blocks = 4596992 kBytes = 4489 MBytes = 4707 prMB
Sectorsize: 2048 Bytes
Copy from SCSI (4,0,0) disk to file 'VD00218.iso'
end:   2298496
Errno: 5 (Input/output error), read_g1 scsi sendcmd: no error
CDB:  28 00 00 21 DA 80 00 00 40 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 03 00 00 00 00 0A 00 00 00 00 11 05 00 00
Sense Key: 0x3 Medium Error, Segment 0
Sense Code: 0x11 Qual 0x05 (l-ec uncorrectable error) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 6.938s timeout 40s
readom: Input/output error. Cannot read source disk
readom: Retrying from sector 2218624.
Errno: 5 (Input/output error), read_g1 scsi sendcmd: no error...addr:
2218688 cnt: 64
CDB:  28 00 00 21 E4 40 00 00 40 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 03 00 00 00 00 0A 00 00 00 00 11 05 00 00
Sense Key: 0x3 Medium Error, Segment 0
Sense Code: 0x11 Qual 0x05 (l-ec uncorrectable error) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 6.984s timeout 40s
readom: Input/output error. Cannot read source disk
readom: Retrying from sector 2221120.
..................~~-~~~+~~~-~~~+~~~-~~~+~~~-~~^Croot at mypvr:/mnt/vid3/video/r/optical
disk recovery#

I killed readom as I know that the entire end of that disk is
unreadable and readom would take literally weeks trying to recover
some sectors from it.  I know, from having tried to recover the data
on the end of that disk with Gnu ddrescue, that it in fact has many,
many more errored sectors than using dd caused to show up in kern.log.
I was very surprised to see only those few messages, and as a result
of that, I would not be surprised if using dd on a less damaged disk
resulted in a copy where dd did not report any errors at all, despite
the errors being there.

So, unfortunately, any optical disk images you have made using dd may
contain errors, and you will not know until you actually use the
damaged data.

There are many reasons why dd is a dangerous command (it has many
nicknames, like dd=deadly dangerous), and this is just one of them.

If you do have damaged optical data disks, then you can try using
ddrescue to read them:

http://www.gnu.org/software/ddrescue/ddrescue.html

Note that there are two "ddrescue" programs, the good one is the Gnu
version, ddrescue.  The not so good one is dd_rescue.

But my experience with recovering damaged optical media is that it is
pretty rare to be able to recover much from the end of the disk once
they start degrading.