Hi there,
Now I've got this new machine with all this space on it (or rather:
now I seem to be more interested in doing stuff with this machine I
built a while ago), I'm starting on the process of ripping all my DVDs.
In the past I tried media-video/undvd for DVD ripping, but its .mp4
support now is broken, and probably won't be fixed.
This week I've been trying HandBrakeCLI, and it seems to work pretty
darn lovely.
But the difference is that undvd has a simple --clone option which
copies the DVD to disk first, and HandBrakeCLI doesn't.
To save wear & tear on my optical drive I have been cloning the DVD to
disk before ripping, and I've noticed that it doesn't seem to work if
I just do `dd if=/dev/cdrom of=disc.iso`. It seems like I have to
access the disk using some other command first, then dd works just
fine (in exactly the way I tried a moment before).
Can anyone explain this, please?
I'm guessing it has something to do with DeCSS encryption, but firstly
I don't understand how that applies to dd, because I'd have assumed
that treats the drive as a block device. Secondly, if this is related
to DeCSS, I don't understand why accessing the disk with one command
leaves it unlocked for another command to access the disk a minute
later.
Anyone got any thoughts, please?
I haven't looked into this deeply myself, yet, so I'm not able to give
a full analysis of how exactly the behaviour is manifesting itself. I
tried dd'ing one disk and it didn't work, so I started undvd working
with the --clone option and cancelled when the cloning had finished
(and the rip began). I basically wanted to see if it worked or failed,
and it worked just fine, so I looked through undvd's source and it
_seems_ (I say "seems" lest I'm reading undvd's perl code wrongly)
just to use dd itself. So next I tried `dd if=/dev/cdrom
of=disc_manual_dd.iso` myself and not only did it work just fine, but
the md5sums of the two images (the one produced by undvd & the one
produced by my manual dd) were identical.
So I tried with a different disk - take a look at the attached
cloning.txt - and dd fails repeatedly at 770kB. Then I run scandvd on
the disk and after that dd works perfectly, "8027521024 bytes (8.0 GB)
copied". scandvd is a tool which is packaged with undvd and it runs
mplayer (I'm sure) on the disk, then shows the number of tracks on the
disk in a pretty format.
This is no kind of a show-stopper for me, because I've described the
workaround above, it's just a curiosity. I guess I'm not alone on here
in wanting to know how these computer things work.
I'd be really interested if anyone else's DVD drives show the same
behaviour. Does dd fail for you when you try it on a new movie? If you
don't have undvd installed, just run `mplayer dvd://`, cancel it and
then try dd again.
Sorry if I've been a little verbose with my explanation, BTW. It's a
little late here, I'm a little tired, and with these weird things that
I almost don't believe myself I always like to explain
comprehensively, and it prolly reads like I'm blabbering.
Thanks for any thoughts,
Stroller.
