K19: Widowmaker (PAL, R4) - stutter still there with RC 5.1 Pro

[Plutox]

Just as a test... do you think you could try something…

OK - it's running now. Just in case this is significant, you said…


While you have ITEM.ECL opened change this line:

vbr_brate_max=8712

Well FWIW that line actually read

vbr_brate_max=9000

Not a huge disparity, but enough to make a difference?

I'll report results when rebuild is complete.

[Plutox]

@plutox

Just as a test... do you think you could try something?
I don't know whether this is what you want to hear or not, but the test procedure you asked for does not improve the situation. The vision & sound stuttering persists at exactly the same place.

I'm happy to do any further tests or provide information. I'll keep everything on my hard disk until further notice.

[jdobbs]

The maximum bitrate changes depending upon what audio tracks you keep.

How long does the stuttering last?

[Plutox]

The maximum bitrate changes depending upon what audio tracks you keep.
I am keeping only the English AC-3 audio.
How long does the stuttering last?
From 23'25" elapsed time to 24'25".

I also confirm that I can play the appropriate M2V file (albeit without sound) flawlessly.

[Plutox]

Is there any more information I can supply to help track this one down :confused:

[HKT3020_1]

Unfortunately I've done about every ILVU disc that can be found in the U.S. during my testing and I have yet to have had a problem with any of them... and I've tested them on PowerDVD and 6 different standalone players, including a Sony.

As for ILVU that is done with 0.93... it remains unchanged from the original -- it is copied 100% intact.

You can also force intact copying with RC5.1 by adding ILVU_ENCODE=0 to your [Options] area. If your player has problems with that -- you can be assured it is the player and/or the disc. It would be interesting to see the result.

I want to fix it -- but as near as I can tell it is only happening to a couple of people, and I need to make sure the problem is in DVD-RB.

I just backed up The Incredibles R1 NTSC successfully after removing angles 2 & 3 with Ifoedit however at 1:00:32 it comes to a pause for about 70 seconds and then resumes. This also happend on DVD-RB 0.93 back when I ripped & encoded the movie only. My question is why does this happen? On the retail DVD9 this doesn't occur at all so why does this happen on my backup? What exactly is being done differently rather than compressing it? The only possible explanation is that it is in fact my Sony DVP-665P because while 3 other players in the household play it fine then what other reason is there. :( Being that you have tested backups countless times and have run through a series of tests on multiple DVD players, is there a player you recommend? :)

[blutach]

The only possible explanation is that it is in fact my Sony DVP-665P because while 3 other players in the household play it fine That sounds like it then.

Regards

[jdobbs]

K-19: Having access to the cell in question now, I'm a little confused... because on my system with Power DVD the original VOB stutters also at the exact same spot... where the Submarine leaves port and goes to sea.

I'll continue to look at it.

[jdobbs]

K-19: Continuing. Well I definitely see an audio timing problem in the output stream -- now to find what is causing it.

[jptheripper]

hkt3020_1, try backing up incredibles without stripping angles. Ifoedit isnt great at it.

[blutach]

@hkt3020

