My fault for cluttering the essence of the script with fluff. I went back and highlighted that part.

CSS will not prevent a direct copy (with dd, etc.) You won't necessarily be able to PLAY the copied file, because it still contains the CSS encryption. But you should be able to COPY it.

That is if the DVD is protected by pure CSS. But many DVD's go beyond this. They throw in intentional bad sectors to thwart efforts to copy them. It is these bad sectors that throw dd into a tizzy. And while ddrescue may be able to get around them, it can take a very very long time.

What you need is a command that has the smarts to read around the bad sectors. This is supplied by "dvdnav" (but dvdnav is not a stand alone program, it is library support only). There is no content you want to try to recover out of those bad sectors after all - they are thrown in there on purpose to screw up copy attempts.

To backup the entire DVD, try:

dvdbackup works most of the time, but not always. There is yet another copy protection that is seen frequently where the file system of the DVD is intentionally scrambled. You can see this if you mount the DVD, and then run du or df on it's mountpoint. The result will show something impossible, like 50Gb. DVD's aren't that big. Anyway, if you attempt to use dvdbackup on such a disk, it will merrily chug along and copy you a gigantic 50Gb file. And it's doubtful that you'd ever be able to use that 50Gb file for anything. Probably not playable, but I have not tried to play one of these beast files myself, so I don't really know.

When dvdbackup fails as above, you can use mplayer to rip. But I have only used mplayer to rip a specific title from a DVD, not the entire DVD. I do not know if mplayer can rip an entire DVD or not - I simply haven't tried, so I don't know the answer.

To backup just one title from the DVD, try:

An actual invocation would look like the example below. Notice all the slashes in the command after the word "dvdnav" appears ... tricky syntax.

Note: Some distros provide mplayer WITHOUT dvdnav support compiled in. At least they used to. I am not sure about now. Back in the days where this support was not universal, I downloaded the source for mplayer and prior to compiling, during the configuration phase, I specified to include dvdnav support. It is (was) a configurable option.

