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

[brashquido]

I've been trying to make a backup of K:19 Widowmaker which is a ILVU title since Jdobbs first put in ILVU code into DVD-RB, but I keep getting the same stutter (do a search for K:19) in the exact same spot on every attempt. I tried uninstalling and deleting all my DVD-RB file and related programs last night, reinstalled them all fresh (along with DVD-RB RC5.1 Pro), but am still getting the exact same stutter issue. With the amount of time I've spent on this it would have been much easier to just get a DVD-R DL and make a straight 1:1 backup, but I like to know why things don't work when they should.

Anyway, I am not sure now this is an ILVU issue, as Jdobbs seems pretty sure it should work, and I know that the opening credits which definitely is an ILVU segment (titles are in different languages) plays correctly. I don't have access to my DVD-RB log files now, but I seem to remember seeing that the CCE low bitrate value was set at only 600. My question is could an excessively low bitrate cause this, or would a bitrate that low only be used for blanks? Viewing the problem segment though there seems to be no image artifacts that would suggest overly compressed video.

Things I'll try from here are;

1) movie only backup

2) using encoder other than CCE


P.S - Should mention that at all times when trying to make a backup of K:19 there has been no pre-processing with any other application, and am working with a straight ISO rip doing a default 1:1 backup in DVD-RB.

[brashquido]

Just tried doing a movie only backup of K:19 and the stutter is still there, it actually might be even slightly worse. I did some poking around and I found the actual .m2v and .avs files in the D2VAVS directory, but neither of them display any of this stuttering when played directly. I did notice a few avs that when played would give a "MPEG2Source: couldn't open source file, or obsolete D2V file (F:\Temp\D2VAVS\V0D143~1.AVS, line 6)" error. Line 6 of that AVS file was: "mpeg2source("F:\Temp\D2VAVS\VI0400008001.D2V")".

[jdobbs]

That's normal -- that would be the ILVU sections that need to be extracted on-demand.

[jdobbs]

Which/how many audio streams are you keeping? Does the stutter change or go away if you select a different audio stream?

[brashquido]

I'm doing a straight 1:1 backup, so all audio streams are there (English & French 5.1, and English commentary). Just deleted the files :rolleyes:, so I'll set it going again overnight and test switching the audio files.

[jdobbs]

Thanks. The most likely cause for stutter is when the bitrate exceeds the maximum. I'd like to see if maybe I'm not lowering the maximum bitrate enough accomodate all the audio channels.

Also, are you using OPV?

[brashquido]