Before processing with DVDRB, try giving it another run through with IfoEdit doing a mock strip (http://forum.doom9.org/showthread.php?s=&threadid=84097) on the movie's titleset.

Was this the disk you PM'ed me about, which was not an angle but rather just a seamless branching disk?

Regards

[jdobbs]

K-19: Well I'm looking at the original cell that was sent to me. It has errors all through it. There are numerous audio packets in which the presentation time (PTS) is earlier than the system clock reference (SCR) at the time of arrival of the packet. That means the player would have to go back in time to play it...

There's not a lot I can do with something like this. Either this cell has been modified or whomever authored this disc was drunk at the time... I'm surprised this could even get through an authoring package... Here's an example:

[jdobbs]

It isn't just the audio, either. I'm finding the same thing for video GOPs that have a DTS/PTS that is earlier than the SCR....

[HKT3020_1]

@hkt3020

Before processing with DVDRB, try giving it another run through with IfoEdit doing a mock strip (http://forum.doom9.org/showthread.php?s=&threadid=84097) on the movie's titleset.

Was this the disk you PM'ed me about, which was not an angle but rather just a seamless branching disk?

Regards

I've pretty much done that during the removal of angles 2 & 3 and made sure the DVD plays fine on Ifoedit's player. Also to answer your question this is another disc, the one I PM'ed you about was Aliens SE. That movie contains seamless branching and it looks like I'll just be doing movie only with that disc. :o

[jdobbs]

K-19: So here's the bottom line... There seems to be about a minute of audio/video in the original source that is out of whack. It then corrects itself. So I went back and burned the original cell to a DVD and it plays without stutter on a standalone. The reason seems to be that both the audio and the video are equally wrong (with Presentation Time and Decoding time in the past)... as a result (at least on my player) the player seems to compensate. I have to believe, though, that there are standalone players that will choke on this (as Power DVD does on my computer).

But DVD-RB authors the video correctly -- with the DTS/PTS falling appropriately after the SCR time (as it always should). The audio stream, however, is left untouched and is reintegrated with the video. As a result, since one is correct and the other is goofy, the stutter happens.

I really don't want to get into the mode of trying to correct timing errors in the original DVDs... it would have no end and there is no limit to the number of possible errors that could exist in bad authoring. What I'm trying to decide is whether this is worth finding and flagging as an error when reading the source. I would never expect to see such a thing in a commercial disc...

I will look, though, and see if there is an easy way to fix an incorrectly built original. I may be able to work off of the PTS instead of the SCR in order to rebuild this disc.

[jptheripper]

jdobbs in sticking withthe "keep original as possible" mentality, would it be possible to keep this minute raw so the error is translated in tact? i.e. scan for these reference errors, and if they are there, just dont reencode that section. I dont know if that is possible.

seems like the "garbage in, garbage out " addage applies here.

[jdobbs]

I don't think so. There are numerous other implications to not properly reauthoring -- it is not compliant with the DVD specs -- and as I said, I think it will still cause problems. I'd much rather correct it than let it be reauthored badly... when that happens it becomes my fault.

[jptheripper]

fair enough

[brashquido]

That is weird as the original cell plays fine in PowerDVD (verision 4) for me. So glad we found SOMETHING though :)

[Plutox]

K-19: Either this cell has been modified or whomever authored this disc was drunk at the time... I'm surprised this could even get through an authoring package...
This is almost incredible and I'm truly amazed that a professional authoring package permits this type of error.

In a way it is even more surprising that the duplicating/manufacturing house does not reject a master containing errors like this, as the legal complications of having ten thousand or more faulty discs in the distribution channel are colorful to say the least.

"You've made a faulty disc, costing us money and reputation"
"We've only duplicated the master supplied by you"
"It was your responsibility to check and reject the master"
"Had we not gone ahead with production we couldn't possibly have met your absurdly tight timing demands"

For this reason most decent production companies will refuse to manufacture a title that does not conform to the specfication.

[Plutox]

I will look, though, and see if there is an easy way to fix an incorrectly built original. I may be able to work off of the PTS instead of the SCR in order to rebuild this disc.
How feasible do you think it would be to detect this type of inconsistancy between the sound and vision streams and correct it by using PTS? A few hours of work may be justified - any more than that, doubtful IMHO.

Is there one particular commercial authoring package that is buggy in this respect and creating dodgy masters? Are there enough instances of this type of error to justify the creation of a work around?

[Sir Didymus]

Is there one particular commercial authoring package that is buggy in this respect and creating dodgy masters? Are there enough instances of this type of error to justify the creation of a work around?

Hi, hi. Maybe you will be surprised to realise that the right question is the opposite: "Is there one particular commercial authoring package that is not buggy in too many respects... ?"... At the present time you can count them on the fingers of "less than a half a hand"...

...and the tools to check the compliancy of a given title against the DVD specs are few and quite expensive...

Said this, it seems to me the alteration presented is too incredible to be generated directly by an authoring package... Most probably some external process (stripping ? preprocessing ? the simple extraction of the cell through some improper tool ?) has been performed...

[jdobbs]

I have been giving thought to the possibility that it might be purposeful... protection maybe? I don't think you could get one of the professional authoring packages to do this even if you wanted... but it is clearly there -- and right in the middle. The part just before and after are timed correctly.

Curious.

[Plutox]

I have been giving thought to the possibility that it might be purposeful... protection maybe?
If you like conspiracy theories, how about the possibility that this was (is?) a low-level, discreet trial of an anti-copy scheme that covered large sections of the film with this type of temporal discontinuity?

It appears that most people had no problems playing the original, so why not cover the whole movie with this stutter protection?

[brashquido]

I'm on the same boat as Jdobbs on this one. Assuming those responsible for authoring the original are competent, the only logic that really works for something like this to be there is that it was put there on purpose. And as this is outside DVD compliant spec, it would be logical to assume that putting something like this in there on purpose would be done as some kind of copy protection scheme. As to why it is only done in this one section instead of the whole movie is anyones guess. Mine would be that as Jdobbs mentioned eariler this will make the disk unplayable on some DVD players, and people would be much less likely to return a DVD for refund if only a 1 minute section was effected rather than the entire disk. Conspiracy theory I know, but apart from a lapse in QA on the master there aren't too many other plausible possibilities.

If this turns out to be too much work to implement a fix for Jdobbs, would it be possible to have a system where DVD-RB detects the error, and then enables the user to input a custom "corrections file" that contains user specified timings? Idea being that users create these correction files a specific movie, and then shares them with the community for others to use. Not ideal at all, but at least would give some avenue for correcting dodgy masters...

[jdobbs]

That's not likely. It would be incredibly complex (pretty much impossible) to try and calculate DVD timing by hand... the SCR timings have to match the frame serving and sector reading exactly -- they also have to mux exactly -- and you have to know the temporal start/finish of each GOP (not delivery times or playback order -- but temporal order) based upon the frame type at the start of the GOP and which frame is temporally first... if you get just a little off it will skip all over the place...

I think I may add some code that will look for discrepancies in SCR and DTS/PTS and adjust the SCR so it is compliant. It all depends how difficult it is to do.

[brashquido]

Ok, cool...

[Plutox]

So if this was/is a trial of a putative anti-copy technology "let's see how many complaints we get about the section where the submarine leaves port", considering that most of us seem to be able to play the original disc without problems, what's to stop them creating whole discs covered in this kind of anomaly?

While not insurmountable, it would certainly make the work of writing copying software much harder than it already is.

[jdobbs]

I don't know... the more I think about it the less I think that is the case. An incorrect SCR is a pretty big problem -- they'd be foolish to purposely make their DVD out of spec...

[jdobbs]

Just as an update to this troublesome original. I ran a further analysis on the original cell -- the problem isn't limited to the audio -- while not as bad as the audio, the DTS and PTS occasionally fall behind the SCR on the video as well.

[jptheripper]

jdobbs, any idea on the authoring tool they used that would allow this?

[brashquido]

This really does seem to be turning out to be a can of worms :( ...

[Plutox]

they'd be foolish to purposely make their DVD out of spec...
Who'd have thought that they would design a copy protection system for audio CDs that deliberately introduced so many errors as to make the disc nearly unplayable...

[brashquido]

Um.... Jdobbs, please don't kill me.... I just tried K19 again from scratch with 1.01 Final, and although greatly improved there is still significant pauses every few seconds in cell 11. Towards the end of the cell it gets very screwed up and audio and video are totally out of sync by several seconds. Then just like nothing had happened it all syncs again and away we go again....


I will see if I can find some time to get details for you...

[jdobbs]

The original is non compliant... there's not a lot I can do about it.

[brashquido]

Ok, I understand. Looks like I am going to have to put this to a dual layer if I want a copy that is watchable. Would it be worth considering having a pop up window (something that can't be ignored) when these errors are detected by DVD_RB with a message saying that the original is not standards compliant and as a result DVD-RB can not garantee flawless backup? Just using K19 as an example, it is only a very small portion of the movie that is effected, so people mightn't pick it up unless they watch the entire movie after using DVD-RB to back it up.

[brashquido]

Just thinking again...

Perhaps a pop up window isn't appropriate as it would interupt work flow in a batch proccess scenario. But what about highlighting lines in the status window that potentially need user attention? That way a user is alerted to any potential issues with the project so they know to be extra careful when reviewing the end result without interupting workflow. Just a suggestion, but I'm sure you might have plenty of them already :)

[jdobbs]

If you look at the log you should see a warning that SCR errors were found.

[roux]

Is the SCR errors warning always mean there's a part out of sync? I've done a backup where this warning is given but i watched it on my computer and did not noticed anything in that chapter.

[jdobbs]

No. It also doesn't necessarily mean it will be "out-of-sync". Sometimes it may cause a picture shutter. In most cases, though, DVD-RB should be able to fix it.

The warning means that there is a portion of the original audio stream that has a PTS (Presentation Time Stamp) or DTS (Decoding Time Stamp) that falls before the SCR (System Clock Reference) of the pack that delivers it. Since the SCR is the time the data arrives at the player, it would be impossible to decode/present the data at the time it is required.

When DVD-RB sees that circumstance, it attempts to adjust the SCR in order to correct the problem. If the change to the SCR isn't too dramatic, it can be done and everything is ok. In that particular Region's PAL K-19, however, it seems it is too big a mess to correct.