Bigtime undersize, ILVU in extras!!

[knife]

I'm using latest RB-PRO RC5.1 installer together with CCE.
I have never before experienced any undersize problems and this is also my first ILVU disc.

Sp Kids 3D
Main movie in 2 versions, 2D and 3D, VTS_01, PGC 1 and 2
Extras with one part ILVU
All extras in VTS_02
Ripped with DVDDecryptor
Untoched soure

Senario 1:
Full backup with CCE 2 Pass VBR
No steal space from extras
Everything went fine, ILVU working, disc size as expected (4*688*879*616 byte)
Size VTS_02_1.vob (extras): 631*185*408 byte


Senario 2:
Blanked the 3D version with segment viewer.
CCE 2 Pass VBR
Default setting on Save space from extras (can't remember but I never touched the setting)
Encoding went fine but the result in undersized, disc size (3*784*126*464 byte)
Size VTS_02 (extras): 631*185*408 byte
Note: Extras VTS_02 has exactly the same size as in the full backup.

Senario 3:
Blanked the 3D version with segment viewer.
CCE 2 Pass VBR
50% steal space from extras (max)
Encoding went fine but the result in undersized, disc size (3*984*293*888 byte)
Size VTS_02 (extras): 670*187*520
Note: Extras VTS_02 is bigger but it should be smaller, I choosed o steel more space from extras in this senario.


Conclusion: The saved space from blanking when the disc has ILVU is not reallocated.

Any wild ideas about how I could resolve this issue is welcome.

//Knife

[jdobbs]

My guess is that you are reaching the maximum quality level with CCE and it refuses to throw any more bits at the movie (because it wouldn't be improved by it).

[knife]

Some sizes from the project:
The source DVD ripped to HD
Extras total size: 1261MB
3D main movie: 3123MB
2D main movie: 3120MB

2005-03-12 20:48 12 288 VIDEO_TS.BUP
2005-03-12 20:49 12 288 VIDEO_TS.IFO
2005-03-12 20:49 8 183 808 VIDEO_TS.VOB
2005-03-12 20:49 102 400 VTS_01_0.BUP
2005-03-12 20:49 102 400 VTS_01_0.IFO
2005-03-12 20:53 471 699 456 VTS_01_0.VOB
2005-03-12 21:02 1 073 709 056 VTS_01_1.VOB
2005-03-12 21:07 1 073 709 056 VTS_01_2.VOB
2005-03-12 21:10 1 073 709 056 VTS_01_3.VOB
2005-03-12 21:13 1 073 709 056 VTS_01_4.VOB
2005-03-12 21:16 1 073 709 056 VTS_01_5.VOB
2005-03-12 21:20 1 073 709 056 VTS_01_6.VOB
2005-03-12 21:21 116 447 232 VTS_01_7.VOB
2005-03-12 21:21 53 248 VTS_02_0.BUP
2005-03-12 21:21 53 248 VTS_02_0.IFO
2005-03-12 21:21 10 240 VTS_02_0.VOB
2005-03-12 21:26 1 073 709 056 VTS_02_1.VOB
2005-03-12 21:27 249 176 064 VTS_02_2.VOB
18 fil(er) 8 361 816 064 byte

Senario 1:
2005-08-17 07:48 12 288 VIDEO_TS.BUP
2005-08-17 07:48 12 288 VIDEO_TS.IFO
2005-08-17 07:19 8 183 808 VIDEO_TS.VOB
2005-08-17 07:48 124 928 VTS_01_0.BUP
2005-08-17 07:48 124 928 VTS_01_0.IFO
2005-08-17 07:19 471 699 456 VTS_01_0.VOB
2005-08-17 07:31 1 073 739 776 VTS_01_1.VOB
2005-08-17 07:41 1 073 739 776 VTS_01_2.VOB
2005-08-17 07:43 1 073 739 776 VTS_01_3.VOB
2005-08-17 07:44 356 179 968 VTS_01_4.VOB
2005-08-17 07:48 63 488 VTS_02_0.BUP
2005-08-17 07:48 63 488 VTS_02_0.IFO
2005-08-17 07:19 10 240 VTS_02_0.VOB
2005-08-17 07:48 631 185 408 VTS_02_1.VOB
14 fil(er) 4 688 879 616 byte

Senario 2:
Note the size VTS_02_1.vob with the extras.
2005-08-18 19:12 12 288 VIDEO_TS.BUP
2005-08-18 19:12 12 288 VIDEO_TS.IFO
2005-08-18 18:53 8 183 808 VIDEO_TS.VOB
2005-08-18 19:12 102 400 VTS_01_0.BUP
2005-08-18 19:12 102 400 VTS_01_0.IFO
2005-08-18 18:53 471 699 456 VTS_01_0.VOB
2005-08-18 19:05 1 073 739 776 VTS_01_1.VOB
2005-08-18 19:07 1 073 739 776 VTS_01_2.VOB
2005-08-18 19:08 525 211 648 VTS_01_3.VOB
2005-08-18 19:12 63 488 VTS_02_0.BUP
2005-08-18 19:12 63 488 VTS_02_0.IFO
2005-08-18 18:53 10 240 VTS_02_0.VOB
2005-08-18 19:12 631 185 408 VTS_02_1.VOB
13 fil(er) 3 784 126 464 byte

Senario 3:
Note: This is with max steel space, and extras ends up bigger.
2005-08-19 14:08 12 288 VIDEO_TS.BUP
2005-08-19 14:08 12 288 VIDEO_TS.IFO
2005-08-19 13:48 8 183 808 VIDEO_TS.VOB
2005-08-19 14:08 102 400 VTS_01_0.BUP
2005-08-19 14:08 102 400 VTS_01_0.IFO
2005-08-19 13:48 471 699 456 VTS_01_0.VOB
2005-08-19 14:01 1 073 739 776 VTS_01_1.VOB
2005-08-19 14:02 1 073 739 776 VTS_01_2.VOB
2005-08-19 14:03 686 376 960 VTS_01_3.VOB
2005-08-19 14:08 63 488 VTS_02_0.BUP
2005-08-19 14:08 63 488 VTS_02_0.IFO
2005-08-19 13:48 10 240 VTS_02_0.VOB
2005-08-19 14:08 670 187 520 VTS_02_1.VOB
13 fil(er) 3 984 293 888 byte

I'm not touching the extras at all, no blanking on the extras.
The quality of the reencoded extras is really bad, blocking etc.

//Joakim

[jdobbs]

That's not exactly what I meant. What I think is happening is that you are reaching the maximum quality on the movie... then in scenario 3 you are attempting to throw even more bits at it after it has reached its maximum quality/useful bitrate.

There's something else going on here. Look at scenario three and you will see that the main VTS is larger than scenario 2 -- but VTS 02 got larger also... where did it pull those extra bits?

I can't help but feel that there are some details you are leaving out as to how you are doing this. Are you doing this with OPV, for example? Also it looks like it would come really close to fitting on the disc without compressing at all.

[knife]

Well you are right that it almost fits the disc, it's 200mb to big.
Note: I never use OPV. All the above senarios are done completely with RB, no RB-OPT or vobblanker etc.
The 3D and 2D version are in the same VTS but in separate PGC, 3D - PGC_1 - 3100MB and 2D - PGC_2 - 3120MB) There are two more PGC, small ones 11Mb and 10kb only.

In the long run what I'd like to do is to compress the extras from 1230MB to 1000Mb and blank the 3D version.
First I tried to blank the 3D version using segment viewer, using RB-Opt 20 to set the compression of main movie to 99.99% and then when finished use the original VTS_01 set. It did not work, the extras (VTS_02) ended up at 632MB, heavily compressed.

Then I tried to do it in two steps - blank the 3D version in "no compression" mode of RB and then use the RB-OPT and replace, but I found that it can't be done. RB only blanks the sound in "no compression" mode.

During the experimenting I found that there is something strange going on with the extras which contains small part of ILVU. RB comresses (with CCE VBR) the extras to half the original size with crappy result and DVD-undersize.

A possible cause:
When I blank the 3D version RB states: "Recovered 1643,63MB"
If RB belives that only 1643,63MB is saved by blanking 3D version (the size of the 3D version in vobblanker is about 3100MB) it is more likely that the Extras VTS_02 will suffer and the result will be a undersized. Extras compressed heavily because RB thinks that only 1643Mb is blanked, new disc size to compress is then 7966-1643 = 6323MB instead of 7966-3100=4866MB.

Some observation:
- The reduction for the extras always ends up to be around 50%, doesen't matter what I blank.
-In segment viewer the feature bitrate for every cell in the Extras is 5300 for the original. In the rebuilder.ecl the extras has bitrates around vbr_brate_avg=500 - 1600 both before and after blanking of movie.
- I just did a run where I blanked both the 2D and 3D version , segment viewer states "recovered: 3532MB". Still the extras end up with 50% compression with bitrates between 500 and 1600. Size of VTS_02_1.vob now 639MB and total disc size is 1095MB where 450mb is untouched menu. Of all cases this case should leave the extras alomst at the same size as original.

//Joakim

[jdobbs]

Could you send the IFOs for this DVD to me at DVD-RB@DVD-RB.COM? I'd like to see what DVD-RB is seeing here.

[knife]

IFO's are on the way.

//Joakim

[knife]

Out of curiosity I tried "Movie And Menus Only" on the original, untouched source of this movie.
The result was Error 006 - framecount....
Last recorded in the log is:
- Processing VTS_02
- Reading/processing TMAP table...
- Rebuilding seg 0 VOBID 1 CELLID 1
- Rebuilding seg 1 VOBID 1 CELLID 2
and then it stopped. Note: VTS_02 is the extras which had ILVU

//Joakim

[knife]

I solved the error0006 by correcting the size of the .flg files.

I did some more investigations regarding the undersizing, only investigating the Extras.
Checking the bitrates with "bitrate viewer", playback on DVD-player and confirming with sectorlength versus time from .ifo I found that they correlate.
BUT if I do the prepare stage in RB and look at the bitares in "sector viewer" these bitrates are much smaller (half) than those reported in "bitrate viewer". I also opend up RB_OPT 0.21 and checked the bitrates from the rebuilder.inf (turning the slider to 100%) those bitrates are the same as shown in RB, i.e they are smaller (half) than those reported in bitrate viewer.
example:



Cell 1 of VTS_PGC_9
from IFOEDIT:

[Ch 01] [Pg 01] [Cell 01] [V/C Id: 11/ 1] : time: 00:09:50.04 / 25 fps [Pos: 00:09:50.04] [Frames: 14754] SP/ILVU/DISC/SA:[ no/ no/yes/yes]

[00000004] Playback time (BCD) 610624 [00095140]
Playback time (hh:mm:ss.frame) 00:09:51.00 / 25 fps
[00000008] Prohibited user operations 0 [00000000]
[0000000c] Audio stream 1 status 32768 [8000]
Audio stream 1 uses stream nr.: 0
[0000001c] Sub-picture stream 1 status -2147483648 [80000000]
Sub-picture stream 1 uses stream nr.(4:3): 0
[00000020] Sub-picture stream 2 status -2130706432 [81000000]
Sub-picture stream 2 uses stream nr.(4:3): 1
[00000024] Sub-picture stream 3 status -2113929216 [82000000]
Sub-picture stream 3 uses stream nr.(4:3): 2

PGC Program Map:
[000000fc] Program_1: Entry cell number 1 [01]
[00000102] Cell_1: playback time (BCD) 610372 [00095044]
playback time (hh:mm:ss.frame) 00:09:50.04 / 25 fps
[00000106] Cell_1: entry point sector 527366 [00080c06]
[0000010a] Cell_1: first ILVU VOBU end sector 0 [00000000]
[0000010e] Cell_1: start sector of last VOBU 645839 [0009dacf]
[00000112] Cell_1: last sector of this cell 645875 [0009daf3]


Using
Cell_1: entry point sector 527366
Cell_1: last sector of this cell 645875
playback time (hh:mm:ss.frame) 00:09:50.04 / 25 fps = 590sec
I get 3212kb/s (645875-527366 =118509, 118509*2048*8/(590*1024)

In RB-OPT 0.21 with reduction 99.99% it says: bitrate 1524
This is the same bitrate reported in "Segment viewer" in RB.

If I calulate backwards from 1524kb/S I get: 56197,5 sectors
To correlate with rebuilder.inf I use the reduction setting i for this cell and get:
56197,5 * 0.437 = 24558 which is close to Video_Sectors=23975.

In rebuilder.inf I have:
Frames=14754
Reduction=43,7
First_Sector=527366
Last_Sector=645876
Audio_Sub_Sectors=7786
Video_Sectors=23975

My guess here is that the number of video_packs (Video_Sectors) is wrong.
I really would like to check the number of video_packs, audio_packs, sub_packs, nav_packs. Anyone that can recommend a stable software to do that.

//Knife

[jdobbs]

The bitrates in the INF file are the rates at which they will be encoded in order to fit...

You also have to be very careful if working in NTSC, as these bitrates are determined based upon a common denominator of 23.976fps. It would be considerably different if you check the M2V file and the final VOB.

The number of video packs is determined by the size of the encoded output. I can assure you they are correct -- but of course they won't match the input!

Cell_1: entry point sector 527366
Cell_1: last sector of this cell 645875
playback time (hh:mm:ss.frame) 00:09:50.04 / 25 fps = 590sec
I get 3212kb/s (645875-527366 =118509, 118509*2048*8/(590*1024)Where do you account for the audio, NAVPACK, and subpicture sectors?