Stutter is there no matter what audio channel is selected. According to RB-Opt everything is OPV (which is the default isn't it?). Here is everything I can find regarding that segment in the DVD-RB prepare files;

Rebuilder.ecl

[item]
title=V04001000011001
aud_out=0
vaf_file=F:\Temp\D2VAVS\V04001000011001.vaf
aud_file=F:\Temp\D2VAVS\V04001000011001.mpa
file_focused=0
packet_size=2048
width=720
height=576
frame_rate_idx=3
cbr_brate=6000
vbr_brate_avg=2420
vbr_brate_min=500
vbr_brate_max=8712
seq_endcode=0
dvd=0
half_width=0
half_height=0
lum_level=0
adjust_q_matrix=0
aspect_ratio=3
gop_m=3
gop_nm=4
gop_hdr=12
seq_hdr=1
all_closed_gop=0
fix_gop_length=0
samples_per_sec=44100
stereo=2
brate_idx=7
crc=1
progressive=1
alternate_scan=0
intra_dc_prec=2
intra_dc_precision_9_max=113
intra_dc_precision_10_max=113
aud_mode=0
tc_ref_frm=0
drop_frame=0
fix_vbv_delay=0
letter_box=0
pulldown_detect=0
offset_line=0
create_new_vaf=1
credits_tweak=0
credits_start=0x00000
credits_brate=1000
h_filter=0
h_filter_idx=8
dither=0
dither_max=8
quality_prec=16
timecode=0x0000000
video_type=4
vid_file0=F:\Temp\D2VAVS\V04001000011001.m2v
vid_file1=F:\Temp\D2VAVS\V04001000011001.m2v
vid_out=1
vaf_out=1
opv_q_factor=20
opv_brate_min=0
opv_brate_max=8712
vbr_bias=25
vbr_pass=1
use_filter=0
filter_val=6
non_linear=1
top_first=0
mpeg1=0
mpeg1_cps=1
qmat_idx=0

[file]
name=F:\Temp\D2VAVS\V04001000011001.avs
frame_first=0
frame_last=9459
encode_first=0
encode_last=9459


Rebuilder.inf

[ILVU]
V0400002001=13330,56712,1,1
V0400003001=13603,57166,1,2
V0400005001=167345,170127,1,1
V0400006001=167901,170731,1,2
V0400008001=207720,211895,1,1
V0400009001=208205,212192,1,2
V0400024001=2569650,2628966,1,1
V0400025001=2570138,2629665,1,2
V0400027001=2743138,2802477,1,1
V0400028001=2743280,2802676,1,2
[Status]
mode=1
MovieOnly=0
Original_Size=3850747
Excluded_Audio_Sub_Size=0
MainVTS=04
VTS_02_SIZE=184194
VTS_03_SIZE=84809
VTS_04_SIZE=2359545
VTS_05_SIZE=338460
VTS_06_SIZE=86137
VTS_07_SIZE=36541
Progress=1
CCEType=3

###

[V0400011]
Last_Sector=677713
[V04001000011001]
SCR=.000
PTS=25200.000
Frame_Rate_Code=3
Pulldown=0
Structure=3
Frames=9459
Playback=9459
First_Sector=533503
Last_Sector=677713
Reduction=47.8
Aspect_Ratio=3
HalfD1=0
Convert16=0
EndPTM=34077600.000
Audio_Sub_Sectors=26394
ILVU=0
Video_Sectors=55881

[jdobbs]

OPV isn't the default for DVD-RB -- not sure about RB-Opt. Please try it with 2-Pass VBR. I don't think OPV is a good idea with ILVU, I'm not even sure it will work at all (at least not correctly) with multiple angles.

I may have to add some code to disable OPV for multiple angled sections.

[SpazzHH]

@ Brashquido
Make sure you have upgraded to the latest(0.21) version of RB-Opt. There have been a few fixes lately.

[FilipeAmadeuO]

Jdobbs:
I´ve been using OPV for ILVU sources and until now, absolutely no problem.
Please do not disable that option on ILVU source.
I´ve done one more today (Hide and Seek) and again is perfect.

[jdobbs]

It's a really bad idea for multiple angles. The two angles have to be very, very close in size and I make some settings in CCE to accomodate it. If you use OPV those settings will not be applied. You probably won't notice it in seamless branching sources, but muliple angles must be very carefully matched. Some techniques even recommend CBR for multiple angles.

Hide and Seek is a seamless branching title. Each of the alternate endings is a part of a different PGC.

[brashquido]

Thanks for the tip SpazzHH, upgraded to 0.21 of RB-Opt ;) .

@jdobbs - Just wondering, if OPV isn't the default then why is it that when I set DVD-RB to use all default settings that RB-Opt shows everything as being OPV when I open the rebuilder.inf file? Until I set it in RB-Opt just now, I have at no stage specified wether to use OPV, VBR or CBR. I must be missing something really basic as I can see no place in DVD-RB itself to specify this, apart form if you select "One pass VBR with analysis".

[FilipeAmadeuO]

OK. You´re right. Multiple angles is diferent from ILVU.
In multiple angles you have to do it with multipass to have the exact same size.
In ILVU that not necessary.

[brashquido]

Just tested the results using only VBR instead of OPV, and the stuttering is still there...

[jdobbs]

How many audio tracks are there? What types (AC3, DTS, etc.)?

[brashquido]

Only 3 audio tracks. English and Fench 5.1, plus an English commentary. I just tried doing a movie only backup with the "No compression (100% video)" option selected from the Mode menu, and the stuttering is still there. Would that suggest something in the rebuild phase if none of the video is touched?

[brashquido]

