But it's just a little scratch
July 31, 2007 4:11 PM Subscribe
On my Linux-based laptop and desktop, I've been having trouble reading DVDs that have even the slightest scratches. It seemed that Windows was a bit more tolerant of imperfections--is there any way to modify my [Ubuntu] settings so that it doesn't hang at the first missed bit?
Now that half the country has Netflix and their DVDs are spending a lot of time in transit, every disk seems to come with at least one small abrasion. In an effort to smooth the playback (via Totem, VLC, MPlayer, whatever), I have taken to copying and/or transcoding the disk to my harddrive first (dvdrip, handbrake, vobcopy, and DVD Decrypter through wine), but each program hangs at the first unreadable sector. Is there any DVD equivalent to something like Exact Audio Copier to conduct error checking/correction to reclaim these bits? Alternately, are there any settings that I can modify to make my system tolerate a small gap in the data stream?
Now that half the country has Netflix and their DVDs are spending a lot of time in transit, every disk seems to come with at least one small abrasion. In an effort to smooth the playback (via Totem, VLC, MPlayer, whatever), I have taken to copying and/or transcoding the disk to my harddrive first (dvdrip, handbrake, vobcopy, and DVD Decrypter through wine), but each program hangs at the first unreadable sector. Is there any DVD equivalent to something like Exact Audio Copier to conduct error checking/correction to reclaim these bits? Alternately, are there any settings that I can modify to make my system tolerate a small gap in the data stream?
Check your drive's DMA setting (as root):
# hdparm /dev/dvd
Most likely you'll want using_dma set to 1, but you can try turning it off if it's own now and you're getting read errors you weren't getting in Windows.
Turn on DMA with
# hdparm -d1 /dev/dvd
If DMA doesn't come on, the issue may be with the device's Linux driver. Run "lspci" (as root) to see what your hardware looks like to the kernel, and check your IDE interface. Then check the Ubuntu forums to see if there's any information about support for your IDE device in a newer kernel.
posted by Loudmax at 8:09 AM on August 1, 2007
# hdparm /dev/dvd
Most likely you'll want using_dma set to 1, but you can try turning it off if it's own now and you're getting read errors you weren't getting in Windows.
Turn on DMA with
# hdparm -d1 /dev/dvd
If DMA doesn't come on, the issue may be with the device's Linux driver. Run "lspci" (as root) to see what your hardware looks like to the kernel, and check your IDE interface. Then check the Ubuntu forums to see if there's any information about support for your IDE device in a newer kernel.
posted by Loudmax at 8:09 AM on August 1, 2007
Response by poster: Thanks flabdablet, it seems like this will work well for me, though I'm having trouble gaining raw access to the drive (any tips on that, please let me know!). gddrescuse has read more of the disks than any other method so far...
posted by zachxman at 8:33 AM on August 1, 2007
posted by zachxman at 8:33 AM on August 1, 2007
Best answer: Gah. Sorry; distro confusion. All that raw stuff works jut like I said when I'm using the Trinity Rescue Kit, a live CD that runs as root; it's a little fiddlier from a user account in Ubuntu.
First, you have to load a module into your running kernel:
If that works, /dev/rawctl should spring into existence; then, you have to make a few more entries in /dev by hand:
(add more mknod commands if you want more raw devices)
Once that's all done, you can bind a raw device to any of your block devices like so:
You can see what raw device bindings exist, using
You can disconnect a given raw device from whatever it's bound to with
And if you want, you can free up a little kernel memory when you're all done, with
From a ddrescue point of view, the most important difference between a raw device and the block device it's bound to are that
posted by flabdablet at 5:21 AM on August 2, 2007
First, you have to load a module into your running kernel:
sudo modprobe raw
If that works, /dev/rawctl should spring into existence; then, you have to make a few more entries in /dev by hand:
sudo mkdir /dev/raw
sudo mknod /dev/raw/raw1 c 162 1
sudo mknod /dev/raw/raw2 c 162 2
sudo mknod /dev/raw/raw3 c 162 3
(add more mknod commands if you want more raw devices)
Once that's all done, you can bind a raw device to any of your block devices like so:
sudo raw /dev/raw/raw1 /dev/dvd
You can see what raw device bindings exist, using
sudo raw -qa
You can disconnect a given raw device from whatever it's bound to with
sudo raw /dev/raw/raw1 0 0
And if you want, you can free up a little kernel memory when you're all done, with
sudo rmmod raw
From a ddrescue point of view, the most important difference between a raw device and the block device it's bound to are that
- Reads and writes to the raw device do not touch the buffer cache associated with the block device. If you use ddrescue to write to a raw device, and then perform reads on the block device it's bound to, you might get out-of-date cached data instead of what you wrote. This is either a bug or a feature, depending what you're trying to accomplish.
- The raw device won't report a size, so ddrescue has to be given the size explicitly with the --max-size= option (or work it out from a pre-existing logfile using --complete-only - not supported in early versions).
- Raw device reads of non-error blocks are slower than block device reads, because they never benefit from caching or read-ahead. That, and the size thing, are what makes it worthwhile to do a non-raw pass first.
posted by flabdablet at 5:21 AM on August 2, 2007
Response by poster: Thanks Loudmax, but changing the dma settings didn't seem to affect anything. Actually, with these two disks, nothing seems to work, so I'm sending them back in hopes of more pristine media.
flabdablet, thanks for this great tutorial... As you might imagine, it takes a long time for each of these ddrescue sessions to run, but I'll try to report on the method that worked for me.
posted by zachxman at 7:40 AM on August 2, 2007
flabdablet, thanks for this great tutorial... As you might imagine, it takes a long time for each of these ddrescue sessions to run, but I'll try to report on the method that worked for me.
posted by zachxman at 7:40 AM on August 2, 2007
I'd be interested to find out what happens when you run another ddrescue pass with your replacement discs. Do you, in fact, quickly end up with a perfect copy?
posted by flabdablet at 6:23 PM on August 2, 2007
posted by flabdablet at 6:23 PM on August 2, 2007
Oh shit, I killed it.
I got about 65% of the way through the copy with only a few errors... and then the drive seems to have committed seppuku.
So I have 65 percent of the data, presumably. What syntax can I use to mount the image file I was copying off the drive?
posted by killdevil at 11:29 PM on August 13, 2007
I got about 65% of the way through the copy with only a few errors... and then the drive seems to have committed seppuku.
So I have 65 percent of the data, presumably. What syntax can I use to mount the image file I was copying off the drive?
posted by killdevil at 11:29 PM on August 13, 2007
This thread is closed to new comments.
1. Physically clean them up as much as possible, by wiping an only-just-damp and very clean soft towel from centre to edge using a fair bit of force (it's important that any scratches you add during this step should be radial, not circular).
2. Open the disc with mplayer, then pause the playback. This means that the drive has been opened with libdvdcss and fed the appropriate session keys.
3. Use Gnu ddrescue to make a block-for-block copy of the disc to an image file:
cd /path/to/dvd/image/folder
ddrescue /dev/dvd dvd ddr.log
4. If ddrescue reports errors (and it most likely will), rerun it using raw device access, bypassing the kernel cache to grab the last few available sectors:
raw /dev/raw/raw1 /dev/dvd
ddrescue --block-size=2048 --max-retries=3 --complete-only /dev/raw/raw1 dvd ddr.log
raw /dev/raw/raw1 0 0
5. Unpause and quit mplayer.
6. Restart mplayer using -dvd-device /path/to/dvd/image/folder/dvd instead of -dvd-device /dev/dvd.
If there are still too many bad blocks to allow uninterrupted movie watching, go get another copy of the disc, then repeat the whole thing. This time, ddrescue will run very fast and probably error-free, because it will only be filling in, from the new disc, blocks that were bad on the old one.
If you don't already have Gnu ddrescue installed, you can get it with
sudo apt-get install gddrescue
posted by flabdablet at 5:49 PM on July 31, 2007 [5 favorites]