Consistently too small output

[FredThompson]

I've been using RB-Pro 1.01 with ProCoder on a 7.3G source. The output is consistently 3.22G which is about 1G too small. When I run as 3 phases and check the target output size with RB-Opt after phase 1, it appears to have the proper target size of ~4.3G. All other encodes with this setting have run just fine.

What might cause this kind of drastic undersize result?

[jdobbs]

What encoder are you using and is it OPV? Some encoders are more accurate than other -- and OPV always results in variance.

[FredThompson]

ProCoder 2.0, no OPV. Its' done just fine on everything else, including other discs from this set.

[wmansir]

Have you check the output to make sure it is complete and error free?

When I see that kind of undersizing the first thing I check is the video to see if there was an .avs script error, which got encoded instead of the actual video. The error messages don't take many bits, so the encoder 'undersizes' the disc because it can't reach the specified bitrate.

Is there anything unusual about this disc? Is it a regular movie DVD, or a concert, anime or something odd? Does it contain angles?

[FredThompson]

Interesting. I hadn't thought of that. DVDShrink shows there are, indeed, 2 massively undersized program segments. They're both about 25 minutes but are encoded to a total of about 35M each. All that appears to be present is audio. PGCEdit won't preview the encoded results for those segments.

No special angles as far as I can tell. The source is interlaced TV.

Maybe something in the video streams caused DGDecode to puke. I'll try the Nan version when the attachment is approved.

Is there a way to manually initiate encoding of specific portions? If so, maybe I could find the problems then run phase 3 to rebuild.

[Rippraff]

Any Preprocessing? Are there any files beside .ifo, .bup and .vob in your source folder?
Maybe you can post the log file and rebuilder.ini as well.

Cu Rippraff

[FredThompson]

Ah, HA!

Look at this from the log during phase III:

- Rebuilding seg 11 VOBID 7 CELLID 1
- Possible dropped frame(s) [ 36800 ] noted in this segment, continuing...
- Updating NAVPACKS for VOBID_07
- Rebuilding seg 12 VOBID 8 CELLID 1
- Possible dropped frame(s) [ 37032 ] noted in this segment, continuing...
- Updating NAVPACKS for VOBID_08

Everything else looks normal. There's nothing odd in the ini at all. I just used ProCoder and the extras configuration is set to "steal" 0%. That's irrelevant, anyhow, as this is in the main source, not the extras.

This particular DVD was made with old tape source. Maybe the source has a slight glitch.

[Rippraff]

That's why I always recommend to have a look at the log file if the output is undersized. ;)
Seems Procoder crashed during the encode phase, there are more than 50 minutes missing.
This can be caused by hardware problems, overclocked machine for example.

Cu Rippraff

[FredThompson]

No overclocking. The log mentions a dropped frame. I wonder if the old tape source which was mastered resulted in a glitch, the disc is damaged or something like that. I wonder what the numbers represent. Are they absolute positions in the source stream? If so, it should be easy enough to modify those particular scripts to duplicate a field, as needed, from either direction in the stream. If that works, it would be nice to encode just those 2 problem segments rather than the entire set given the other parts are fine.

--

Well, nuts. It looks like AviSynth is crashing on these 2 segments. MPC and VirtualDub-MPEG2 both hang when they're used to load the scripts. Guess I'll have to wait for the SSE Nan build to see if the more robust decoding routines can handle this properly.

[FredThompson]

Looks like this IS a dgdecode 1.1.0 problem. Using DGIndex 1.4.5 to create a different D2V file and modifying the scripts created by DVD-RB Pro to load it with the matching DGDecode yields scripts which load properly into VirtualDub-MPEG2 and MPC. FWIW, this source is PAL made from an NTSC TV original.

How does DVD-RB Pro control the encode process? If I edit rebuilder.inf to include just the 2 problem segments, run phase II (encoding), restore the original rebuilder.inf then run phase III, will that yield a "proper" result?

Here are the "before" and "after" versions of the scripts and inf file. Do they look correct?

[Rippraff]

Hi Fred,
I wonder what the numbers represent. Are they absolute positions in the source stream?
I'm not completely sure, which numbers you mean. The first one tells you something about the location and the corresponding avs file which you've probably found now.
The second tells you, that your encoder crashed and the result is 36,800 frames to short.
And yes with trim inside the avs they are absolute positions inside a VTS.

How does DVD-RB Pro control the encode process? If I edit rebuilder.inf to include just the 2 problem segments, run phase II (encoding), restore the original rebuilder.inf then run phase III, will that yield a "proper" result?
Okay, I'll tell you how I solve this problem with dropped frames and CCE. I'm not sure if it works with Procoder too and on the other hand if I understand you right your dealing with two different dgdecode versions. So I'm not sure if they work together and your don't get new problems during rebuild.

Leave everything untouched in your d2vavs folder except your two modified avs scripts.
Open Rebuilder.ecl with an editor, delete everything down to
[item]
title=V11000000007001
keep the lines behind [file] as well.
Delete everything else up to the end and save it under a new name, reencode1.ecl.

Do the same with the [item] that corresponds with seg 12 VOBID 8 CELLID 1.
Delete everything else up to the end and save it under a new name, reencode2.ecl.

Open Eclpro and load your new 1ecl file => Convert, redo this 2ecl, when this is done, run Rebuild within DVD-RB.

I'm not sure if it works in your case but give it a try.

Cu Rippraff

[FredThompson]

OK, I'll give it a shot.

This also looks like it might be part of the answer to how to trim inside segments to remove those really nasty segments which aren't standalone and easily removed with PGCEdit.

[CrisCr0ss]

I have a similar problem except im inputing Alien dvd9 and getting an output of 2.5 gigs... Im using Rokas installer for CCE SP.

[jdobbs]

@FredThompson

What version of AVISYNTH are you using? I've never experienced a problem with DGDECODE 1.1.0 with AVISYNTH 2.5.5.

[FredThompson]

I've used both 2.5.5 and 2.5.6 (now pulled from distribution.) It's not an AviSynth issue, it's a DGDecode issue. 1.4.5 works perfectly, 1.1.0 original fails on 2 segments, NaN's 1.1.0 fails on 1 of those 2 segments. NaN asked me to send the segments for testing but they're too large for email and I haven't gotten a reply to my request for a hard mailing address. If you want to PM me, I'll send you some source which makes 1.1.0 puke. It won't be the whole disc, just the problem VOBs.

Another thing to consider is the growth of DVR recordings. Streamed MPEG2 uses some flags that DVD doesn't use. That's what a lot of the builds after 1.1.0 were about, flags to repeat fields, swap dominance, etc. I'd imagine there will be more and more people doing what I do, making homemade IFO sets from recordings. Running those through DVD-RB would be a way to fix oversize issues and enhance compatibility by changing the MPEG2 from stream-optimized to navigation-optimized.

It's also possible to make IFO sets from HD MPEG2 then run them through DVD-RB to have a DVD structure with oversized video or use a resizing script to make an SD version. You can run into similar issues with decoding stream-optimized source there, too.

[jdobbs]

Was the source that caused this problem from a commercial DVD or one that was created?

[FredThompson]

Disc 2 of the 3-disc set WWE Wrestling Stars of the '80s, the PAL release, commercial.