Just tried doing a movie only backup with DVD-Shrink with no compression, and there is no stutter in the section where there is stutter when backing up with DVD-RB.

[brashquido]

Another thing I noticed was that in DVD-Shrink it recognised the main movie (VTS_04) as being a bit over 4GB, with angle 2 being a bit over 2GB (a total of about 6.5GB). Looking at the rebuilder.inf I posted above it lists VTS_04 as only being a bit over 2GB, with no mention of the 4GB section that DVD-Shrink detected anywhere. Could DVD-RB just be not picking up the multiangle aspect of the movie correctly?

[jptheripper]

shrink transcodes and does not reauthoring, saying you backed it up with shrink is like saying you bought another copy and that doesnt stutter either, it is meaningless.

lack of identification of the vts, on the otherhand, is great troubleshooting

[brashquido]

Keep forgetting about the transcoding thing with DVD-Shrink :rolleyes: ...

[brashquido]

I need to eat my hat there too. Looking again DVD-Shrink recognises VTS_04 (main movie) as two seperate titles of about 5.5GB each. DVD-RB recognises VTS_04 as a single 6GB title.

[HKT3020_1]

I've personally never used this option before but there is a setting in Decrypter, where if I'm reading this correctly should allow you to keep only the first angle(s) of the film.

http://img99.imageshack.us/img99/3015/untitled7uy.gif

[jdobbs]

If you use that option nothing else will work. Decrypter strips the other angles, but doesn't correct the IFO files.

[HKT3020_1]

Is there perhaps another way to work around this, I would really like to strip any other angles other than the ones I intend on using. For instance say The Incredibles R1 NTSC, I've come across problems when encoding it with an earlier build of DVD-RB...RC4 I think it was. To avoid problems during the encoding process what would someone like you recommend?

[brashquido]

Personally I would suggest reporting the bugs to jdobbs so he can nail them out is the best solution. I ALWAYS like to use 100% unaltered rips of the original for my backups (I use ISO exclusively), it's just not worth tainting them for the risk of complicating troubleshooting further down the track.

[blutach]

Is there perhaps another way to work around this, I would really like to strip any other angles other than the ones I intend on using. For instance say The Incredibles R1 NTSC, I've come across problems when encoding it with an earlier build of DVD-RB...RC4 I think it was. To avoid problems during the encoding process what would someone like you recommend?Load the IFO of the VTS up in IfoEdit and click on VobExtras. There's settings there to strip angles.

Regards

[jdobbs]

Is there perhaps another way to work around this, I would really like to strip any other angles other than the ones I intend on using. For instance say The Incredibles R1 NTSC, I've come across problems when encoding it with an earlier build of DVD-RB...RC4 I think it was. To avoid problems during the encoding process what would someone like you recommend?You might try running it through again with "No Compression" -- so it can do the REBUILD with the latest version.

[RaistlinMajere]

I had this problem with this film a few months back (ifoedited it so just angle 1, english 5.1 and english subtitles) and had the stuttering. I thought perhaps it was my sony players fault as it can be a bit picky about discs at times so I didn't think much about it.

Anyway I fixed it simply by demuxing the rebuilders output and re-muxing it with muxman, playback smooth as silk afterwards.

If there is an issue with rb with this disc I'd recommend looking at stage 3 of the process, I can't be certain but I am pretty sure it was done with 0.93 and I stripped all the ilvu out anyways. I must say though I would suggest the problem is down to the film and not rb as this is the only film I have known to do this.

[Plutox]

I have to chip in here and say that I too have a stuttering problem with this film (Region 2) - in the area where the submarine has left port and we see exterior shots of it at sea. Now the sea shots contain a lot of random motion and are therefore tough on the encoder, but this is a problem that I have never seen in over a hundred DVDs processed in much the same way.

My method is not 'pure', but is very well tried and tested. I do the ripping with DVD Shrink (only angle 1 in this instance) eliminate all but the main English audio and backup to hard disc with the Shrink transcoder switched off. Please don't allow the discussion to be sidetracked by my unorthodox method, which is historical really - it goes back before DVD-RB had ILVU support and was generally less flexible than it is now, so I appreciate that my method is now obsolete but like I said, I have successfully copied over a hundred films in this way and this is the first one to have exhibited this problem.

