Re: [gentoo-user] Re: Cloning movie DVDs with dd - only works after accessing disk with another command?
- Original Message - From: Stroller strol...@stellar.eclipse.co.uk To: gentoo-user@lists.gentoo.org Sent: Tuesday, August 11, 2009 4:22 PM Subject: Re: [gentoo-user] Re: Cloning movie DVDs with dd - only works after accessing disk with another command? On 11 Aug 2009, at 20:31, Grant Edwards wrote: On 2009-08-11, Stroller strol...@stellar.eclipse.co.uk wrote: I'm just really curious why `dd` works perfectly fine the last time, but not the first. Hasn't this been answered several times already? No, it hasn't. Presumably it works the second time but not the first time because between the two attempts you've run a program that has written the decryption keys to the optical drive. I'm just looking for a better answer than ones prefaced with presumably and which treat DeCSS encryption like it's black magic. I don't say that to offend anyone, because I'm sure none of the other posters doing so are claiming to be experts on the subject, either. Presumably anyone replying saying oh, it must be something like this is interested in discussing their conjecture. If you disagree with that answer, please esplain why rather than just re-asking the question again and again. Well, in the case of the message you quoted, the poster seemed not to have read the cloning.txt console log I posted. He seemed to be telling me that what I have done is impossible and I was correcting his misunderstanding. You will see that I already explained in my message of 11 August 2009 19:58:11 BST some aspects of this still confuse me. If you'd like me to clarify that post further then I guess the best way I can explain it is: if I've run a program that has written the decryption keys to the optical drive (your words), how come mplayer still has to retrieve the CSS keys (see cloning.txt) when it's run on the disc.iso file? (using -dvd-device argument) The answer to that is surely because the movie is still encrypted, so (to me) that begs the question why's the movie file still encrypted if I've written the decryption keys to the optical drive? This seems to me to be a logical loop, and I'd really be genuinely glad for someone to explain where I'm looking at it wrong (but please ignore this message if the subject is bothering you). I suspect someone who really understands what's going on here doesn't need the additional clarification of my previous 2 paragraphs. There's probably a really simple explanation for what's going on here. Stroller. To copy dvd to your p.c. just use mplayer/mencoder...It's not that difficult. It shouldn't be too difficult to get the dump back onto DVD disk. It's not that big of a deal. dd probably worked because the disk wasn't encrypted. Run the history command and investigate. This could have been a fluke. It's nothing to ramble on about.
[gentoo-user] Re: Cloning movie DVDs with dd - only works after accessing disk with another command?
This is just a wild guess, but could the decryption keys be stored in the DVD drive? Playing the disc with mplayer retrieves the keys (using libdvdread) and sets them in the drive. From that point, the disc is readable by all means. When you change the disc, the keys are not valid anymore. As I said, this is a wild guess, I have no actual knowledge about these things. -- Remy signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: Cloning movie DVDs with dd - only works after accessing disk with another command?
Stroller stroller at stellar.eclipse.co.uk writes: 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. QDVDauthor is very cool. Version 2.0 is soon to be released. When it is, I'm going to ask the dev for a version bump. The current release is 1.11.0 Ebuild is currently at 1.2.0 If you can wait a few weeks, QDVDauthor 2.0 is suppose to be very cool. You can beta test it now, on gentoo, as Varol, the main dev is really cool to work with. http://qdvdauthor.sourceforge.net/ HTH, James
Re: [gentoo-user] Re: Cloning movie DVDs with dd - only works after accessing disk with another command?
On 11 Aug 2009, at 16:28, James wrote: Stroller stroller at stellar.eclipse.co.uk writes: 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. QDVDauthor is very cool. Version 2.0 is soon to be released. When it is, I'm going to ask the dev for a version bump. The current release is 1.11.0 Ebuild is currently at 1.2.0 If you can wait a few weeks, QDVDauthor 2.0 is suppose to be very cool. You can beta test it now, on gentoo, as Varol, the main dev is really cool to work with. It looks jolly, but it's waaay more than I need. The machine is a server with lot of disk space in it, but it's headless and I interact with it by ssh. It's no problem to walk through pop a disk in it, but I prefer to just run a single `myrippingalias filename.mp4` in a screen session, rather than to have to open a window check boxes. I have no need to author DVDs right now. I think I have *once* made a DVD-R of a movie to prevent the kids from scratching the original and in such circumstances I was quite happy with the video quality of a single layer, so was able to do that pretty easily at the command line, too. Stroller.
[gentoo-user] Re: Cloning movie DVDs with dd - only works after accessing disk with another command?
On 2009-08-11, Stroller strol...@stellar.eclipse.co.uk wrote: I'm just really curious why `dd` works perfectly fine the last time, but not the first. Hasn't this been answered several times already? Presumably it works the second time but not the first time because between the two attempts you've run a program that has written the decryption keys to the optical drive. If you disagree with that answer, please esplain why rather than just re-asking the question again and again. -- Grant Edwards grante Yow! I want a WESSON OIL at lease!! visi.com
Re: [gentoo-user] Re: Cloning movie DVDs with dd - only works after accessing disk with another command?
On 11 Aug 2009, at 20:31, Grant Edwards wrote: On 2009-08-11, Stroller strol...@stellar.eclipse.co.uk wrote: I'm just really curious why `dd` works perfectly fine the last time, but not the first. Hasn't this been answered several times already? No, it hasn't. Presumably it works the second time but not the first time because between the two attempts you've run a program that has written the decryption keys to the optical drive. I'm just looking for a better answer than ones prefaced with presumably and which treat DeCSS encryption like it's black magic. I don't say that to offend anyone, because I'm sure none of the other posters doing so are claiming to be experts on the subject, either. Presumably anyone replying saying oh, it must be something like this is interested in discussing their conjecture. If you disagree with that answer, please esplain why rather than just re-asking the question again and again. Well, in the case of the message you quoted, the poster seemed not to have read the cloning.txt console log I posted. He seemed to be telling me that what I have done is impossible and I was correcting his misunderstanding. You will see that I already explained in my message of 11 August 2009 19:58:11 BST some aspects of this still confuse me. If you'd like me to clarify that post further then I guess the best way I can explain it is: if I've run a program that has written the decryption keys to the optical drive (your words), how come mplayer still has to retrieve the CSS keys (see cloning.txt) when it's run on the disc.iso file? (using -dvd-device argument) The answer to that is surely because the movie is still encrypted, so (to me) that begs the question why's the movie file still encrypted if I've written the decryption keys to the optical drive? This seems to me to be a logical loop, and I'd really be genuinely glad for someone to explain where I'm looking at it wrong (but please ignore this message if the subject is bothering you). I suspect someone who really understands what's going on here doesn't need the additional clarification of my previous 2 paragraphs. There's probably a really simple explanation for what's going on here. Stroller.
Re: [gentoo-user] Re: Cloning movie DVDs with dd - only works after accessing disk with another command?
On Tue, Aug 11, 2009 at 3:22 PM, Strollerstrol...@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. I can't give you a definitive answer to your original question but I can hopefully shed some light on how CSS works, no black magic. Let me say also that I'm no expert and this is all as I understand it. 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. 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. CSS is handled in a series of keys, and the hardware of the DVD drive is involved in at least some of the key authentication. 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). 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). I can't give you a definitive answer on why dd gives you different results, but I would tend to agree with the presumption of the other people who replied. My suspicion is that a valid player key was given to the drive by the other program you used and the door was left open so to speak, causing the drive to then output valid data when you used dd on it the second time. I'm not sure how long that player key lasts in the DVD drive (if it does at all). I guess you could look at the sources of libdvdread and libdvdcss to see exactly how it's done. 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. Then you should be able to transcode from those files to the format you want without needing the disc in the drive. 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). 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.
Re: [gentoo-user] Re: Cloning movie DVDs with dd - only works after accessing disk with another command?
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, Strollerstrol...@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
