Undersizing when forced re-encoding

[Boulder]

I just ran into a situation in which DVD-RB undersizes when I force re-encoding. The original DVD folder is 4.12GB and DVD-RB created folder is 4.18GB. It's not saturation, but I think it may have something to do with restricting the average bitrates - the DVD I'm trying to process is from my DVB captures in which the average and maximum bitrates are quite close to each other.

Is there anything that can be done to fix this?

EDIT: Here's the log:
[21:39:41] One Click encoding activated...
-----------------
[21:39:45] Phase I, PREPARATION started.
- DVD-RB v1.26.5
- AVISYNTH 2.5.7.0
- HC v0.21.0.0 encoder selected
- AVS Filters are enabled.
- Source: TMPGENC DVD
- VTS_01: 297 515 sectors.
-- Scanning and writing .D2V & .AVS files
-- Embedded null records found
-- Processed 35 842 frames.
-- Building .AVS and .ECL files
- VTS_02: 286 666 sectors.
-- Scanning and writing .D2V & .AVS files
-- Embedded null records found
-- Processed 34 654 frames.
-- Building .AVS and .ECL files
- VTS_03: 263 043 sectors.
-- Scanning and writing .D2V & .AVS files
-- Embedded null records found
-- Processed 35 626 frames.
-- Building .AVS and .ECL files
- VTS_04: 260 437 sectors.
-- Scanning and writing .D2V & .AVS files
-- Embedded null records found
-- Processed 35 026 frames.
-- Building .AVS and .ECL files
- VTS_05: 274 615 sectors.
-- Scanning and writing .D2V & .AVS files
-- Embedded null records found
-- Processed 35 626 frames.
-- Building .AVS and .ECL files
- VTS_06: 276 504 sectors.
-- Scanning and writing .D2V & .AVS files
-- Embedded null records found
-- Processed 36 068 frames.
-- Building .AVS and .ECL files
- VTS_07: 267 056 sectors.
-- Scanning and writing .D2V & .AVS files
-- Embedded null records found
-- Processed 35 480 frames.
-- Building .AVS and .ECL files
- VTS_08: 234 612 sectors.
-- Scanning and writing .D2V & .AVS files
-- Embedded null records found
-- Processed 35 626 frames.
-- Building .AVS and .ECL files
- Reduction Level for DVD-5: 100,0%
- Overall Bitrate : 2 847Kbs
- Space for Video : 4 144 692KB
- HIGH/LOW/TYPICAL Bitrates: 3 150/2 429/2 847 Kbs
-- FEATURE does not require reencoding.
[21:46:38] Phase I, PREPARATION completed in 7 minutes.
[21:46:38] Phase II ENCODING started
- Creating M2V for VTS_01 segment 0
- Creating M2V for VTS_02 segment 0
- Creating M2V for VTS_03 segment 0
- Creating M2V for VTS_04 segment 0
- Creating M2V for VTS_04 segment 1
- Creating M2V for VTS_05 segment 0
- Creating M2V for VTS_06 segment 0
- Creating M2V for VTS_07 segment 0
- Creating M2V for VTS_08 segment 0
[02:41:19] Phase II ENCODING completed in 295 minutes.
[05:19:42] Phase III, REBUILD started.
- Copying IFO, BUP, and unaltered files...
- Processing VTS_01
- Reading/processing TMAP table...
- Rebuilding seg 0 VOBID 1 CELLID 1
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_01_0.IFO
- Updating TMAP table...
- Processing VTS_02
- Reading/processing TMAP table...
- Rebuilding seg 0 VOBID 1 CELLID 1
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_02_0.IFO
- Updating TMAP table...
- Processing VTS_03
- Reading/processing TMAP table...
- Rebuilding seg 0 VOBID 1 CELLID 1
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_03_0.IFO
- Updating TMAP table...
- Processing VTS_04
- Reading/processing TMAP table...
- Rebuilding seg 0 VOBID 1 CELLID 1
- Rebuilding seg 1 VOBID 1 CELLID 2
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_04_0.IFO
- Updating TMAP table...
- Processing VTS_05
- Reading/processing TMAP table...
- Rebuilding seg 0 VOBID 1 CELLID 1
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_05_0.IFO
- Updating TMAP table...
- Processing VTS_06
- Reading/processing TMAP table...
- Rebuilding seg 0 VOBID 1 CELLID 1
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_06_0.IFO
- Updating TMAP table...
- Processing VTS_07
- Reading/processing TMAP table...
- Rebuilding seg 0 VOBID 1 CELLID 1
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_07_0.IFO
- Updating TMAP table...
- Processing VTS_08
- Reading/processing TMAP table...
- Rebuilding seg 0 VOBID 1 CELLID 1
- Updating NAVPACKS for VOBID_01
- Updated VTS_C_ADT.
- Updated VTS_VOBU_ADMAP.
- Updated IFO: VTS_08_0.IFO
- Updating TMAP table...
- Correcting VTS Sectors...
[05:33:42] Phase III, REBUILD completed in 14 minutes.

