Hi Paul,
Many thanks for the details synopsis. Some of this was known to me,
some not. Comments below.
On 11 Aug 2009, at 23:49, Paul Hartman wrote:
On Tue, Aug 11, 2009 at 3:22 PM, Stroller<strol...@stellar.eclipse.co.uk
> wrote:
I'm just looking for a better answer than ones prefaced with
"presumably"
and which treat DeCSS encryption like it's black magic.
...
First, DeCSS is actually one (the first?) decryption method, and is
very old and mostly obsolete. What you probably meant to say was CSS
(Content-Scrambling System) which is the encryption method. Most
likely whatever programs you're running nowadays are using libdvdcss,
not DeCSS.
Yes, indeed. My apologies.
DeCSS used a compromised player key (gleamed from Xing player on
Windows, IIRC) which was revoked and invalid on newer discs, while
libdvdcss uses a computed lookup table of every possible player key
(400 or so) as well as falling back to brute force in the event of a
disc with a new set of keys so that it can decrypt nearly everything.
I didn't realise this. I assumed there was one key for each region,
and had not realised that keys had actually been revoked (how does
that work with old players?)
... On the DVD,
there are keys at the sector, title and disc level. The disc key is
needed to get the title key, and the title key is needed to decrypt
the sector keys to get to the actual movie data. The 400+ variations
of the disc key (one for each possible player key) stored on the DVD
itself in abnormal locations (possibly unreadable to dd?) such as disc
lead-in. The DVD player software gives the drive a player key and it
cycles through all of the disc keys on the DVD until it finds a match
(or doesn't).
I had not been aware of these multiple levels, either.
The behaviour makes a lot more sense to me knowing that there are
multiple keys per disk. So it's possible that one key has been
provided, yet other parts of the data stream are left encrypted. I can
relate that much more easily to the results I'm seeing.
Even if you made a 100% perfect read of the original,
nearly all consumer-grade DVD burners are forbidden from writing the
CSS key data to DVD+/-R discs (and I believe DVD-R discs even
physically lack the area where they would go).
Yes, I was aware of this, thanks.
Typically, if you want to reduce wear and tear on your DVD drive,
you'd use vobcopy which will handle the decryption and copying of the
data in one motion.
It's not really much odds to me one way or the other. For the sake of
running a single command on the drive (scandvd in the cloning.txt log)
I'd rather have the single image file created by dd, even if it's
still encrypted (rather than a clutterful directory of .vob files).
Then you should be able to transcode from those
files to the format you want without needing the disc in the drive.
Yes, I can do that, anyway - working from the (still encrypted)
"disc.iso" created by `dd`. That's why I left the `mplayer` command in
the cloning.txt log - you can see it finds the titles in the disc.iso
image and gets a key for each vob file. The screencap is clear.
Since transcoding is usually the slow part, if you've got a lot of
disc space on this new beast of a machine you might want to do all of
the copying first and then just transcode them in a huge batch
(perhaps that was already your plan from the beginning).
The transcoding is, so far, taking 12 - 24 hours per title.
With undvd (using mencoder) a movie was pretty consistently at c 12
hours, IIRC. Maybe 11 - 14 depending on the runtime. That was a
different machine - probably very slightly faster, but not enough to
make an appreciable difference. Both are olde Pentium 4s.
Today HandBrakeCLI seems to be doing 25-minute TV episodes in about 6
hours each. It's averaging about 3.6 fps, but halve that because I'm
doing two pass encoding.
I believe that both mencoder & handbrake may both rely on some of the
same libraries, but that they're basically different applications
built on top of those. Obviously I'm hoping that this apparently
slower ripping means that handbrake will give better quality. ;) It
looks like HandBrake defaults to higher bit rate / larger file sizes
than undvd, however.
Anyway, 12 or 24 hours doesn't matter - I'm plenty happy with one
movie ripped per day. It's quite a luxury to have a whole TB of free
space, and just to be able to copy the DVD to the hard-drive whenever
I want and rip at leisure. The machine on which I was previously
ripping has 6gig free on one drive & 23gig free on another, but that's
just at the sort of limits where I was finding that - experimenting
with quality settings & stuff - I couldn't keep as many images around
as I wanted to, or had to store them on the "wrong" drive and move
them to the other & stuff like that.
I have been using `for title in $(seq 1 6) ; do ...` to rip these
individual episodes, but if we're generally talking about a main
feature film then generally I don't mind checking up on the rip every
couple of hours and starting a new one when necessary, or loading the
drive once per day & making the disk image. I don't know whether it's
the switch to HandBrake or whether it's the extra space or what, but I
feel quite liberated, and that the regime I was attempting previously
somehow constrained me from ripping more. Hopefully I'll get into a
regular routine & have my whole collection done within a few weeks now.
As CSS was rendered obsolete 10 years ago, finding any technical info
is kind of hard since it seems people have moved onto more challenging
pursuits. Googling mainly results in a billion pages about copying
movies on Windows.
Yeah, I've found this in the past. It's really a bit of a swine that
all this encryption nonsense was (pretty much) imposed on us. In the
context of encryption & stuff, we're really pretty lucky with CSS that
it was so hacked so quickly.
Stroller.
