broken Vobcopy :(

[tfindlay]

Hi,

The last week or two, I've been trying to backup some new movies with the trusty "vobcopy -m". Only it always bombs out now.

I get all the way upto the actual movie part and then it dies like so:

Writing to /home/blah/Desktop/Movies/<title>/VIDEO_TS/VTS_01_1.VOB
0MB of 1024MB written ( 0.0 % )
[Error] Error writing to /home/blah/Desktop/Movies/<title>/VIDEO_TS/VTS_01_1.VOB.partial
[Error] Error: Bad address

I suspect it could be a libdvdread problem ?
I'm using libdvdread-0.9.7-2.fc6

Or a kernel problem ?
using kernel-2.6.20-1.2933.fc6

Has anyone else come across this problem ?

[SuperNu]

Could it be that your dvd you are copying has some sort of copy protection beyond CSS such as Sony's ARccOS? Vobcopy expects no bad sectors on the dvd, so if something like ARccOS is being used, vobcopy will fail. You might have better luck using DVDDecrypter and Wine.

--SN

[tfindlay]

Yeah, thats possible. I've tried 3 different source DVD's so I didnt think it would be the disk.

It's a cow that Linux keeps pilllaging windows apps to solve its problems though, weather it's DVD Decrypter, Ndiswrapper or whatever.

I've tried K9Copy, DVD::rip, but both report the same thing, thats why I suspect it's a libdvdread problem.

[linux_for_you]

I think I am on to something here.

I am using vobcopy, 1.0.2 (?) Suse Linux 10.2 on US DVD's.

I ran into this error that people are mentioning with two disks, specifically "Pirates of the Carribean 2" and "The Descent". But I didn't have a problem with "Serenity".

In both cases it seesm that the problem lies in one VOB specifically. VTS_01_1.VOB.

So I ran the normal Vobcopy -m. Then when it bailed out on the problem VOB, I deleted the *.VOB.partial file that vobcopy creates. I did a cp /dvd/mount/point/VIDEO_TS/VTS_01_1.VOB /hdd/location/of/ripped/movie/VIDEO_TS/

This does a piss poor job of copying the file, copying on 300MB of a 1GB file. Then I ran vobcopy again. and I continued and skipped over the already created directories and files. Then it goes on to rip the rest of the disk.

Then I played the ripped dvd and it looked just fine. I didn't watch the whole thing or try going to every part of the menu options to test it all out yet, but it looks good.

A previous author on the Gentoo forum site, suggested that in the normal play of the movie, the IFO files cause a jump from VOB to VOB as necessary. I doubt anything ever redirects to this crappy VOB. (or worse maybe there is a trap in the beginning of the vob, and something redirects into a later part of the vob). Its like this is a VOB trap for people that are Ripping DVDs.

Hope it helps.

[linux_for_you]

Thinking about this some more, I didn't need to go through the trouble of doing the cp step. I could have just created an empty file called VTS_01_1.VOB so that vobcopy would prompt me to skip it while ripping the whole disk under "vobcopy -m".

This is such an ingenious idea, though also lame, way of protecting a disk. I think this technique woudl also cause problems for some people who just can to copy the disk to a burnable dual layer DVD.

It sounds like "their" technique is to specifically encode garbage into one of their files, no let me be more specific. its not like it is garbage as in corrupted frames in a VOB, the corruption is actually in the blocks of data in the ISO file used to create the master disk. File systems don't like to have bad blocks on a disk. This is a digital "scratch" on the disk.

The reason people have said that it looks like LIBDVDREAD and/or LIBDVDCSS is hanging up on this is that these libraries (I think) access these files on the disk and try to do manipulations on the datastreams coming from them. But the filesystem itself chokes when it tries to read a file where a block is bad.

My limited understanding of a good versus bad block, is that for every chunk of data there is an error checking code embeded that "verifies" that teh block is good. This embedded code is a result or partial result of a mathematical formula of the data in the block. If the block data, once plugged into the formula doesn't equal the code, the block is labeled as "bad".

It is only in systems that try to look at EVERY file (rippers and copiers) that will trip into this corrupted block. A DVD player, and even Xine w/LIBDVDCSS start at the VIDEO_TS.VOB and VIDEO_TS.IFO file and then go from there as the information in the IFO file tells the player where to jump next. I would bet that the first conclusion to be made here is that no IFO instruction ever causes a jump to the file that has the corrupted ISO block.

IFO jumps, I believe, not only specify which file to jump to, but also can offset into the file. There may be a situation where a movie company will have uselful content in blocks of a file on either, or, both, sides of the corrupted block. I would think that the best case here would be to analyze the IFO file for a specific VOB and pad the ripped file VOB with the right block "volume", so that, offsets will still be valid. That assumes of course that the VOB contains any useful content.

So a smart ripper would build an IFO jump map that starts from VIDEO_TS and works from there, finding all the places that a user playing a DVD could navigate to. That would mirror the way a player effective plays a disk with this new "encryption". Is "corruption" not "encryption". The encryption scheme is fixed, because a DVD player has to be able to play all the DVD's.

Sweet