So bottom line: You need to be able to deal with CSS, intentional bad sectors, and scrambled filesystems. And who knows what else may be thrown into the mix in the future. And in the case of mplayer, where you are ripping only one title, you need to know which title to rip. That can be difficult to determine sometimes, especially when you have the scrambled filesystem - that also presents as having many (typically 99) titles on the DVD. Easiest way to find the correct title to rip is to play the DVD in your home DVD player. Once you've navigated around all the menus and the main feature is playing, look at your DVD players display. Most have an indicator telling you which title is playing. You can also see a currently-playing-title indicator in VLC if you're playing your DVD that way (you have to search for the indicator - it's somewhere in the menus).

So why is it necessary to open the DVD with VLC or similar before ripping?
I have come across a DVD box set that won't allow copying with dd due to bad sectors -- in fact it was so bad that even dcfldd and even some combination of commands meant to repair the image didn't work (I forget the exact strategy) it was so bad I gave up.
However, it remains that "normal" DVDs have to be played before they can be ripped and I can't see how bad sectors would make any difference to this as you're not altering the data on the DVD?

Despite haertig's assertions to the contrary, there must be some encryption (whether CSS or not, I do not know) issue with many commercial DVDs that *vlc and brasero know how to handle, but *dd do not know how to handle.

Your ~/.dvdcss directory should have a load of folders with names associated with DVDs that you've played with vlc, and my hypothesis is that *dd uses those files to dump the DVD to hdd.

Anyone who says, "no that's wrong" needs to explain the "bad sector" errors that we see before using *vlc and the lack of bad sectors afterward. If they can't, then they're just blowing smoke.

But how would a low-level tool like dd even use an encryption key? I have seen the key files mentioned and I have no doubt they're used by the various programs like VLC to unscramble DVDs but for the life of me I can't work out what difference that makes to dd. Unless /dev/sr0 is a "dummy" device much like when a luks encrypted device is mounted.

this is what i do:
http://www.linuxquestions.org/questi...9/#post5219039

i think that lsdvd will allow dd (or whatever) to decrypt the dvd while it is copying/encoding.

I have never found that necessary. I don't routinely open the DVD's before ripping.

It could be that whatever software you are using to rip with does not understand how to handle CSS natively, but is able to take advantage of the work VLC has done. You will note that after playing a DVD with VLC (or any other media player that supports libdvdcss2 - which most do), you will have a .dvdcss subdrectory under you $HOME. In in that .dvdcss directory you will find info from the decrypt process. Could be that your ripping software does not know how to create this info, but is able to use it if it already exists, created by some other program.

This is just my guess. Personally, I have never had to play a DVD in VLC or any other media player before ripping it. So I've never encountered the issue you mention here.

What are you using to rip with? Try "dvdbackup" without playing the DVD first. See if that works for you without playing the DVD first.

The bad sectors are what's making you have to "play before rip". I have no idea where your problem there could be coming from, other than my guess above. For things like dd that are just trying to copy raw data from one place to another, these bad sectors are problematic. Because dd, et. al., have no idea if those bad sectors contain data that you really want or not. What dvdnav does, is treat the source not as raw data to be copied sequentially, but as a DVD. dvdnav says, "How would a standalone DVD player extract a data stream from this source?" Well, a DVD player would follow the pointers that were generated in the DVD authoring process. And those pointers "point around" the bad sectors, so they never come into play. dvdnav is smart enough to follow the pointers, and not attempt a problematic sequential copy that would try to rip those bad sectors.

That could be the case schneidz but I'm interested to know how something al low level as dd is doing anything but copying block of data from one place to another. hence my guess about /dev/sr0 being, or becoming, a pointer to a decrypted data stream.
What can I say, haertig, I have always, as long as I remember, had to play DVDs before ripping on Linux with the only exceptions being a few music DVDs which weren't CSS encrypted or region coded. This has been the case whether I am using something like DRDRip or simply using dd on the command line, the latter being the method I prefer to employ and have used on my entire collection fairly recently.
The reason I am asking about this, by the way, is that while it is possible to rip using the methods we've described using scripts and/or using cvlc to open the DVDs first I'd still like to know what's going on both out of curiosity and in case there is a way to streamline the process. It seems that at the moment we've resolved an issue but we don't actually know what the underlying problem is that we're dealing with.

I never asserted anything like that. "Some kind of encryption that VLC knows how to handle but dd does not?" That would be EVERY encryption, because dd understands NONE of them. You do understand that VLC knows that it's playing a DVD, and how to navigate it as a DVD thus skipping around bad sectors, navigating scrambled filesystems, and decrypting CSS whereas dd is only looking at a stream of bits, not knowing whether those bits represent a DVD or a text file, right? Of course dd knows nothing about encryption.

Your hypothesis is 100% incorrect.

"No, that's wrong". And I can't explain your claim that bad sectors magically disappear after playing a DVD with VLC. I believe you are wrong in that claim, just as you are wrong in your hypothesis about dd using files under .dvdcss. I guess that means I'm blowing smoke in your opinion. Bottom line: You asked for help in your post. I attempted to provide you some help. You can't seem to rip your DVD's. I can rip mine just fine. Then you get huffy because someone else obviously knows something that you don't know. Some days it's just a waste of time trying to help some people...

I just don't know. But do you have a better hypothesis that fits all the facts?

No, and that's the point. All we have here is speculation.
We have two people who have recognised the same behaviour and at least one who hasn't. We have a couple of incomplete hypotheses neither of which are backed up by anything but hunches.
So, as things stand what the collective wisdom if this site is saying is that in order to rip DVDs with dd some people must in some way "play" them with an application first. We also have some ways of "playing" them that involve scripts and the like which ought to be reliable. That's all well and good but is it beyond the realms of possibility for somebody to actually know what is going on here rather than having to guess?
My own hypotheses about /dev/sr0 being or becoming a decrypted stream makes sense -- does that mean I know that's the case? Do I get to decide how things work just by typing them?
OK, so this isn't the most important thing to know but am I the only one who would actually like to know the facts of what is going on rather than just guessing?