Done.
[05:33:42] PREPARE/ENCODE/REBUILD completed in 474 min.

[jdobbs]

My first guess would have been encoder saturation. The average bitrates shouldn't be restricted, but the peak values are for timing reasons. My next recommendation would have been to try "DISABLE_DYNAMIC_PEAK=1" in the "[Options]" area (I would never leave it there permanently, though). But when I look in your ECL file, it appears the maximum bitrate is always set to 8500.

[Boulder]

Dynamic peaks are already disabled..

It's not encoder saturation - the average quants are 8-10. Something does go wrong in the maths.. I think I'll try to calculate those manually and see what comes out (it's quick because there's 8 VTSs and seven of them has one cell and one VTS has two). The audio track for every VTS is 224kbps MP2.

[Sharc]

What about avisynth 2.5.6 vs 2.5.7? I remember there had been sizing issues some time ago with 2.5.7.

[Rippraff]

The original DVD folder is 4.12GB and DVD-RB created folder is 4.18GB.
Sorry, if I didn't get it, but if RB output folder ist bigger than your source folder why is this an example for undersizing :confused:

Cu Rippraff

[Boulder]

What about avisynth 2.5.6 vs 2.5.7? I remember there had been sizing issues some time ago with 2.5.7.I have no problems when the source size is larger than a DVD-5 disc.Sorry, if I didn't get it, but if RB output folder ist bigger than your source folder why is this an example for undersizingThe target size is supposed to be close to 4.37GB so it is undersizing. I do need all the bits for obvious reasons, sharpening takes all it can get.

I'm going to try a professionally authored "smaller-than-DVD5" DVD and see what comes out. Maybe it's TMPGEnc DVD Author's muxing engine playing tricks on DVD-RB (those embedded null records, what are they?)

[Rippraff]

The target size is supposed to be close to 4.37GB so it is undersizing.
As far as I know RB prevents the output to be bigger than the source except if you use bitrate redistribution.
But I don't have that much experiences with small sources as I usually backup DVD-9 discs.
(those embedded null records, what are they?)
Sectors that are completely filled with zeros.

Cu Rippraff

[Boulder]

I recently asked jdobbs and he said that when the source is smaller than a DVD-5, the target will still be adjusted to whatever is set in the ini file.

[~bT~]

I've done this a few times and the final folder is always less than 4.37GB. Usually just a few MB's more than the original.

[Boulder]

I tried working on a professionally authored DVD this time.

The source : 3038MB
The result : 3073MB

So it looks like the maths go wrong somewhere.

[jdobbs]

Just rememberd something. You might want to try setting "OVERRIDE_BITRATE_CHECK=1" in the "[Options]" area. Unfortunately, though, it raises the likelihood of playback stutter (because of audio integration) when there is significant upward movement in bitrate, so I wouldn't leave it set.

It should be ok for the differences you're showing, though.

[Boulder]

Thanks, I'll give it a go when I get back to that project :) My settings should be OK for my purposes, I've done numerous DVDs with max video bitrate 8500kbps and 192-448kbps audio bitrate and using MuxMan to author, no problems observed.

[jdobbs]

The stutter is related to trying to keep the existing audio's timing characteristics. Normally, though, it is associated with higher-level bitrate changes.

[Boulder]

Using this option, I no more get undersizing. Thanks :)

By the way, how does the situation differ from regular encodes in which the bitrate may vary rather quickly from the minimum to the maximum?

[jdobbs]

That kind of increase is ok -- because its variable. The main problem is when you have a consistently higher average bitrate than the original -- as over time it can lead to buffer overruns when used with the original audio's timing. I could get around it by remuxing the audio from scratch -- but it's just easier this way.