My Shrink rip plays perfectly. The problem is evident when playing back Rebuilder's output (RC 5.1) off the hard disk with WinDVD, or when playing a real disc on my Sony standalone. FWIW the M2Vs sitting in the work path also play back smoothly - obviously without sound.

I have all the files for this job sitting on my hard disk so if Maestro JDobbs needs to look at anything…

[jdobbs]

I have to chip in too. Do me a favor. Just run the DVD through Rebuilder without helping it out with all the other processing. I can't debug what Shrink does when it removes an angle. If it still has the problem -- post again.

To everyone -- it really doesn't help to say it works after running it through Shrink. That's like saying the original worked... Shrink just takes the original and cuts/reduces a few portions out that improve accuracy and then writes it back out. It doesn't have to author or encode at all. There's not a lot that could go wrong. Also, the fact that it plays back doesn't mean it still has integrity... players are very forgiving.

Hell, I could have gone the easy route with the public release "shrinking" engine that was used in ReJig a year ago or the "within-the-compressed-domain" algorithms published in numerous papers just like all the other SuperDuperCopyPlus programs did... but the quality wouldn't be worth a damn except on sources that will almost fit anyway -- just like all of them. But I chose to do it the hard way, which is also the quality way.

I'm sorry -- and I will work on any reported problem... but as I have said before, I can't respond to the results of preprocessed sources that are of unknown and/or suspect integrity.

[brashquido]

I have to chip in here and say that I too have a stuttering problem with this film (Region 2) - in the area where the submarine has left port and we see exterior shots of it at sea. Now the sea shots contain a lot of random motion and are therefore tough on the encoder, but this is a problem that I have never seen in over a hundred DVDs processed in much the same way.

That's the EXACT same spot where I see the stuttering in PowerDVD and on my Pioneer 355! Although, I have not done ANY processing on the DVD source before passing it through DVD-RB. My source is a 100% pure DVD ISO rip, and I've even re-ripped the thing just incase it was somekind of freaky problem with the ISO image.




I have to chip in too. Do me a favor. Just run the DVD through Rebuilder without helping it out with all the other processing. I can't debug what Shrink does when it removes an angle. If it still has the problem -- post again.

To everyone -- it really doesn't help to say it works after running it through Shrink. That's like saying the original worked... Shrink just takes the original and cuts/reduces a few portions out that improve accuracy and then writes it back out. It doesn't have to author or encode at all. There's not a lot that could go wrong. Also, the fact that it plays back doesn't mean it still has integrity... players are very forgiving.

Hell, I could have gone the easy route with the public release "shrinking" engine that was used in ReJig a year ago or the "within-the-compressed-domain" algorithms published in numerous papers just like all the other SuperDuperCopyPlus programs did... but the quality wouldn't be worth a damn except on sources that will almost fit anyway -- just like all of them. But I chose to do it the hard way, which is also the quality way.

I'm sorry -- and I will work on any reported problem... but as I have said before, I can't respond to the results of preprocessed sources that are of unknown and/or suspect integrity.

Sorry for mentioning Shrink, but I am no wizard at this and I have no idea what I should be looking for. I simply forgot that Shrink achieved it's size reduction by cutting corners. I did run K:19 through DVD-RB 5.1 Pro with the video set to no compression, but the stutter issue was still there. I would think this would suggests the problem sits somewhere in the rebuild phase. Just to note though that it seems that both Plutox and I have the exact same stutter issue in the exact same area of the movie. Let me know if there is anything you need to help you nail this one out.

[jptheripper]

whats the bitrate at that point?

[kisav]

I thought I'm the only one who has stuttering problems. Although its a different movie but it's a "plain vanilla" (1 angle + 2ch + 5.1ch sound) and no preprocessing done. Mounted ISO. http://forum.doom9.org/showthread.php?t=98980

[brashquido]

whats the bitrate at that point?

Not sure, but wouldn't the fact that the stutter is there even after backing up with DVD-RB set with the video set to use no compression remove bitrate from the equation?

