(Sorry, I accidently posted an incomplete message earlier. I couldn't figure out how to delete it, and wasn't able to edit it before the 30 minute limit expired. The following should be complete, but I probably won't be able to read the responses until tomorrow.)
Newer schemes, generally referred to as "structure protection", work differently and are different from title to title, each with different decoding requirements for a proper read.
Can you point me to some more information about "structure protection"?
I have no idea why, nor why player type smarts could not be written into copying software. The idea that it can't is counterintuitive, but I'm sure there's a good reason.
I'd like to learn what that is.
This sounds more like a read error or bad spot on the original disc. Error handling has improved as the product has evolved. Is the original a DVDR (bluish) or DVD-ROM (silver)?
Both discs are silver.
Again sounds like a read error.
I agree, but I don't think the errors are there because of dirt or scratches. I think that they are encoded into the DVD master. They are intentional errors that are part of the copy protection scheme. I'm an old timer, and they used to do similar things to floppy disks when software was distributed on floppies.
I would upgrade to 184.108.40.206 and see how you have error handling set up in Common Settings-->Read. Select the "Ask/Retry/.." button and allow a larger number of retries in the "Retries" pulldown menu. Brief hiccups in the output are not typical copy protection symptoms.
That's puzzling. When I backed up "When The Levees Broke..." it seemed to be doing a lot of retrying. I thought it was excessive. Judging from the program's progress bar and the LED on the DVD drive, the program spent nearly all of the 1 hour and 20 minutes required to process the disc retrying in only a couple of spots. But "Retry times" was set to "1".
Something else is strange. "Ask retry/ignore/abort when reading error" was checked, but the program never reported an error or asked me how to handle it, indicating that there were NO read errors. It doesn't make sense.
Here is a bit of history.
I first encountered this problem while using DVDShrink. I think it reported a CRC or some other type of read error. The first time I had encountered this, the disc had problems on a regular player also. I fixed both problems by polishing the DVD using something called Kit Scratch Out, a car polish that I got from WalMart.
The second time it happened, polishing the DVD didn't work. I concluded that the read error was put on the disc intentionally by the publisher as a copy protection method, the way software publishers began to do years ago on floppy disks, so DVDShrink needed to be updated to handle read errors.
I couldn't find a DVDShrink update, but found something new called DVDFab that worked, sort of. Its output was playable, but had annoying glitches.
The glitches were what I call "duplication glitches", because it appeared that they were the result of blocks of VOB file being included in the output twice. I could see split seconds of video repeated, with motion compression errors apparently because of the referencing of incorrect frames. And I could hear split seconds of audio repeated. I thought that what might be happening was that the publisher was duplicating VOB file blocks, once with a flaw that would cause a read error, and once without a flaw.
I further concluded that the players were probably simply throwing away any VOB file blocks with read errors and going on to the next block. But since they were throwing away blocks that were not needed, the disc played flawlessly.
But the copying software was apparently doing something different. It was including every block in the output stream, including the duplicate blocks that had read errors, resulting in the duplication glitches.
If this was true then a fix would be easy. I was going to try to contact the software author and suggest the fix: Discard blocks with read errors. I didn't do that because the next version of the software seemed to work okay. I thought that the author had figured it out and made that fix.
But apparently that is not what happened, because new DVDs require new software updates. Based on all the data I've seen so far, this is what seems to be happening:
DVDFab will handle a DVD in one of 2 ways.
It will keep VOB file blocks with read errors, which results in (duplication) glitches.
It will discard VOB file blocks with read errors, which results in a flawless copy.
Old DVDs are copied with method 2. New DVDs are copied with method 1. But the meanings of "Old DVD" and "New DVD" are not constant. They depend on the version number of the software.
So my new questions are: Does my analysis seem reasonable? If it is then: Why is method 1 used at all?