[mchipk]

I'm doing one pass video and I get stutter on only with DTS or THX, but regular 5.1 audio seems to be fine. The stutter usually occur approximately from middle of the movie till the end.

My solution is rip the first half of the movie with SmartRip, run it through DVD-RB, and do the same for the second half and then join them together with VobEdit and then edit and create new info with IfoEdit for DVD back-up.

This procedure takes longer time, but it works for me. Just make sure to set your SmartRip option to rip maximum size of 4GB when ripping the first and second half of the movie, otherwise you will get a non-seamless joint between vob size of 1GB. Just locate until what part of the movie or cell you want to rip the first half, and use the next cell to begin and rip your second half (you will end up joining two vob's of apprx 2GB + 2.3GB depending the length and size of your movie). Seamless joint and no stuttering, just a perfect movie ;)

[Plutox]

Do me a favor. Just run the DVD through Rebuilder without helping it out…

I'll do as you ask over the weekend and report back.

I'll do a clean rip with Decrypter followed by movie-only processing with Rebuilder. I'll also ask Rebuilder to remove all but the English language AC3 audio.

[jdobbs]

Not sure, but wouldn't the fact that the stutter is there even after backing up with DVD-RB set with the video set to use no compression remove bitrate from the equation?Probably.

[jdobbs]

@brashquido

Could you wrap together the following into zip file and send it to dvd-rb@dvd-rb.com? I'd really like to find out what causes this before I release v1.00 final.

REBUILDER.INI
REBUILDER.INF
REBUILDER.ECL
A LISTING OF THE CONTENTS OF D2VAVS
REBUILDER.LOG
VERSIONS OF CCE, AVISYNTH, and DGDECODE

Also, if you could point out the AVS(s) that contains the point of the stutter(s) it would be very helpful.

Thanks.

[jdobbs]

One other thing. It's a stab in the dark, but could your try adding this line to your REBUILDER.INI file (under [Options]) and then do the REBUILD again?

LAYER_BREAK_REMOVAL=0

[RaistlinMajere]

there is nothing wrong at all with the encoding with this disc, but for some reason the problem seems to be in the muxing at stage 3.

I took the output from that rb created and simply demuxed the streams and remuxed with muxman and the problem was solved so its not the encoding part.
One thing i did notice was that at the various parts the film stuttered the audio was playing a piece of classical music that was very loud and full sounding. (sorry stuck for words to discribe it lol). At the time I remember thinking it was probably due to the audio stream somehow.

[jdobbs]

Hmmm... I don't get it... When I put the audio back into the stream it remains at exactly the same DTS/PTS as it was on the original. If the video was at too high a bitrate it might cause this -- but then muxman would probably reject it...

[HKT3020_1]

I had this problem with this film a few months back (ifoedited it so just angle 1, english 5.1 and english subtitles) and had the stuttering. I thought perhaps it was my sony players fault as it can be a bit picky about discs at times so I didn't think much about it.

Anyway I fixed it simply by demuxing the rebuilders output and re-muxing it with muxman, playback smooth as silk afterwards.

If there is an issue with rb with this disc I'd recommend looking at stage 3 of the process, I can't be certain but I am pretty sure it was done with 0.93 and I stripped all the ilvu out anyways. I must say though I would suggest the problem is down to the film and not rb as this is the only film I have known to do this.

Unfortunately I had this problem too, the film would stuffer completely on certain ilvu scenes. This was even shown while playing it through PowerDVD6, I had encoded that disc about 4 times and RC4 was the last time I took a stab at it. Recently I also had a problem with T2 Extreme Edition DVD where on PowerDVD6 it would play fine but once it got to a disc, my Sony player would stop and give me a C13 error stating the disc was dirty. Tried that movie a few times with suggestions from other members here and there but no avail. Lastly I had a minor problem with Jaws CE where it would pause for about 30 seconds to what I'm guessing is a layer break. This happened with RC5.1 on my backup but plans the original DVD9 fine, this seems to be happening on my Sony DVP NC665P. :angry: Suggestions anyone? :thanks:

[jdobbs]

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.

[Fastolfe]

JDobbs, sorry to bother you with this, but I hope there is no harm in reporting another example.
I am experiencing similar problem with Finding Nemo R2 (French edition) on both my DVD players (Pioneer = freeze + Samsung = strong stutter) but only at one place during the movie, this is after one multi-angle angle section.
I am not a specialist in these matters but I will try to explain as clearly as I can. I can choose to play the DVD either in English either in French at start. When starting in English, I am not noticing any problems with the movie for both the ILVU and muti-angle sections, everything play OK. When I start the DVD in French, the ILVU sections seem to play fine (both entering and exiting ILVU) but not for the multi-angle section (at least the first one encoutered): entering the multi-angle is OK but it freezes on exit (Pioneer). Of course it plays fine in PowerDVD.
The DVD is ISO, no pre-processes, using RB1 rc5.1 with CCE SP v2.70.02.01 with 2 passes, AVS 2.55, DGDecode from RB zip file and the only thing removed is the audio DTS.
The only fix from a player standpoint is Fast Forwarding just before exiting the multi-angle section.
Now, I can send the RB files if you think that can be of any assistance.

What is puzzling me is that I tried this one a long time ago with RB v0.9x and I do not recall having that problem (will have to rerun it I guess to be sure, with 0.94 preferrably?). But of course the video quality was very bad since half of this DVD9 is ILVU.

FFS

PS. just to point out that this is the only issue I have experienced in many months, I think it goes back to RB v0.7x (an eternity ;) )

[Fastolfe]

Just to build on my previous post, just did rerun Finding Nemo with the same options as for RB v1.0rc5.1 but this time with RB Free v0.94 (just replaced the exe file). At least for me and this movie, the freeze/stutter is gone, perfectly clean. So I do not what is going on :confused: but I am wondering if I could just rebuild the 0.94 encode with 1rc5.1 and vice-versa to check the results. Would this make sense to exclude differences in the rebuild phase between both RB?

Thanks

[jdobbs]

I'd be interested in how it works with the LAYER_BREAK_REMOVAL=0 option I mentioned earlier. brashquito sent me some information for "K-19 - The Widowmaker", and I noticed that at the beginning of all the cells the System Reference Clock gets reset to 0. It's possible the more aggressive layer_break removal code is causing this.

Interestingly enough, I've always refused to add this code in the past when asked because I was worried that it was too risky -- I'd like to see if I was a dumb-ass for putting it in anyway.

[jdobbs]

Just to build on my previous post, just did rerun Finding Nemo with the same options as for RB v1.0rc5.1 but this time with RB Free v0.94 (just replaced the exe file). At least for me and this movie, the freeze/stutter is gone, perfectly clean. So I do not what is going on :confused: but I am wondering if I could just rebuild the 0.94 encode with 1rc5.1 and vice-versa to check the results. Would this make sense to exclude differences in the rebuild phase between both RB?

Thanks You can't rebuilder the RC5.1 output with 0.94 -- it will choke on it.

Just a note too... v0.94 does not reencode the ILVU -- it just copies it intact.

[Plutox]

Do me a favor. Just run the DVD through Rebuilder without helping it out with all the other processing. I can't debug what Shrink does when it removes an angle. If it still has the problem -- post again.

I have now done exactly as you asked and the problem persists unchanged, in exactly the same place. What logs/data would you like to see to investigate further?

[jdobbs]

I'm looking at some files brashquito sent me to see if I can find anything...

[jdobbs]

@plutox

Just as a test... do you think you could try something? Assuming you still have the files on your hard drive:

1. Copy the section for segment 10 or VTS_04 from the REBUILDER.ECL. It starts at the part that looks like this:

[item]
title=V04001000011001
aud_out=0
...

and ends at the line just before the next "[item]" line.

2. Paste it over the existing contents of the ITEM.ECL file (starting at "[item]")

3. While you have ITEM.ECL opened change this line:

vbr_brate_max=8712

to this:

vbr_brate_max=5000

4. Then load ITEM.ECL directly into CCE and encode it.

5. REBUILD and report whether the stutter is still there.

Thanks.

[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.