RB-Opt v0.23 BETA a tool to change titles bitrate, CCE parameters and AVS scripts.

[robot1]

It's coded in few nights... so it still has bugs (like every beta...)
It should work with every encoder supported by DVD-RB.

Sorry for my english... it's not my mother language.

RB-Opt is an addon for DVD-RB (0.4x-1.x free and PRO)
It allows the user to select different bitrates for every Title in a DVD to process by DVD-RB. For example, backing up a DVD you may want to lower the bitrates for the extras, leaving more room to the film. It works even for extras in the same VTS of the film (ex. Trailers, deleted scenes...)
RB-Opt allows to change also CCE parameters and .avs scripts, to use your custom setup for backup.
Since v0.13 RB-Opt supports OPV mode: thanks to SansGrip for the coding.

Latest version:
RB-Opt v0.38 beta (http://forum.gleitz.info/attachment.php?attachmentid=91918&d=1203877329) (mirror by Doom9.de)


Previous versions:
RB-Opt v0.37 beta (http://www.jdobbs.net/Freeware/RB-Optv0.37.zip) (mirror by jdobbs)
RB-Opt v0.33 beta (http://www.savefile.com/files/843117)
RB-Opt v0.29 beta (http://www.savefile.com/files/801164)

Usage:
Put DVD-RB in "3 click mode", and run the "Prepare" stage.
Now run RB-Opt, and open the REBUILDER.INF created by DBD-RB.
RB-Opt shows the default bitrate used for every title in the "Encode" stage.
Find (using preview) the Vob-IDs of the film, and link them (mandatory to have the best results).
Select the title you want to compress more/less, and input your custom bitrate.
The program will calculate the new bitrate for the titles labeled as "Auto".
It's just like DVDShrink and other one-click apps do ... in a less graphical way :-(
Now you can tweak end credits cell, initial cell, or use "expert settings" to tweak any CCE parameters, or to apply an avisynth filter.
For every title you can select if it will be encoded as VBR or OPV. For OPV titles the program will run a prediction step to find the right Q factor, unless you select a custom Q to override prediction.
After saving the changes, you can start the encoding stage in DVD-RB

The bitrate is always calculated cell by cell: if in DVD-RB you selected "Dynamically Assign Cell Bitrates", the resultant Cell Bitrates will be still proportional to the original ones.

Avisynth editing allows to insert a filter in every .avs of a Vob-ID, and uses "favourite filters" for faster editing. It allows to preview the cell, to control the filter behaviour.
You can change these CCE parameters, for every Vob-ID:
- Number of passes
- DC Precision
- Gop Length
- Quantizer Characteristics
- Bias
- Min/Max bitrate for VBR
- Matrices
- CCE internal Filters


Mich

Edit:
Updated to v0.38 beta.

For german speaking people, here is the RB-Opt page (http://forum.gleitz.info/showthread.php?t=13041) on german doom9 board.

[jdobbs]

Wow. Between this and RB Server Farms... we're hitting things I never even imagined. Honestly, though, the reason 3 Click mode exists and I'm openly explaining what all the parameters are is to support creativity in how they are used.

[Joergen]

Yeah we love DVD-RB so much we cant wait for you to add all the features and people beaver away on their own :)

Nice job robot1, I dont have any new stuff to encode and I'm even yet to try the half-d1-bitrate option but I'll test your tool on something in a few days. Seems like a sound idea.

[robw]

great robot1

DVD-RB is absolutely great but I'm still having trouble with the run-time error 9. From what I've read in the forum it seems to be related to the 1/2 D1 & 1/2 space option. I am definitely trying to use that option. I was about to try again with the option turned off when I noticed your program to tweak the avs file.

Well this seems like exactly the thing I've been waiting for and I am going to give it a try. Will let you know.

By the way, your interface looks very nice! Good start on a really outstanding feature.

[robot1]

It's only a start. I hope to post tonight a newer version (with less bugs...)

@robw
You could try to enable half D1, without half bitrate, and select the bitrate with RB-Opt.
Post your results...

[robw]

Originally posted by robot1
It's only a start. I hope to post tonight a newer version (with less bugs...)

@robw
You could try to enable half D1, without half bitrate, and select the bitrate with RB-Opt.
Post your results...

Wonderful. I'm very excited about giving this a try. I'll do it tonight and check the board before I do to see if you've updated the file.

[gopalkk]

What i mean is, should the calculations of bitrates be based on
resolutions as well so the user can decide in this tool if its
good to go with either half d1 or less bitrate or both in this
level?

This is just the begining of this tool.
I feel DVD-RB should concentrate on doing things accurately and
parameterising all actions it takes (it does this already mostly).

Then this tool (once clubbed with server farm) will create
the control features of DVD-RB.

All my DVDs has 20% used in Menus and this tool will help me
release more from the menus.

Thanks for your efforts

[wmansir]

Good job, Mich. I think tools like this are an excellent way to exploit the openness of DVD-RB's process.

People may have missed it, but a similar tool is in development, but it was buried in one of the long threads: here (http://forum.doom9.org/showthread.php?s=&postid=467081&highlight=ecl+Optimiser#post467081) It's a bit further along, but only works per VTS set. I actually lost track of it and when searching for it to post here was surprised at the advances that have taken place.

I don't mention it to discourage you, I just wanted to make people aware of it. I'm not even sure if John plans on developing it further, as the last update was several weeks ago.

[Joergen]

Wow, ECL Optimizer should have its own thread. It's sad to see it buried in there.

[the-warriners]

JDobbs - now that this app is in development do you still plan to add this sort of thing to DVD-RB as 'standard'?

Seeing as the original aim was to write a dvd shrink type of app that was easy to use but utilised the power to CCE i think it should be built in.

I dont want to belittle Robot1's work however.

[Joergen]

I'm sure he will and he has stated that he will. But there's still lots of bugs to squash and new features can bring more bugs that need to be squashed before adding yet more features.

[robot1]

I hope to find soon these features in DVD-RB ;)
Waiting for them, I coded this little app.

[the-warriners]

Joergen - I dont want to imply that JDobbs should do it now. Obviously these new tools are popping up now so I was just wondering if they might have prompted a change of direction.

To be honest I am more than happy leaving the extras at the DVD-RB calculated rate.

[robot1]

@all
Updated v 0.2 beta, with less bugs (I hope).

[P3gasus]

@robot1

I cannot test your software for now because I have no dvd to test it with (I am not at home); but I noticed that if you check the "Auto" checkbox without loading any inf file, RB-Opt crashes (Windows error message). I know that it is not really an useful bug report but I thought you could be interested.

Bye

PS Very nice app indeed :D

[jdobbs]

Originally posted by the-warriners
JDobbs - now that this app is in development do you still plan to add this sort of thing to DVD-RB as 'standard'?

Seeing as the original aim was to write a dvd shrink type of app that was easy to use but utilised the power to CCE i think it should be built in.

I dont want to belittle Robot1's work however. Actually I think this is a great way to do it. Something like this can be tested and if everyone likes the features -- and if everyone likes it I can look at rolling it into the base package.

I'm an advocate of open environments... and will try as much as possible to support the creativity of others. I think that is one of the factors that have made AVISYNTH so successful.

[robot1]

Originally posted by P3gasus
...I noticed that if you check the "Auto" checkbox without loading any inf file, RB-Opt crashes (Windows error message). I know that it is not really an useful bug report but I thought you could be interested.

Bye

PS Very nice app indeed :D Thanks!
Bug fixed for next version.

[robot1]

@DnGermany
Uhm... strange.
Can you check that Rebuilder.inf and Rebuilder.ecl in D2VAVS directory weren't actually saved?
Are there .bak files?
Thanks for info.

[Fishman0919]

I'm gettind the same error...checked the .inf and .ecl and they wasn't saved

[robot1]

@Fishman0919
What S.O. are you using?
XP ?
I can't repeat this error (win2k), but I hope I've fixed it.

[Fishman0919]

I'm running Win XP Pro sp1a

DVD-RB .45
Avisynth 2.54
decodefix100 (MPEG2Dec3dg.dll)

If this helps ;)

[robot1]

Thanks to Fishman0919 and DnGermany for pointing that bug.
It's fixed for next release (in a couple of hours).

[Fishman0919]

Sorry but Thank You....;)

[Joergen]

I get the "an unnamed file not found" error on both W2K and XP.
RB-Opt looks promising so far though.

Suggestion: Shouldnt the title names reflect the VTS_# instead? Like, I have this episodic disc where I wanted to cut down the extras VTS_5 but its Title3 in RB-Opt and I had to guess that by looking at the title video size %.

[robot1]

Lab-One just upped the new version.
link to v0.4 (http://lab-one.freewebsitehosting.com/images/RB-Optv0%5B1%5D.4.zip)
I fixed the "unnamed file not found" error (I hope), and added VTS number indication.

Added a new dialog box to change every cell bitrate (example: to lower end credits bitrate if they are in a single cell).
Added also an experimental "cell view" (plays the .avs with windows mediaplayer).

[Joergen]

Wow that was fast :D

Yep it works now for me. I changed VTS_5 and hit save and the BAK files were created and the INF and ECL updated. :)

[robot1]

Fine :)

[robot1]

Another update, for better size control.
Added preview also in main window.

To download:
link to RB-Optv0.5 (http://www.freewebs.com/robot1/RB-Optv0.5.zip)

Mich

[robw]

Originally posted by robot1
Another update, for better size control.
Added preview also in main window.

To download:
link to RB-Optv0.5 (http://www.freewebs.com/robot1/RB-Optv0.5.zip)

Mich

Mitch
Link is not working

[lab-one]

thats odd. right click and select save target as. that seems to work.

[robot1]

Fixed a bug introduced in v0.5:
loading a second Rebuilder.inf in the same session caused wrong bitrate displayed.
Much improved slider control behaviour.

The program now does what was in my mind at the beginning:
change Vob-ID bitrates
change single cell bitrate
cell preview

As there are many "error 9" for users with halfD1 & half bitrate, it could be useful to change the bitrate of the single frames cell (which goes too low and could be the cause of the error).
HalfD1/Half bitrate often cause undersized results: DVD-RB could be used to force an oversize to compensate (anyway I suggest to not set to half bitrate in DVD-RB at current stage, and to change with RB-Opt).

The interface should be better (my reference is always dvdshrink...) Maybe a treeview in place of the combo box would help. Maybe.
Development stopped for a while (if I don't find bugs to fix).

Download to
Link to RB-Opt v0.6 (http://www.freewebs.com/robot1/RB-Optv0.6.zip) (right click -> save target as)

[blueboyec]

Thanks for this great program.

Possible bug:

1. When trying to tweak the last few cells (usually the end credits) of a vob, the auto check box of the 1st cell also get unchecked which prevents this cell from receiving any addition bitrate from the given away bitrates of the credits?

2. Some movies get distributed over a few (2 or 3) vobID, so when you lower the bitrate of the end credits only the vobID cells with the end credits get the addition bitrate from the given away bitrates of the credits.

For example: a movie is distributed over vobID1 and vodID2, credits are in vobID2. Before lowering credits cells bitrate - vobID1 cells & vobID2 cells ~ 70% bitrate of original. After lowering credits cells bitrate - vobID1 cells ~ 70% & vobID2 cells (except credits cells) ~ 78% bitrate of original. Is there a way you can distribute the given away bitrates of the credits over vobID1 and vobID2 so that vobID1 cells ~ 74% & vobID2 cells (except credits cells) ~ 74%. Hope this makes sense?

Thanks again

[robot1]

Originally posted by blueboyec

1. When trying to tweak the last few cells (usually the end credits) of a vob, the auto check box of the 1st cell also get unchecked which prevents this cell from receiving any addition bitrate from the given away bitrates of the credits?
I'll check this. Hope for a fix tomorrow.

Originally posted by blueboyec
2. Some movies get distributed over a few (2 or 3) vobID, so when you lower the bitrate of the end credits only the vobID cells with the end credits get the addition bitrate from the given away bitrates of the credits.

For example: a movie is distributed over vobID1 and vodID2, credits are in vobID2. Before lowering credits cells bitrate - vobID1 cells & vobID2 cells ~ 70% bitrate of original. After lowering credits cells bitrate - vobID1 cells ~ 70% & vobID2 cells (except credits cells) ~ 78% bitrate of original. Is there a way you can distribute the given away bitrates of the credits over vobID1 and vobID2 so that vobID1 cells ~ 74% & vobID2 cells (except credits cells) ~ 74%. Hope this makes sense?
This is a bit harder to tweak. A title can be split in two (or more) VobID. Usually the split point is at the layer break.
At this time you should manually upper VobID1 bitrate, and then lower end credits cell, to have all movie cells with the same reduction. It's a bit trial and error.
I think the program should read the original .ifo to understand how a title is splitted, but I have never looked at this.

I'm glad you find this program useful.

[robot1]

Originally posted by blueboyec
1. When trying to tweak the last few cells (usually the end credits) of a vob, the auto check box of the 1st cell also get unchecked which prevents this cell from receiving any addition bitrate from the given away bitrates of the credits?
Fixed in v 0.6a. To download: Link (http://www.freewebs.com/robot1/RB-Optv0.6a.zip) (Right click -> Save target as)

Thanks to blyeboyec for pointing me that bug.

[blueboyec]

Thanks for the update

Any chance on my 2 request being fixed soon?

thanks again

[robot1]

Originally posted by blueboyec
Any chance on my 2 request being fixed soon?
Am I wrong, or there is only another request?
I think to insert some code to "group" some VobID's, so they're treated as one. It's the simplest way to treat movies distributed over a few (2 or 3) VobID.

[blueboyec]

robot,

That is the one.

Thanks again for this cool program.

[robot1]

Originally posted by blueboyec

2. Some movies get distributed over a few (2 or 3) vobID, so when you lower the bitrate of the end credits only the vobID cells with the end credits get the addition bitrate from the given away bitrates of the credits. New version v0.7 allows to join Vob-IDs, so you can replicate the real structure of the film.
If you use the tweak cell option to lower end credits bitrate (for example), all the cells of the film will benefit from the extra space gained, if you join all the VobIDs of the film. If you don't use this option, only one part of the film will benefit from the extra space.

For example, The Matrix Revolutions - R2.
After removing foreign menus and all other stuff, Rebuild gave me a reduction of 69,19%.
Tweaking the last cell of the film with the credits to a bitrate 935 Kbist/sec, the film has a reduction of 73,1%
Almost a 4% gain :)

I hope the interface is getting better.
To dowload:RB-Opt v0.7 (http://www.freewebs.com/robot1/RB-Optv0.7.zip) (Right click -> Save target as)

[rayvt]

If the movie has a lot of segments--such as 291, RB-opt crashes.

[VampHuntD]

This looks like a great addon for RB, great work!

[robot1]

Originally posted by rayvt
If the movie has a lot of segments--such as 291, RB-opt crashes. Could you send me the rebuilder.ecl and the rebuilder.inf?
PM me, thanks.

[blueboyec]

Thanks for the update

[Joergen]

I think if the movie has over 150 segments it suffers from a DVD-RB bug that splits the movie wrong.

[Jomile]

RB-Opt is a very nice feature to combine with the one click solution CCE back up.

What is a player that can be used to preview the first cell?

[robot1]

I use the old Media Player in windows 2000 (MediaPlayer version 6.4, filename mplayer2.exe). Also Windows Media Player (the new one, wmplayer.exe) works.
Any player capable to play .avs should work.

[blueboyec]

After restarting the program, it forgets where the media player is and I have to find the media player after very restart of the program. Is this a bug?

[robot1]

Yes it is:confused:
Please, can you check if the setting is saved in the .ini file when you quit?

[robot1]

Bug fixing:
Improved handling of players for cell preview.
Solved crash for VobID with more than 100 cells.
Added "Hide Vob-ID of insignificant size" option in JoinWithVobID dialog.
Donwload v0.7a (http://www.freewebs.com/robot1/RB-Optv0.7a.zip) (right click -> save target as)

In next version I hope to insert CCE tweakings:
gop lenght: 12 or 15 frames
dc precision: 9 or 10 bits... and so on.
Suggestions?

[PINOBIRD]

Hello robot1,
First of all thanks for this great add-on.
Wouldn't it be great to add checkboxes for the filters quantum has discribed here.
http://forum.doom9.org/showthread.php?s=&threadid=76261

Greetz PB

[robot1]

Originally posted by PINOBIRD
Wouldn't it be great to add checkboxes for the filters quantum has discribed here.
http://forum.doom9.org/showthread.php?s=&threadid=76261
Yes, it's possible.
One question: are those settings valid for all versions of CCE (2.50, 2.6x and Basic)?

[blueboyec]

This new version fixed the remembering of the media player problem.

Thanks for the hard work

[Xuivo]

I've just tried your program and works like a charm!!! Very nice apps, especially for the end credit!!!

I hope you will continue your work!

Cheers

Xuivo

[robot1]

A new version, with lot of improvements, will come soon.
new features:
insert line in avs scripts
CCE parameters tweaking (and a preliminary support to custom matrices)

[Video Dude]

Originally posted by rayvt
If the movie has a lot of segments--such as 291, RB-opt crashes.


I keep getting a crash with MFC (Microsoft Foundation Class) error box.

When rebuilder.ini is opened in Re-Opt 0.7a the MFC crash occurs.

The movie had 2,562 segments.

Here is the debug dump listed in the MFC error box.
Error Signature:
AppName: rbopt.exe AppVer: 1.0.0.1 ModName: rbopt.exe
ModVer: 1.0.0.1 Offset: 000165ec

[robot1]

Originally posted by Video Dude
I keep getting a crash with MFC (Microsoft Foundation Class) error box.

When rebuilder.ini is opened in Re-Opt 0.7a the MFC crash occurs.

The movie had 2,562 segments.

Here is the debug dump listed in the MFC error box.
Error Signature:
AppName: rbopt.exe AppVer: 1.0.0.1 ModName: rbopt.exe
ModVer: 1.0.0.1 Offset: 000165ec 2,562 segments?
Aren't too much? I've limited to 999 per VobID. Could it be a DVD-RB fault? If DVD-RB demuxing is right, I'll change that limit. Could you test if the rebuilded film (without tweaks) works well? (no stutter...).

[Video Dude]

I meant to say avs files. Is that the same as segments? If not, how do you determine the number of segments? DVD Rebuilder was 0.49 used.

Others seem to be getting a lot also:
http://forum.doom9.org/showthread.php?s=&threadid=76438

It seems to play just fine.

[robot1]

In next version I'll set the limit to 3.000 avs. Hope it's enough

[DDogg]

A new version, with lot of improvements, will come soon.
new features:
insert line in avs scripts
CCE parameters tweaking (and a preliminary support to custom matrices) Wow! Thanks so much for doing this! See your PM re the test version.

[robot1]

Link to download (http://www.freewebs.com/robot1/RB-Optv0.8.zip) (right click -> save as)
Added Expert Settings, to edit .avs scripts and CCE parameters.
Fixed a lot of bugs.
"Expert Settings" are per vob-id:
if you edit the .avs script (or change any CCE parameters), the changes are made for all the cells of that VobID.
If you have (for example) three extras in the same VTS (split in three VobID's), link them to treat as one, and make just one change.

My suggestion:
1 - if the film is split in two (or more) vob-id's, link them.
2 - change the compression (if needed)
3 - tweak end cell credits (if needed)
4 - link vob-id's to make expert tweakings.

@Video Dude
Please, test now. Bug should be solved.

P.S.:
as someone report problems in downloading, if anyone could mirror it...

[Edit]
CCE presets work only for CCE SP 2.66+ (the program detect the version). For CCE Basic users there is the ECL Tweaker by Quantum (http://forum.doom9.org/showthread.php?s=&threadid=76662)

[Joergen]

Here you go, feel free to add it to your main post:

RB-Optv0.8.zip (http://koti.mbnet.fi/haupt/RB-Optv0.8.zip)

[Video Dude]

Originally posted by robot1
@Video Dude
Please, test now. Bug should be solved.


@robot1
It works great! No more error.

The expert settings are a perfect addition to the program.

Thanks for the great program. Good job.

[jdobbs]

Originally posted by robot1
2,562 segments?
Aren't too much? I've limited to 999 per VobID. Could it be a DVD-RB fault? If DVD-RB demuxing is right, I'll change that limit. Could you test if the rebuilded film (without tweaks) works well? (no stutter...). What movie could have 2,562 segments? Is this a Kareoke DVD or something?

[Video Dude]

Originally posted by jdobbs
What movie could have 2,562 segments? Is this a Kareoke DVD or something?
The bonus features had massive amounts of still galleries. DVD Rebuilder detected each still as 1 frame. Each still was given its own avs file.

[jdobbs]

Ok. If they're stills they are supposed to be broken out.

[Joergen]

I'm also now needing to increase the bitrate of the stills, but keep the bitrate of motion video pieces in the same VTS. This is cause the video parts are fine with this bitrate (3000kbit) but the stills look awful :(

This title has about 400 segments, of which only 20 are for the movie.

RBOpt 0.8 closes without error when opening the .INF :(

Any easy way to up the bitrate for stills?

edit: ok here's how I'll do it (thanks to RBFarm I can)

1) I'll up the bitrate for the VTS16 and VTS17 that have the stills using ECL Optimizer
2) move their current encodes to a new dir
3) del the farm_chunk files for those VTS
4) re-encode them
5) then move only the big parts (video parts) of the earlier encode to the D2AVS dir.

This way I get optimized video and good looking stills without oversizing. I hope :)

[jdobbs]

Originally posted by Joergen
I'm also now needing to increase the bitrate of the stills, but keep the bitrate of motion video pieces in the same VTS. This is cause the video parts are fine with this bitrate (3000kbit) but the stills look awful :(

This title has about 400 segments, of which only 20 are for the movie.

RBOpt 0.8 closes without error when opening the .INF :(

Any easy way to up the bitrate for stills?

edit: ok here's how I'll do it (thanks to RBFarm I can)

1) I'll up the bitrate for the VTS16 and VTS17 that have the stills using ECL Optimizer
2) move their current encodes to a new dir
3) del the farm_chunk files for those VTS
4) re-encode them
5) then move only the big parts (video parts) of the earlier encode to the D2AVS dir.

This way I get optimized video and good looking stills without oversizing. I hope :) I'll check it out -- but I thought I'd already set stills to the maximum... might be mistaken though.

[Joergen]

Originally posted by jdobbs
I'll check it out -- but I thought I'd already set stills to the maximum... might be mistaken though.

No no dont, as I originally dropped those VTS16 and 17 lower with ECL Optimizer cause they contain duplicates of an extra (the same extra is on the disc 3 times.. go figure Disney mastering) and its not unreferenced.

So what I wanted to achieve is first lower (for video parts), then raise for still parts. :)

I'd like to add that I wouldhave removed those duplicates (they play after you play a question game) but DVDRemake screws the menus and DVDStripper screws the game :D

[robot1]

Originally posted by Joergen
This title has about 400 segments, of which only 20 are for the movie.

RBOpt 0.8 closes without error when opening the .INF :(
Could you send rebuilder.inf and rebuilder.ecl to email?
Thank you. My email is in the readme file.

[Video Dude]

Thats similar to the error that I was getting with Re-Opt 0.7a.

Re-Opt 0.8 opens the rebuilder.inf with no problems. Tested with 2,000+ segments.

[Joergen]

robot1: I'll do a clean prepare and try that. If it doesnt work I'll send them to you.

[robot1]

Originally posted by Joergen
robot1: I'll do a clean prepare and try that. If it doesnt work I'll send them to you. Thank you.
Anyway I think DVD-RB encodes stills at a CBR rate of 6.000. RB-Opt doesn't change the CBR encoding bitrate (I don't know if ECL Optimizer changes that parameter). If it works right, you could lower the bitrate of the VTS with RB-Opt, without need to care of stills, which will be encoded CBR.
If stills come bad, probably that's a CCE fault.
Master Jdobbs, correct me if I'm wrong.

[Joergen]

My CCE does the 3 passes for the stills.. at default DVD-RB settings the bitrate meter in CCE goes from about 8.5mbit for the .vaf pass down to 7.3mbit for the end of the 3rd (2nd) pass.

It seems CCE doesnt do very well with stills. The quality is quite much worse than the original stills even at default bitrates.

Also it takes quite abit of power to open and close CCE a few hundred times :) Direct still-copying would be more optimal, but of course jdobbs already knows this so...

Maybe somebody could write a tool that extracts, renames and copys the stills over to D2VAVS 1:1?

[Joergen]

robot1: I sent you a PM with details.

[robot1]

The RB-Opt crash is related to a huge number of VobID.
Bug fixed, for next version.

[jdobbs]

Originally posted by Joergen
My CCE does the 3 passes for the stills.. at default DVD-RB settings the bitrate meter in CCE goes from about 8.5mbit for the .vaf pass down to 7.3mbit for the end of the 3rd (2nd) pass.

It seems CCE doesnt do very well with stills. The quality is quite much worse than the original stills even at default bitrates.

Also it takes quite abit of power to open and close CCE a few hundred times :) Direct still-copying would be more optimal, but of course jdobbs already knows this so...

Maybe somebody could write a tool that extracts, renames and copys the stills over to D2VAVS 1:1? No. Don't go to all that trouble... I can extract the stills as-is. I worry, though, when I see someone who says they have 2000 stills in a file. 2000 I-Frames can add up to a significant amount of storage.

[Joergen]

Perhaps another expert-option would be handy? "Encode Stills" on/off :)

robot1: Thanks for the quick fix test version! I can now tweak the bitrates exactly like I wanted!

[wmansir]

Originally posted by Joergen

Maybe somebody could write a tool that extracts, renames and copys the stills over to D2VAVS 1:1?

Have you tried RB-Keeper? I'm not sure if it will work on stills, but it may. There is a link to the thread in the overview stickie.


@robot1

Actually, I was mistaken, vmode=0 is one-pass VBR, not CBR (vmode=1), but it is only used with CCE 2.5 according to my observations. That is probably because the init() error has only appeared with 2.5. So it looks like stills with 2.5 are encoded with OPV, Q=20.

Also, on a slightly related topic. Now that One Pass VBR mode is being tested you might want to check for OPV usage and display a warning or error message. The easiest way would probably be to look for the presence of the ANALYSIS.ECL file, since just checking for OPV usage in the ECL could lead to false positives with it being used for stills in 2.5.

[robot1]

Originally posted by wmansir
@robot1

Actually, I was mistaken, vmode=0 is one-pass VBR, not CBR (vmode=1), but it is only used with CCE 2.5 according to my observations. That is probably because the init() error has only appeared with 2.5. So it looks like stills with 2.5 are encoded with OPV, Q=20.I hope Joergen can test that movie with CCE 2.5, to see if OPV mode handle well stills.

Also, on a slightly related topic. Now that One Pass VBR mode is being tested you might want to check for OPV usage and display a warning or error message. The easiest way would probably be to look for the presence of the ANALYSIS.ECL file, since just checking for OPV usage in the ECL could lead to false positives with it being used for stills in 2.5. Thank you, you're right!. I'm working to insert the check (and I took the wrong way!). I think to display an error message: in OPV mode Q depends from all parameters of a CCE encode, so no parameter can be changed.

[wmansir]

Originally posted by robot1
Thank you, you're right!. I'm working to insert the check (and I took the wrong way!). I think to display an error message: in OPV mode Q depends from all parameters of a CCE encode, so no parameter can be changed.
Actually, you were ahead of me. :) I was thinking you should just disable bitrate changes, but you are correct, changing other encoding parameters (especially filters) will affect the output size in OPV encoding because of the change in compressablilty of the material.

[Xuivo]

Just want to say that the version 0.8 is working like a charm. Expert settings are great. But does anyone know where to get a guide explaining those function. I'm kind of a newbie in this domain?

Thanks

[robot1]

Originally posted by Xuivo
Just want to say that the version 0.8 is working like a charm. Expert settings are great. But does anyone know where to get a guide explaining those function. I'm kind of a newbie in this domain?

Thanks For avisynth filters you can look at this page (http://www.avisynth.org/index.php?page=Section+3%3A+Filters%2C+plugins+and+colorspaces)
For CCE settings the best guide is CCE manual!

[techdude]

Does RB-Opt v0.8 beta work with current dvd rebuilder Version 0.50a thanks for the help guys.:cool:

[robot1]

Originally posted by techdude
Does RB-Opt v0.8 beta work with current dvd rebuilder Version 0.50a thanks for the help guys.:cool: Yes, it works.
One Pass VBR mode is not supported, and will not be supported, as changing parameters will lead to unpredictable results. In next version RB-Opt will not open OPV projects.

[jdobbs]

Sorry. Not trying to make it hard for you.

[robot1]

It's not hard. It's a matter of taste.
Someone prefers OPV, others multipass.
I always do multipass encodes, and I like to tweak CCE options.
But there is people who wants to press the big red button and have the best result possible, as fast as possible.
So your app can be good for all. RB-Opt is for the tweakers...

[Joergen]

I also would think that if you want to cut in time using the OPV method then why would you want to optimize the output with RBOpt? :)

In any case, I'm sure a one pass VBR method is welcome to many since it brings DVD-RB closer if not on par with transcoder speeds and still better quality at low bitrates.

[jdobbs]

Originally posted by robot1
It's not hard. It's a matter of taste.
Someone prefers OPV, others multipass.
I always do multipass encodes, and I like to tweak CCE options.
But there is people who wants to press the big red button and have the best result possible, as fast as possible.
So your app can be good for all. RB-Opt is for the tweakers... I personally always use multipass for my backups. It is the way to guarantee the absolute best quality in the space available. But it never hurts to have a high-quality speedy solution available too.

[Fr4nz]

Hi, I think there's a little bug in RB-Opt. In fact, if I want to reduce the percentage reduction, for example, from 65,5 to 64,4 see what happens....

[Status]
mode=1
Progress=2
CCEType=0
Encode_Progress=34
[V01000000001001]
SCR=,000
PTS=25854,000
Frame_Rate_Code=3
Pulldown=0
Structure=3
Frames=5845
Last_Sector=98180
Reduction=63,7 <==== WRONG!!!
Aspect_Ratio=3
HalfD1=0
EndPTM=21067854,000
[V01000100001002]
SCR=21042000,000
PTS=21067854,000
Frame_Rate_Code=3
Pulldown=0
Structure=3
Frames=4641
Last_Sector=190309
Reduction=64,4 <==== OK!
Aspect_Ratio=3
HalfD1=0
EndPTM=37775454,000
[V01000200001003]
SCR=37749600,000
PTS=37775454,000
Frame_Rate_Code=3
Pulldown=0
Structure=3
Frames=5847
Last_Sector=310053
Reduction=64,4 <==== OK!
Aspect_Ratio=3
HalfD1=0
EndPTM=58824654,000
......and so on!

So it seems that for the first cell RB-Opt doesn't set the right value. Can you correct this?? :)

[robot1]

@Fr4nz
Thanks for the report.
I'll check.

[Fr4nz]

Great Robot :D

I hope it's an easy thing to fix!

[Paced]

Hey robot1, just wanted to say thanks for the addition of the expert features, they're extremely useful :) Just wondering though, how difficult do you think it would be to add a function to remove a line (in the AVS script)? Thanks again for this utility :D

[robot1]

@Paced
Why would you remove a line in the script?

[Paced]

Originally posted by robot1
@Paced
Why would you remove a line in the script?

Hey, thanks for the reply. One reason is, when adding multiple lines to the script, and you accidently make a silly mistake, you have to reset the script, then start all over again. And secondly, DVD-RB uses BilinearResize when resizing down to half D1, and I prefer to use LanczosResize instead (therefore, a 'remove line' function would able me to easily replace the Bilinear with the Lanczos).

[robot1]

Next version will not have these features.
But in future I plan to implement a better editing (with a sort of "favourites filters", so there will be less mistakes).
I could do "Replace line", to solve a problem like the one you showed.

[Fr4nz]

Did you succeed in correcting the bug I've reported?

[280zx]

This is pretty slick. I've only tried it once so far but it worked perfectly. Thanks for the tool.

[robot1]

Right now I'm testing.
Is it time for a bugfixed release?

[robot1]

Originally posted by 280zx
This is pretty slick. I've only tried it once so far but it worked perfectly. Thanks for the tool. :) I hope it will be more and more useful

[ClydeFrog]

i think you should implent an option to reduce the overall bitrate of all vob-ids. i sometimes get oversized results and would like to reduce the bitrate evenly of every id...

[Fr4nz]

Yes I agree.

[techdude]

Thanks so much robot1 RB-Opt v0.8 beta works great rebuilder Version 0.50a i just did a backup of face/off dvd with CCE SP 2.66 and tweaked the extra tralier to a bitrate of 1800 and the end credits of the movie to 2016. with 5 passes movie got a bitrate of 4016 quality is Awesome. thanks again for thinking about us tweakers.:D

[robot1]

CCE handles well end credits also at a bitrate of 1000-1200 (unless you're very much interested in reading them!).

@Clydefrog
It's an option I can implement.
Anyway, in my experience, if you don't change CCETargetsectors in Rebuilder.ini, you'll never get oversized results.

[ClydeFrog]

i really dont know why this special disc gets oversized every time by 100MB, but it does :(
its my personal project of kill bill uncut, jap version with german ac3 and subs. plus the german menu and a nice intro from the jap disc and the english making-of.
pretty sweet result, but oversized ;)
i cant prog in any common language, but i'm expert in mirc scripting(:D), so i did it with a nice mirc script :P

[Fr4nz]

Originally posted by robot1
@Clydefrog
It's an option I can implement.
Anyway, in my experience, if you don't change CCETargetsectors in Rebuilder.ini, you'll never get oversized results. [/B]

Well, IMHO the default setting is too conservative because it leaves ~40-60Megs of space free on the DVD. So it could be useful an option that permits you to modify the overall bitrate.

[jdobbs]

Originally posted by Fr4nz
Well, IMHO the default setting is too conservative because it leaves ~40-60Megs of space free on the DVD. So it could be useful an option that permits you to modify the overall bitrate. If you are off by 40M that means you have filled the disc to within 8/1000ths of capacity... do you think you may be splitting the hair a little here? Just how accurate is accurate enough?

[Fr4nz]

Originally posted by jdobbs
If you are off by 40M that means you have filled the disc to within 8/1000ths of capacity... do you think you may be splitting the hair a little here? Just how accurate is accurate enough?

Well we are speaking about personal tastes ;)

[Joergen]

40MB might be something if you think it's an extra animation or menu, but it's nothing spread across the movie, just a decimal in a number.

Cant you think of something to fill that little space with? Have you thought of what happens if your dog chews through the original? Put some 800dpi scans of the covers on the backup and sleep better ;)

[robot1]

A new beta:
download RB-Opt v0.8a (http://www.freewebs.com/robot1/RB-Optv0.8a.zip) (right click -> save target as)
Fixed bug reported by Joergen and (I hope) the small one reported by Fr4nz.

@Fr4nz
Please, report results with this version.

[dave88]

Your Download is not working for me, I get "your current security settings do not allow this file to be downloaded" I reset my security to the lowest possible setting (temporarily) and still no go, I have never had this problem before :confused:

I really wanted to try it out :(

[robot1]

If someone can help hosting...

@dave88
In page 4 there is a working link to RBOpt v0.8 by Joergen).
Which browser are you using? I can download with Explorer and with Mozilla, default options.

[dave88]

The pg4 link works fine for me, not sure what the problem is with the other :confused:

I'm using IE6 and like I say I tried setting security to low.

Anyway, Thanks for the cool tool

[robot1]

Here is another link to RBOpt v0.8a (http://www.adrianhensler.com/dvd-rb/RB-Optv0.8a.zip)

Edit:
Mirror is by adrianhensler.
@adrianhensler
Thanks (I couldn't send you neither a PM nor an email...)

[dave88]

Works Great, Thanks!

[robot1]

New version.
Download here (http://www.freewebs.com/robot1/RB-Optv0.9.zip) (right click -> save target as).
If anyone can host on another server, PM me or post the new host (someone reports problem with my current server).

Changes:
Much improved avs editing:
- Added Favourites filters for faster avs editing
- Add remove line options (warning! only for experts!)
Global options to set a different target size (from 95% to 105%)
Original files by DVD-RB are now kept with a different extension, and it's possible to restore them all.
Bitrate control now works as should (thanks to Fr4nz for reports).
Add support to CCE Basic filters

RB-Opt works with the newest DVD-RB 0.51.
Anyway, if you select "Steal Space from Extras" the Reduction % is wrong (I think Rebuilder calculate reduction % after stealing. If jdobbs could change that, having in account the space stolen ...)

[Joergen]

mirror: RB-Optv0.9.zip (http://koti.mbnet.fi/haupt/RB-Optv0.9.zip)

[robot1]

Thanks for the mirror.

@all
I'll be one week off, so don't worry if I'll not reply to all bug reports and requests soon.
When I'll be back, I'll read all the messages.

[Fr4nz]

robot your proggie seems to work correctly now! Good job :)

[robot1]

Originally posted by Fr4nz
robot your proggie seems to work correctly now! Good job :) :) Thanks for the help in finding bugs!

[eggchen]

I'm using the latest version of DVD-RB (51b) and just tried RB-Opt for the first time (0.9). After linking then tweaking the end credit cell, saving the changes, and then encoding in DVD-RB, I get a No File is Specified error.

I tried it several times.

Has anyone else come across this?

Thanks.


... this is not happening in version 0.8a.

[Fr4nz]

Same thing here :(

[robot1]

I'll post in a few hours a bugfixed version.
Thanks for reports.

[robot1]

Changes:
Fixed a bug with CCE 2.50 showing a "No File is Specified" error (thanks to eggchen and Fr4nz).
Fixed a bug in .avs editing: lenght of lines to add was limited to few chars (found by THR on doom9.de forum)
Download (http://www.freewebs.com/robot1/RB-Optv0.9a.zip) (right click -> save as)
As always, a mirror would be very appreciated, as someone reports problem in dowloading from my site.

[eggchen]

Robot1,

Just noticed the post. I'm trying it now. So far, so good.

Thanks for the excellent work.:D

[The eDealer]

Hi robot1,
sorry, i also have the download problems with the right click, don't know why. The mirror is perfect, but the new version isn't linked to a mirror. :(
Can you send the new version (0.9a) via mail to me, than i can mirror it at the german doom9 Settings Thread of the RB Opt. (http://forum.gleitz.info/showthread.php?t=13041) ?

[robot1]

Working Mirror (forum.gleitz.info) (http://forum.gleitz.info/attachment.php?attachmentid=67050)
Thanks to eDealer and the german doom9 forum.

[TRALALA]

Hi guys,

I think that it would be interesting to add in "CCE Setting" to change BIAS.I change it for the extras with very low bitrate, for example.

bye :thanks:

[Paced]

Thanks for the great work robot1 - the 'remove line' option is awesome :D Keep up the good work.

[robot1]

Originally posted by Paced
Thanks for the great work robot1 - the 'remove line' option is awesome :D Keep up the good work. :)
I always try to insert in the program a good suggestion.

@TRALALA
You'll find it in next version (I think in the week-end, 'couse I'm busy now...)

[robot1]

A set of Matrices for CCE, by our German friends:
Matrices in RB-Opt (http://forum.gleitz.info/attachment.php?attachmentid=67057)
Thanks to eDealer

[The eDealer]

New Link for the Matrices Collection 0.2 (http://forum.gleitz.info/attachment.php?attachmentid=67104), now with english informations about each matrix.

EDIT: i have included the bach1 by ddogg matrix.

[TRALALA]

Matriz BACH1 (by DDogg), for bitrate ultra low (around 1000):


08 16 19 22 26 27 29 34
16 16 22 24 27 29 34 37
19 22 26 27 29 34 34 38
22 22 26 27 29 34 37 40
22 26 27 29 32 35 40 48
26 27 29 32 35 40 48 58
26 27 29 34 38 46 56 69
27 29 35 38 46 56 69 83
16 18 20 22 24 26 28 30
18 20 22 24 26 28 30 32
20 22 24 26 28 30 32 34
22 24 26 30 32 32 34 36
24 26 28 32 34 34 36 38
26 28 30 32 34 36 38 40
28 30 32 34 36 38 42 42
30 32 34 36 38 40 42 44

I use it for extras Half D1 & Half space for example.

@robot1: THANKS :D

[The eDealer]

@Tralala,
with GOP 12 or 15??
DC 8 ?
QC 24 ?

[robot1]

I always use GOP 15.
It's dvd standard, and allows better compression.
Had no problem, till now.

@Tralala and eDealer
Thanks for the matrices. I'll insert them all in next build.

[TRALALA]

with GOP 12 or 15??
DC 8 ?
QC 24 ?
I usually use 15 for CVD/SVCD and 12 for DVD.
After reading robot1, I doubted which GOP to assign to the extras. Really with 15 the compression is better.

Finally:
DC 10 (normally, like the source)
QC 24
GOP 15 (better compression)


Regards, :D

[The eDealer]

For me, the extras (1/2D1 & 1/2 BR) need to be handeld like SVCD/VCD, so I use:
GOP 15 (for better compression)
DC 8 (like SVCDs)
QC 20

nice to know your way :)

[robot1]

Changes:
Full CCE SP filters support
CCE Min/max bitrate option included
CCE SP 2.67 BIAS support
CCE Basic 2.69 "Quantization characteristics" support (it should works as soon as Jdobbs support it in DVD-RB)
In avisynth editing, preview of both original and modified cell
Fixed a bug in Tweak Cell
Other small changes.

Download here (http://www.freewebs.com/robot1/RB-Optv0.10.zip) (right click -> save target as)

Edit:
Mirror (http://forum.gleitz.info/attachment.php?attachmentid=67142)

[TRALALA]

WOW, robot1 great work with "CCE Setting." :eek:

Although I have a problem, when I insert a max/min bitrate, the button OK is disabled. :confused:

Regards :D

[robot1]

Originally posted by TRALALA

Although I have a problem, when I insert a max/min bitrate, the button OK is disabled. :confused: The button OK is enabled as soon as the textbox loose the focus (ex: click on a radio button of DC Precision... , or just use tab after editing the bitrate)

[dvdRENEGADE]

bump

[robot1]

Any feedback?
Nobody reports anymore... so I think it's stable enough (and there is nothing more to tweak...)
In the weekend I'll post a small update.

[cmsoliveira]

Hi,

first of all, great app. Very usefull and easy to use.

I only would like to make a small request...

Is it possible to show the size of the dvd when we tweak it?
Example: I needed to oversize a dvd, in order to later compress the menu with dvdshrink (is better after because sometimes dvd-rb doesn't like "touched" source), but for that i really need to know how much am i going to oversize, hence, show the size of the tweaked dvd.

Hope u undersatnd, my english is not that good :)

Cya

[robot1]

Originally posted by cmsoliveira
Is it possible to show the size of the dvd when we tweak it?
There is a problem: Rebuilder doesn't save in extern files the size of the menus (and other Vob's not encoded) and the size of audio streams. So it's impossible without analizing the dvd-source, and I think it's too much difficult for me. :(

[cmsoliveira]

Well, then i guess i'll have to continue with my trial and error method:(

Anyway, great app you have there, and for me , with dvd-Rb is a must-have.

Many thnx

[jdobbs]

Originally posted by robot1
There is a problem: Rebuilder doesn't save in extern files the size of the menus (and other Vob's not encoded) and the size of audio streams. So it's impossible without analizing the dvd-source, and I think it's too much difficult for me. :( I collect that information anyway. If you'd like I can write it to the rebuilder.inf file.

[fugit10]

were you suppose to open rebuilder.ini after u press prepare or after u press encode? cause i did it after preparation was done which showed only one vts file and when i did it after i pressed the encode was done and then i saw many more vts menus. I did the bittrate changes and stuff then but i'm not sure if there was a change done. another question I had was that am i suppose to click dynamicall assign cell bittrates in order for me to use the full space of the dvd? my last question is how can I lower the bittrate for the menus? I was able to change it for the extras but not the menus.

[robot1]

Originally posted by jdobbs
I collect that information anyway. If you'd like I can write it to the rebuilder.inf file. Yes, it would be great! Thanks.

[robot1]

Originally posted by fugit10
were you suppose to open rebuilder.ini after u press prepare or after u press encode? cause i did it after preparation was done which showed only one vts file and when i did it after i pressed the encode was done and then i saw many more vts menus. I did the bittrate changes and stuff then but i'm not sure if there was a change done.
You should open rebuilder.ini after running the prepare step in dvd-rb. RB-Opt changes the parameters used during the encode step. So, any changes made after the encode are not useful (or you should encode again).
Anyway you should find the same VTS numbers before and after encode. Did you uncheck the "Ignore VOB-ID of insignificant size" the second time?
another question I had was that am i suppose to click dynamicall assign cell bittrates in order for me to use the full space of the dvd? my last question is how can I lower the bittrate for the menus? I was able to change it for the extras but not the menus. DVD-RB doesn't support encoding of menu (till now). As soon as DVD-RB will support menues, also RB-Opt will.

[robot1]

Changelog:
- Display approx. final DVD size (DVD-RB 0.55 and later). This is an estimation, and I need feedback on the results. In my tests it was enough accurate (2-4 MB off)
- Better text box behaviour (now OK button is always enabled)
- Better support for stills (not compressed vbr by DVD-RB 0.53)
- About box with reminder to the DVD-RB thread at doom9 forum (to check for upgrades, ask for help...)

To download: link (http://www.freewebs.com/robot1/RB-Optv0.11.zip) (right click -> save target as)

Hope you find it useful.

[jptheripper]

could you explain the better support for stills part? this is the portion of rb that has been giving me the most problems (crashing cce)

if i run my .inf through rb-opt does it make some changes to do a better encode on stills?

Guess i am just not sure what to do with it.

[robot1]

No, RB-Opt doesn't change the way Rebuilder encodes stills.
From DVD-RB 0.53 stills are encoded CBR at a fixed rate of 6.000 kbit/sec, and many users reported it solved their problems.
The new version of RB-Opt simply doesn't allow to change VBR bitrate for cells which are encoded as CBR (stills).
Hope to have been clear.

[69Mws]

The archive with 0.11 is not working for me, got following error: "The archive is either in unknown format or damaged" (using WinRAR 3.30) :(

Greetz
69Mws

[robot1]

I hope someone could offer a mirror.
@69Mws
PM your email and I'll send you the file.

[robot1]

Here is the mirror.
Thanks as always to eDealer!
mirror (http://forum.gleitz.info/attachment.php?attachmentid=67817)

[69Mws]

Thx for the mirror, wasn't here since my last post, so I couldn't pm you my mailaddress.

But the new mirror is working fine :)

Greetz
69Mws

[robot1]

Originally posted by TheGame7
Does RB-Opt allow the encoding of titlesets usually ignored by DVDRB? No. RB-Opt works on the files created by DVD-RB in "prepare" stage. If a titleset isn't demuxed, RB-Opt can't touch it.

[robot1]

RB-Opt v0.12 (http://www.freewebs.com/robot1/RB-Optv0.12.zip) (right click -> save target as)

Few updates this time (working on new features...)
- Fixed a bug: predicted size didn't worked anymore with DVD-RB 0.56 (a parameter in Rebuilder.inf was changed from the one used in DVD-RB 0.55)
- Added full preview of VobID's in main window and in .avs editing (useful to check filters in every scene of the film, not only on the first cell)
- Added size indication in "Global Options": it's handy if you want an oversized DVD, and you want to remove extras with external program *after* rebuilding with DVD-RB.

As soon as I get another mirror, I'll update the first post.

[jptheripper]

is there anyway to global replace things?

for example if using half d1 i would like to LancozResize instead of bilinear. But i dont want to open every avs..

[robot1]

RB-Opt works per VobID, so it edits all the .avs of a VobID in one time.
If extras HalfD1 are in the same VTS, join all the VobID's (button Link VobID), and you have to do just one editing.
Try it, all your changes are backed-up, and you can restore everything.

[Dimad]

@robot1

As per your request:
Rb-Opt v0.12 can be downloaded from DimadSoft site: http://www.dimadsoft.com/rb-opt/RB-Optv0.12.zip

[robot1]

Thank you.
I update the first post.

[Xuivo]

Yeah, thanks Robot1. I think that your program is great!! There's a last thing that could be great with it but i don't know how hard it is do program it. Is it possible to split a cell in 2 and change the bitrate of only a part.

For example, the last part where the credit are normally. Sometime theres still like 2 minutes of movie then after like 10 min of credits. So it could be cool if you can only change the bitrate from 2 min to 12 for example.

Is that possible?

Cheers, and thanks for your great work!!!

[robot1]

@Xuivo
Thanks.

I think it's a good idea. I'll try to add this feature in next version.

[erdoke]

Originally posted by robot1
@Xuivo
Thanks.

I think it's a good idea. I'll try to add this feature in next version.

So is that possible with this nice tool to set RB to encode only one cell (and use all other demuxed materil with the re-encoded cell to rebuild the DVD-Video)? I have added a menu to an earlier DVD2DVDR backup, and it is a little bit oversized now. But only 9 MB, so it would be enough to re-encode the last cell where the credits section is located.

THX for any help

[robot1]

Originally posted by erdoke
So is that possible with this nice tool to set RB to encode only one cell (and use all other demuxed materil with the re-encoded cell to rebuild the DVD-Video)? No, you can change the bitrate of every cell, but you have to encode all.

[Sir Didymus]

Originally posted by erdoke
So is that possible with this nice tool to set RB to encode only one cell (and use all other demuxed materil with the re-encoded cell to rebuild the DVD-Video)?
...
THX for any help

If you didn't delete the D2VAVS folder, it should be possible to do the job manually (I mean even without the support of the excellent application of robot1)...

1) identify the filename of the cell you want to squeeze (let's say for example it is V01001100002004.m2v)

2) open the file rebuilder.ecl with a text editor, and extract the relative [item] and [file] sections to create a new temp.ecl file

3) In this file lower to a suitable value the line vbr_brate_avg=xxxxx; the suitable value should be very easy to find, if you know the number of frames of the cell (i.e. its duration) and the size you want to obtain... with a little bit of math... :)

4) Manually start eclcce, feeding it with the temp.ecl

5) Just hit rebuild...

It is not properly a single click process, but it should take much less than reencoding every things...

Hope it is of some help...
SD

[Sir Didymus]

... and of course an even simpler solution is to use DVD Shrink to reduce a bit the movie itself ot some parts (like the menus or the extra) that are of minor relevance to you...

Cheers,
SD

[erdoke]

Originally posted by Sir Didymus
... and of course an even simpler solution is to use DVD Shrink to reduce a bit the movie itself ot some parts (like the menus or the extra) that are of minor relevance to you...

Cheers,
SD

SD, thanks for your help.
Yes, the transcoder option is on my list, but it is still not a 10 minute thing.
I hoped that maybe a blanker app exists that can blank out a part of a single cell or RB-Opt is able to handle only a part of the movie. My cell looks like: 1 minute of the end of the movie and long credits.
I do not really understand the manual CCE recoding of this cell. Or to be more precise, what I do not understand is how I will force Rebuilder to rebuild the movie if a RB "Encode" phase is not executed between Prepare and Rebuild. Even the Rebuild button is unfunctional and grey if an Encode section has not been done.

[Sir Didymus]

Ahhh,

SORRY erdoke!!!

I totally misunderstood what you have stated in your post...

I assumed that you did at least ONE complete rebuild with DVD-RB, and that you were looking for some method for reducing the size of one of the cells of the rebuilt title...

It is now clear to me that your backup has been produced by DVD2DVDR, not by DVD-RB, so please forget my previous post...

Anyway, thinking to the problem, I have to propose a solution (or better a crazy idea, since it is assuming an heavy manual work...), which is working indeed, since I just tested it before posting...

It takes around 30 minutes for a simple title...

1) rename the cce exe file; in such a way that when eclcce try to launch it an error message is produced...

2) Set up DVD-RB in three click mode and go through prepare (that goes flawless) AND encode; two error messages are produced for every try of encoding, BUT the avs and the FLG files are still generated in the D2VAVS folder... and the rebuild buttun is now not grayed...

3) what you need now is a single m2v file for every cell that has not been generated by CCE (by the way, now it is better to rename again the cce exe file to its original name)... for doing this, vobedit is just what is necessary: first pass for demuxing by cell id the whole title set(s), and a second pass for demuxing again the cells for the extraction of the m2v streams...

4) Now it is necessary to rename carefully every demuxed m2v file to the one corresponding to the cell to be rebuilt. The log file generated by vobedit and the AVS files in the D2VAVS folder are helpful for matching the names for the m2v files...

5) Hit rebuild...

6) In this manner you have recreated an IDENTICAL copy of your source disk, since you didn't use any encoder for its production. Now it is possible to change the bitrate of every single cell in the title, since you have in the D2VAVS folder all the necessary files...

I say again: it works...

Cheers,
SD

[erdoke]

Originally posted by Sir Didymus
Ahhh,

SORRY erdoke!!!

I totally misunderstood what you have stated in your post...

I assumed that you did at least ONE complete rebuild with DVD-RB, and that you were looking for some method for reducing the size of one of the cells of the rebuilt title...

It is now clear to me that your backup has been produced by DVD2DVDR, not by DVD-RB, so please forget my previous post...

Maybe it was because of my poor english and I should look for a good dictionary instead of writing on-the-fly. :D

Originally posted by Sir Didymus
Anyway, thinking to the problem, I have to propose a solution (or better a crazy idea, since it is assuming an heavy manual work...), which is working indeed, since I just tested it before posting...

It takes around 30 minutes for a simple title...

...

I say again: it works...

Cheers,
SD

I must say that it's a very smart and elegant solution to my problem. Unfortunately I will not have time to try it this time, so it is more than probable that I will use a transcoder to shrink the 9 MB. Anyway the movie has an average bitrate of 4400, so it will be unvisible.
It is among my plans to rebuild another one of my backups (5th Element) which has a huge menu, and it seems reasonable to re-encode it and the end credits as well.

So thanks again SD, soon I will take advantage of your guide.;)

[robot1]

You can find RB-Opt v0.13 here (http://www.freewebs.com/robot1/RB-Optv0.13.zip) (right click -> save target as)
Most part of the code for the OPV mode is written by SansGrip. All the credits goes to him!
As soon there is a new mirror, I'll post it.
I hope to receive feedback on the OPV mode, to improve it.

Changelog:
- Added support to OPV.
DVD-RB's OPV prediction pass is done at the end of the prepare phase,
this makes it impossible to use RB-Opt with DVD-RB's version of OPV.
The prediction has already been run using the default CCE settings
from DVD-RB, and any changes to those (e.g. by selecting a custom
matrix with RB-Opt, or changing the GOP length) will invalidate the
results and cause an under- or over-sized encode. By doing the
prediction in RB-Opt one is able to set custom parameters and tweaks
as usual and *then* run the OPV prediction, meaning the prediction
will be run with the same CCE parameters as the actual encode, and
should thus be accurate.
More info can be found in OPVreadme.txt in the package.

Now you can run the "prepare" step in DVD-RB using normal VBR mode,
then, in RB-Opt, select for any VobID if encode in VBR or OPV mode.
If you have an oversized (or undersized) result in OPV mode, you can
re-open the Rebuilder.inf in RB-Opt, and change the mode to VBR. After
saving, the "encode" step in DVD-RB will run just the second CCE pass
(as the .vaf file is retained).


- Fixed a bug: if you selected a non standard matrix in CCE options, it
was used not only for the selected per vob-id, but for the whole film.
Now you can set different matrices for every VobID (ex. use a low
bitrate matrix for extras with low bitrates, leaving default matrices
for the main movie)

[Paced]

This program just keeps getting better and better; thanks robot1 (and SansGrip) for all your hard work.

[robot1]

Originally posted by Paced
This program just keeps getting better and better; thanks robot1 (and SansGrip) for all your hard work. Thanks
:)

[ShadowKnight]

Originally posted by robot1

- Added support to OPV.

Now you can run the "prepare" step in DVD-RB using normal VBR mode,
then, in RB-Opt, select for any VobID if encode in VBR or OPV mode.
If you have an oversized (or undersized) result in OPV mode, you can
re-open the Rebuilder.inf in RB-Opt, and change the mode to VBR. After
saving, the "encode" step in DVD-RB will run just the second CCE pass
(as the .vaf file is retained).


You Rule Robot1! and SansGrip as well... thank you for adding this Robot1, it was well worth the wait. Mad props to you my friend :)

[ShadowKnight]

Originally posted by Xuivo
Yeah, thanks Robot1. I think that your program is great!! There's a last thing that could be great with it but i don't know how hard it is do program it. Is it possible to split a cell in 2 and change the bitrate of only a part.

Cheers, and thanks for your great work!!!

I would like to see this also, but with opv, and selecting a section to do vbr. It would be nice for end credits or HBO static screen logos. Is that possible?

[ShadowKnight]

Originally posted by robot1
I hope to receive feedback on the OPV mode, to improve it.

My first Test came out beautifully!
Forrest Gump R1
4.37 GB (4,694,736,896 bytes)

I'll report more as I run them.
Seems to be working great tho... I ran it with the double check thing on, and all the rest at default values.

[SansGrip]

Cool :D

[erdoke]

The primary download link in the first post seems broken right now.

[SansGrip]

Mirrored here (http://www.indeus.com/sansgrip/RB-Optv0.13.zip).

[erdoke]

Originally posted by SansGrip
Mirrored here (http://www.indeus.com/sansgrip/RB-Optv0.13.zip).

THX, it worked OK.

[marnum]

Hi

I'm afraid I currently can't get OPV to work. I'm doing AI at the moment, and I've done what the OPVreadme said, and I clicked 'Save Settings'. The avs was not modified, but some CCE settings were.

Min bitrate: 600kbit
Max bitrate: 6500kbit
Custom Matrix: KVCD Notch
Low Pass: 8
Effect Restricted Vertical: 2
DC Prec: 10
GOP: 12

CCE 2.66.01.07 started up and ran the prediction.

When CCE finished, I got a notification
"Could not open 'C:\Path\VTS_02_VobID_01.m2v' for reading"
and the log said

=== Running prediction on VTS 2 - VobID 1
--- Initial Q: 36
--- Frames: 109275, target size: 1728188 KB
--- Desired sample size: 17459 KB
--- Pass 1. Waiting for encoder...
--- Testinq Q factor: 36
*** Using Q factor 0
=== Q Factor not calculated

Not seeing what was wrong, I opened the file in mpc and it played flawlessly.
Anybody got an idea?

[robot1]

Originally posted by marnum
When CCE finished, I got a notification
"Could not open 'C:\Path\VTS_02_VobID_01.m2v' for reading"
and the log said
Check your PM.
Anyway, what is the path of your D2VAVS folder?
VTS_02_VobID_01.m2v should be in ..\D2VAVS\prediction\
and not in
C:\Path\
:confused:

[robot1]

Download RB-Opt v0.14 (http://www.freewebs.com/robot1/RB-Optv0.14.zip ) (right click -> save target as)
As soon as there is another mirror, I'll update the first post.
Changelog:
Added support to CCE SP retail (as DVD-RB 0.58)
Fixed a bug in "Link VobID" dialog: sometimes "Link All" didn't work properly.

I've made few changes to the OPV routine, to avoid the error reported by marnum. Hope it's fixed, but I can't reproduce it. If anyone gets that error, please post in forum (or PM me).

[Boulder]

I can't get v0.13beta working with the latest DVD-RB. The program just closes itself without any crash info when I load the rebuilder.inf file. I'm currently trying to encode Lord of the Rings : The Two Towers Extended Edition extras, could it be that the .inf file is just too big, it's 341492 bytes!

If (and probably when) you need more info or the inf file, just let me know.

[robot1]

@Boulder
Please, check you PM

RB-Opt v0.13 beta should work with DVD-RB 0.58, if you don't use CCE SP 2.67 retail.
I posted yesterday an update (0.14beta) to be fully compatible with that release.
Anyway in a few hours I'll post 0.14a because I found two little bugs. I hope to include fixes to your problem.

[robot1]

@Boulder
Thanks for the file you sent me.
The problem is the sixth vts: there are 1806 cells! (still pictures, as they are 1 frame).
I'll post a fix in v0.14a.

[Boulder]

No problem, glad to help:)

[burnout]

with dvd-rb 0.60, rb-opt (tried 0.12 and 0.14) shows some vob-id's twice, but when u select the lower of the 2 duplicate vob-id's it highlights the first... i guess this has something to do with the new prepare stage with 0.60 as i have never seen it before and it has appeared on 2 dvd's. not tried encoding them yet so i'm not sure if it affects anything but thought i would report this ;)

[jdobbs]

This could be caused by the introduction of a new area in the REBUILDER.INI file. Now in addition to the "[V01000100001001]" area for each cell there is a "[V0100001]" area to store information for a VOB. Currently there is only one entry (last_sector), but it might expand).

[robot1]

New version of RB-Opt.
Can be downloaded here (http://www.freewebs.com/robot1/RB-Optv0.15.zip) (right click -> save target as)
As soon as I've a new mirror I'll post it.

Changelog:
Added compatibility with DVD-RB 0.60
Better memory usage, to allow to tweak DVD with strange structures (lots of Vob's or lots of cells)
Fixed incorrect "Global resizing" behaviour in "Global Options" dialog.
Various bugfixes.

[Edit]
If you have already downloaded v0.15 and have problems in save - download it again. The link is the same, but there is a new build.

[robot1]

Thanks as always to eDealer,
here is the mirror (http://forum.gleitz.info/attachment.php?attachmentid=68632) on doom9.de

[Boulder]

Does v0.15 support DVD Rebuilder version 0.62? I only get the whole movie shown as one cell so I can't limit the bitrate for end credits. Other than that it seems to work as it should. I just wanted to know to make sure I'm not doing something wrong here;)

[robot1]

RB-Opt should work with DVD-RB 0.62, as jdobbs didn't changed file format in this version. And in a first test I've done I see no problem.
If you uncheck "Autosized" and press "Tweak Cells", do you find just one cell?
That would be very strange.
If you find just one cell, please check how many times you find the line
[item]
in Rebuilder.ecl
If there are many instances, then there is something wrong, and please PM me.
TIA.

[Boulder]

Looks like it was a mistake on my part, I just noticed that I had to select VBR in RB-Opt to get to tweak the cells:o

Once again I know how a newbie feels..

[robot1]

In OPV mode you can't tweak end-credits, because the whole vob-id will be encoded with the same Q factor.

[wfn1]

@robot1

hi, just tested out your .15 version in conjunction with dvd-rb .62 and i'm getting this cce error which says unable to open cce_encode() function or something to that extent. after that the encoding stops.

the source is futurama_s3_d1 and my tweaking included evening out the bitrate on per vts level for main episodes (vts4-6 and vts8-10), linking the ids in an extras vts7 and adjusting the bitrate and adjusting the bitrate on vts11 which is also extras.

the encoding stops on vts9. i tried with cce sp 2.50.01.00 and cce sp 2.66.01.07 and they both give me the same error. is there a log somewhere which i could use to troubleshoot or send to you? thank you for your continuous effort in developing this very necessary tool.

[robot1]

Probably the bitrate of the cells in vts9 is too low for the complexity of the source (I think other people reported this error, even without RB-Opt - especially for "static" - like HBO logo).

You could try to change encoding in CBR for cells in vts9 (if they are small enough you shouldn't have problems).

For cce 2.50 CBR is
vmode=1
for CCE 2.66 CBR is
video_type=1

You can find vts9 cells in rebuilder.ecl looking at:
[item]
title=V09xxxxxxxxxxxx

I've sent you a PM.

[wfn1]

i'll try the cbr method and see if it helps, i got the pm and i already sent you all the files you requested. thank you!

[pg55555]

robot1

As you can see in this thread

http://forum.doom9.org/showthread.php?s=&threadid=81567

this is an error that apperas for cells of 60 or fewer frames when you select Half D1 for extras. This problem is still present in RB 0.62.

A solution that works is to change the encoding of the problematic cell to CBR

As jdobbs seems to have its hands full trying to ironing out more traumatic bugs, maybe you could find a way to be able to select CBR for all cells below 60 frames in RBOpt.

The only way I´ve have found up to now, is to manually edit the REBUILDER.ECL file, but it can be real tiresome when you have a lot of this cells (it happens in some movies).

If you can choose the CBR bitrate for this segments, better (as ussually they are just blank black frames, a low bitrate - say 1000 - does not cause any harm

A problem could be ussually this small cells are within a VOBID toghether with other cells, which VBR settings we would like to maintain.

Thanks for a great application.

Pablo

[robot1]

I remember Jdobbs planned to encode small segments as CBR - hope I'm not wrong.
Let's wait tonight DVD-RB release: if it's a common CCE bug, I think he will fix it.

[govenar]

I'm using RB-Opt v0.15 beta, DVD Rebuilder v0.67, CCE SP 2.67.00.27.
I noticed a few problems and have some questions:

1. When I click "Reset Bitrates" in RB-Opt, it crashes.

2. When "Hide Vob-IDs of insignificant size" is unchecked, RB-Opt won't let me change the bitrate of these small Vobs ("Autosized" is checked and greyed out so I can't change it). Is this a bug or is there some reason why this isn't possible?

3. The reason I care about #2 is that I want to use no compression for some of those small Vobs (i.e. set "Reduction" to 100%) (while still compressing all the other Vobs). If that's all I want to do, is there an alternative method I could use if #2 can't be changed?

4. The Duration shown by RB-Opt is 162 minutes, but the correct time is 129 minutes. I guess this is related to 23.976/29.97 fps. (Also when I view a Preview, it's played at the wrong speed, and the external player also shows the wrong 162 minute time.) The final DVD output is fine so it's not a huge deal, just annoying.

5. Does linking Vob-IDs increase quality even if I don't tweak any bitrates? (So, if I ran RB-Opt and just linked some Vob-IDs and changed nothing else, would the results be better than DVD Rebuilder without RB-Opt?)

6. Are there any disadvantages to linking Vob-IDs? i.e. will it mess up any menu navigation or chapter selection? Does linking Vob-IDs change the structure of the final DVD, or does it only affect the encoding step?

If the answer to #5 is yes and to #6 is no, then should I link every Vob-ID, even if they're not really related? The one downside I can think of is that it makes it harder to use different reduction amounts for the different Vob-IDs (but that can still be done with Tweak Cells, right?).

[robot1]

1. Could you send me the rebuilder.ini and rebuilder.inf files?
I can't reproduce the crash. PM me for details.
2. Small VodID doesn't take much space, so I prefer leave them untouched, as DVD-RB decided. To change their bitrate, you have to uncheck "hide vod-id..." as you noticed
3. 100% doesn't means "no compression". You will do a CCE pass, using the same bitrate of the original cell. If you want the original cell, it's not simple! You have to demux the original .m2v stream from the VOB. RB-Keeper did this job, but I think it's not compatible with current DVD-RB.
4. Yes, duration is wrong. As I'm in PAL land, I've a question: is it always wrong? DVD-RB reports always a 23.976 framerate, so RB-Opt is wrong in calculation. Are DVD's *ALWAYS* at 29.97, so it's safe to use always a framerate of 29.97?
The same thing happens for the external player.
DVD-RB uses the right framerate in remuxing, so the output will be always fine.
5. Linking Vob-ID is useful (and "mandatory") if you tweak single cells, but it cause no harm. It can be used to group items, and doesn't mess navigation. It affects only the bitrate distribution.

[berndy2001]

Originally posted by robot1
3. 100% doesn't means "no compression". You will do a CCE pass, using the same bitrate of the original cell. If you want the original cell, it's not simple! You have to demux the original .m2v stream from the VOB. RB-Keeper did this job, but I think it's not compatible with current DVD-RB.


in the new RB 0.70, there is a mode called "No Compression". you can use it, to demux your dvd. just copy the m2v-files of your chice to another folder.
(if you are not a vip, use the ReJig-Mode.)

after encoding copy them back.
don't forget to set the related cells in rb-opt to 100%

[robot1]

Originally posted by berndy2001
in the new RB 0.70, there is a mode called "No Compression". you can use it, to demux your dvd. just copy the m2v-files of your chice to another folder.
(if you are not a vip, use the ReJig-Mode.)

after encoding copy them back.
don't forget to set the related cells in rb-opt to 100% :goodpost:

[govenar]

Originally posted by robot1
2. Small VodID doesn't take much space, so I prefer leave them untouched, as DVD-RB decided. To change their bitrate, you have to uncheck "hide vod-id..." as you noticed
The problem is that even after I uncheck "hide vob-ids...", it won't let me change the bitrate. Autosized is checked, and greyed out so that I can't uncheck it. (And OPV is selected. I tried checking "Enable OPV for small Vob-IDs" but that didn't help; the VBR/OPV options are greyed out so I can't change them.)
3. 100% doesn't means "no compression". You will do a CCE pass, using the same bitrate of the original cell. If you want the original cell, it's not simple! You have to demux the original .m2v stream from the VOB. RB-Keeper did this job, but I think it's not compatible with current DVD-RB.
Ok.. I guess in addition to swapping the .m2v files as berndy2001 suggested, I could also just edit the final dvd image later with a re-authoring program to replace the vobs (assuming that I can get around the above problem and set reduction to 100% so they'll be the same size).

With this new RB 0.70 "No Compression" mode, could RB-Opt apply that to only certain Vob-IDs while still compressing others?
4. Yes, duration is wrong. As I'm in PAL land, I've a question: is it always wrong? DVD-RB reports always a 23.976 framerate, so RB-Opt is wrong in calculation. Are DVD's *ALWAYS* at 29.97, so it's safe to use always a framerate of 29.97?
If you always use 29.97 then that will break PAL DVDs? You could add a button to RB-Opt to let the user choose between NTSC & PAL.
Or, could RB be modified to save the original frame rate somewhere like rebuilder.ini so that RB-Opt can read it?
5. Linking Vob-ID is useful (and "mandatory") if you tweak single cells, but it cause no harm. It can be used to group items, and doesn't mess navigation. It affects only the bitrate distribution.
If I don't tweak single cells though, then linking won't affect anything? So I shouldn't bother to link them unless I tweak a single cell?

[jdobbs]

4. The Duration shown by RB-Opt is 162 minutes, but the correct time is 129 minutes. I guess this is related to 23.976/29.97 fps. (Also when I view a Preview, it's played at the wrong speed, and the external player also shows the wrong 162 minute time.) The final DVD output is fine so it's not a huge deal, just annoying. All NTSC files are set to 23.976 when encoding -- this is purposeful and is part of the solution for properly encoding hybrid (23.876/29.97) sources. DVD-RB resets the output speeds back to those in the original source during "REBUILD". It's a lot less "annoying" than an incorrectly encoded movie.

[jdobbs]

4. Yes, duration is wrong. As I'm in PAL land, I've a question: is it always wrong? DVD-RB reports always a 23.976 framerate, so RB-Opt is wrong in calculation. Are DVD's *ALWAYS* at 29.97, so it's safe to use always a framerate of 29.97? No. Because sources that are telecined only have 23.976 frames physically present in the MPEG stream for each second -- even though the the playback may be at 29.97. The additional pseudo frames are generated from those existing and inserted only to meet the NTSC standard fps. When played back through a progressive player/monitor -- the playback is at 23.976, resulting in a superior picture that matches the original film source.

[robot1]

Originally posted by govenar
Ok.. I guess in addition to swapping the .m2v files as berndy2001 suggested, I could also just edit the final dvd image later with a re-authoring program to replace the vobs (assuming that I can get around the above problem and set reduction to 100% so they'll be the same size).
You can swap the .m2v files without harm. The settings are grayed out because for short segments DVD-RB uses CBR instead of VBR, so it's not modifiable.
Size is small and you'll have no problems.


With this new RB 0.70 "No Compression" mode, could RB-Opt apply that to only certain Vob-IDs while still compressing others?

It's not possible: The prepare phase is different when you use "No compression" from the normal one.


If I don't tweak single cells though, then linking won't affect anything? So I shouldn't bother to link them unless I tweak a single cell? If you don't tweak single cells, you don't need to link.

[MAPE]

My question refers that I did some encodes tweaking the end credits bitrate and after saving the changes in Rb-opt, I opened the .Ecl in notepad and noticed that the avg bitrate for this cell was not modified. I linked all Vts in rb-opt and decreased bitrate of the last cell to 1800 avg. and when checked in notepad still was over 2800. Other parameters like CCE's filters, quality precission, bias were correctly modified and saved except the one concerning bitrates.
Tks.

[robot1]

Originally posted by MAPE
My question refers that I did some encodes tweaking the end credits bitrate and after saving the changes in Rb-opt, I opened the .Ecl in notepad and noticed that the avg bitrate for this cell was not modified. I linked all Vts in rb-opt and decreased bitrate of the last cell to 1800 avg. and when checked in notepad still was over 2800. Other parameters like CCE's filters, quality precission, bias were correctly modified and saved except the one concerning bitrates.
Tks. What if you open the Rebuilder.inf you've saved in RB-Opt again?
Do you find the modified value (1800)?
It's the fastest way to check.
I haven't tested RB-Opt with the newer versions of CCE. Probably I'll post an updated version next week (now working to ECLPro...)

[robot1]

This is an intermediate version, just with a bugfix and initial
support for CCE 2.70 (OPV mode).
I hope for the weekend to have a full CCE 2.70 support.

CHANGES:
- Added compatibility to CCE 2.70 in OPV mode
- Fixed a bug in "Reset Bitrates" options
- Added QLB matrix (used in QuEnc by Nic and Dragongodz)


KNOWN ISSUES
- Filters don't work properly with CCE 2.70. Please, avoid filters usage with this CCE version.
- Quantizer Characteristics for CCE 2.70 limited to 64 (and not to 100).

RB-Opt v0.16 (http://dvd-rb.dvd2go.org/modules.php?name=Downloads&d_op=getit&lid=23) Mirror by DVDRebuilder.com

[archaeo]

...support for CCE 2.70 (OPV mode).

and it works very well in OPV! :D
a great tool.

As I mentioned in another thread, I noticed some undersizing issues at low Q-values using Rebuilder with CCE 2.70. Using RB-Opt, the same project came in perfectly at 4.32 Gb.

[TheSeeker]

Originally posted by archaeo
and it works very well in OPV! :D
a great tool.

As I mentioned in another thread, I noticed some undersizing issues at low Q-values using Rebuilder with CCE 2.70. Using RB-Opt, the same project came in perfectly at 4.32 Gb.

I had the exact same experience with 2.70. My dvd came in at 3.59 gb using dvd rb's prediction. With rb-opt using double pass prediction it came in at 4.33!! This tool just keeps getting better and better.

[robot1]

:)

[kheops]

hi all :)

i think i'll mainly use RB-Opt to use custom matrices (the one from the original dvd)
is there a program to extract this matrice from a vob file AND create a valid matrice file for RB-Opt ?

many thanks

[robot1]

I know of just one program to check matrices:
Restream (http://shh.sysh.de/restream.html)
Anyway it needs the .m2v or .mpv file, so you have to demux a VOB to check the matrices.

The format of the eclpro matrices is simple: it's plain text starting with a tab, and then a row of the matrix.
Example:

08 16 20 23 27 30 32 34
16 16 23 24 29 31 34 38
20 23 27 28 30 35 38 40
23 24 28 29 35 39 40 44
27 29 30 35 39 42 45 50
30 31 35 39 42 46 54 59
32 34 38 40 45 54 62 72
34 38 40 44 50 59 72 84
17 19 21 23 25 27 29 31
19 21 23 25 27 28 29 33
21 23 25 27 29 30 32 37
23 25 27 30 31 34 40 45
25 27 29 31 38 46 54 60
27 28 30 34 46 58 72 74
29 29 32 40 54 72 90 100
31 33 37 45 60 74 100 124

The first 8 lines are the one of the intra matrix.
The second 8 lines are the non intra matrix.

[kheops]

thanks robot1 for your answer :)

i might give you this link :

http://www.dvdcreation.net/download.php?id=4776

Matrix Extractor v1.10 is really great and allow extracting the matrices from a vob file and export them in the registry or in plain text

before encoding i've used this setting in my rebuilder.ecl file

qmat=
08 08 09 11 13 13 14 17
08 08 11 12 13 14 17 18
09 11 13 13 14 17 17 16
11 11 13 13 13 17 18 20
11 13 13 13 16 17 20 24
13 13 13 16 17 20 24 29
13 12 13 17 19 23 28 34
12 13 17 19 23 28 34 41
08 08 08 09 09 09 09 10
08 08 09 09 09 09 10 10
08 09 09 09 09 10 10 10
09 09 09 09 10 10 10 10
09 09 09 10 10 10 10 11
09 09 10 10 10 10 11 11
09 10 10 10 10 11 11 11
10 10 10 10 11 11 11 11

in the vob files created, the matrices are

8 8 8 8 8 8 8 9
8 8 8 8 8 8 9 9
8 8 8 8 8 9 9 8
8 8 8 8 8 9 9 10
8 8 8 8 8 9 10 12
8 8 8 8 9 10 12 15
8 8 8 9 10 12 14 17
8 8 9 10 12 14 17 21


8 8 8 8 8 8 8 8
8 8 8 8 8 8 8 8
8 8 8 8 8 8 8 8
8 8 8 8 8 8 8 8
8 8 8 8 8 8 8 8
8 8 8 8 8 8 8 8
8 8 8 8 8 8 8 8
8 8 8 8 8 8 8 8

i'll try to investigate, if you could give me a hint :)

edit : i've used cce to encode

[robot1]

CCE version used?
If you load the .ecl with CCE, can you check if the matrix is correct?
Can you try encoding with RB-Opt and selecting one of the enclosed matrices, if the result is correct?

[kheops]

cce is 2.70.01.05
the ecl loads fine in cce and the matrices setting is correct (the "preset" choice is empty)

i'm doing encoding right now, will give the results

[robot1]

CCE 2.70 has an "Adaptive Q Matrix switching".
I don't know if it can change the matrix automatically... anyway, I'll add an option to disable this behaviour.

[RitchieMad]

An EXCELLENT and friendly tool...
I couldn't get right output size on my In Extremo DVD, but once I used RB and set higher bitrate I hit 4.6Gb size. I was lucky, but that's also a proof this tool works!

[kheops]

2nd encoding, same result

each item in my ecl file IS correct, the matrix is the one i want to use
once created, each m2v file is NOT correct, i already gave my example above (afterwards the vob file has the same matrix but isn't a surprise)

your idea was right, i checked the "Disable adaptive Q-matrix switching" box just for one item and get a correct m2v file :)

in my ecl file, for this item, "q_scale_type=1" is replaced by "q_scale_type=0" so i think the solution isn't too hard to implement, one has just to decide if he want to use this feature or not

what the pdf says about this setting :

Disable adaptive Q-matrix switching

Cinema Craft Encoder SP (later than 2.67) adjusts quantization matrix
automatically to improve the quality of image when Multipass
VBR is selected. However, some DVD player does not support such
MPEG streams as encoded with adaptive quantization matrix, and
may cause the block noise when playback. When you encounter the
problem, you can avoid it with this option.

What is adaptive Q-matrix switching ?

There are some cases that Cinema Craft Encoder SP cannot keep
the minimum bitrate. It is considered to be caused by that the lowest
quantization scale cannot raise the bitrate under a single quantization
matrix. To solve the problem, Cinema Craft Encoder SP automatically
creates other matrices cutting the value of each element in the
matrices by half, quarter and so on, and applies another one to produce
a much lower distortion for much higher bitrate. This switching
of quantization matrix can occur at every GOP.
Thus, adaptive Q-matrix switching can improve the quality of image,
especially with lower bitrate sources or CG works or the edge of
fading out.

thanks for your support :)

[SlipGun]

I'd like to echo Xuvio's post from August 2004. RB-Opt would be perfect if it had the ability to modify bitrate by frames and not just cells. I would think the best way to do this would be to have an in-program player to preview a cell, much like in Vobblanker, where you can select start- and end-points.

I don't know how much effort this would require in the way of programming, but it would be a great option to have, whenever it may be possible - if it is at all.

[jptheripper]

wow frame by frame bitrate editing? i cant ever see doing that.

for me the one thing rb-opt needs is the ability to remove a vts for reencoding (ah lal the now defunct rb-keeper). That would be ideal

[jdobbs]

Remove a VTS for reencoding? Explain.

[jdobbs]

Originally posted by SlipGun
I'd like to echo Xuvio's post from August 2004. RB-Opt would be perfect if it had the ability to modify bitrate by frames and not just cells. I would think the best way to do this would be to have an in-program player to preview a cell, much like in Vobblanker, where you can select start- and end-points.

I don't know how much effort this would require in the way of programming, but it would be a great option to have, whenever it may be possible - if it is at all. Bitrate allocation by frame... that's what the encoder does during VBR -- you really don't want to mess with that...

[robot1]

Originally posted by SlipGun
I'd like to echo Xuvio's post from August 2004. RB-Opt would be perfect if it had the ability to modify bitrate by frames and not just cells. I would think the best way to do this would be to have an in-program player to preview a cell, much like in Vobblanker, where you can select start- and end-points.

I don't know how much effort this would require in the way of programming, but it would be a great option to have, whenever it may be possible - if it is at all. The smallest encoding unit in DVD-RB is the segment (usually a cell), so I can't change parameters for smaller units (the risk to screw things up is really high).
Anyawy, the bitrate gain would be relly negligible.

[robot1]

Originally posted by jptheripper
for me the one thing rb-opt needs is the ability to remove a vts for reencoding (ah lal the now defunct rb-keeper). That would be ideal I'd like to have an option "no compression" ... I hope in an interaction with pgcdemux, one day.

[archaeo]

robot1,
I usually do tweaks after the RB prepare phase using RBOpt, but hardly ever do any adjustment after the encoding phase. For long projects I run the encoding phase right before I go to bed and then click the Rebuild phase to complete the process before I go to work. I do not have much time to look at the final product until I get home from work. It would be great to have a 2 click option, Prepare + Encoding/Rebuild combined, with shutdown on completion. Can this be setup as a feature in RB-Opt?

[robot1]

Originally posted by archaeo
robot1,
It would be great to have a 2 click option, Prepare + Encoding/Rebuild combined, with shutdown on completion. Can this be setup as a feature in RB-Opt? I don't think of 2 click option as a feature of RB-Opt... I'd prefer as a feature in DVD-RB.
I think jdobbs will add it... in the meantime I could code a little app to automates the Encoding/Rebuild/(optional)Shutdown - but I'm working to release RB-Opt 0.17 with CCE 2.70 support.

[blueboyec]

archaeo,

Alot of people do it that way, me included. Many have asked that RB have this option but to no avail.:( It would be great if jobbs would gave RB this option! But if RB-Opt could do it that would be great too.

Blueboy

[jdobbs]

I hear you... I've just been concentrating on clearing up bugs and inconsistencies lately, so features have taken a back seat. I'm trying to get to v1.0 before the next turn of the century.

[jptheripper]

Originally posted by robot1
I'd like to have an option "no compression" ... I hope in an interaction with pgcdemux, one day.

yeah sorry for my incoherency. I would love to, say, be able to set a vts at 100% (original size) and have it completely not encoded.

This would be ideal for situations when renecoding xtras and removing languages (but leaving the main movie intact) is sufficient to get to dvd5 size.

[Whitespliff]

Originally posted by jptheripper
I would love to say, be able to set a vts at 100% (original size) and have it completely not encoded.Yeah, that would come in handy.

The 2 click feature would be great too :D

[robot1]

New version:
RB-Opt v0.17 (http://www.freewebs.com/robot1/RB-Optv0.17.zip) (right click -> save target as).
Later there will be other mirrors...

Changelog:
Full CCE 2.70 support:
- added switches: "Disable Adaptive Q matrix switching" and "Fades on a static scene"
- added support to CCE 2.70 filters.

ProCoder (EclPRO) is detected and only relevant options are showed.

Added "Block Scan Order" & "Progressive" options in CCE Options
NOTICE:
Don't change these setting unless you know what you are doing... else you will have a bad output.
These settings can be used for PAL films (progressive), encoded as interlaced - you can force DVD-RB to
encode them as progressive (likewise the "Disable interlaced" in the "AVS Options" in DVD-RB).
NTSC users should NEVER change the default values.

[berndy2001]

hello, im not able to download the file. i always get redirected back to the thread. (the browser download the html-code of the forum)

if you want, i can provide a mirror.

[pg55555]

berndy2001

Do not Left click on the link. RIGHT click and select "Save target as.." as indicated by Robot1

[berndy2001]

i did that, i get a file, which contains the html-code of this thread.
im using firefox.

robot1 will mail it to me.

[robot1]

Mirror
DVD-RB v0.17 (http://dvd-rb.sun.priv.at/RB-Optv0.17.zip)

This should work with every browser.
Thanks to berndy2001

[archaeo]

robot1,
I've been looking forward to this one! Thanks for all the hard work ;)

[Rockas]

@Robot1

When using a custom matrix (made for CCE) on RB-Opt it doesn't accept the first value if it is a "16", can you explain me why?

[robot1]

I think the first value should be 8 (Edit: for intra matrix)
Am I wrong?

[Rockas]

Well I don't know anything about that but I'm using a custom matrix from a Brazilian forum and the first value is a "16"... CCE accepts it RB-Opt doesn't.

[robot1]

I've checked.
From CCE SP 2.70 manual:
(1, 1) element in intra block must be 8 under MPEG standard.
I think the first element should be 8

[Rockas]

That's explains it... thanks

edit: what would be the problems if the value 16 is used?

[robot1]

If it's not in MPEG standard, I think some players could give problems.

[Rockas]

OK.. thanx I'll keep that in mind.

[archaeo]

robot1,
In v17, which command line enables 'fades on a static scene' in the ecl script? What should it read when I've enabled it?

thanks

[raddygast]

Ok, this could be a retarded question, but...

How do you install RB-Opt? Do I just make a directory for it? That would seem to be the case but there is a .zip within the archive called RB Opt Matrices or something. Do I have to extract that into the RB Opt directory too, or can RB-Opt somehow read the zip?

[TheSeeker]

Yea just make a directory for it and unzip the matrices directory inside that one. you dont NEED to do this for rb opt to work, but you must unzip them to be able to load those matrices into rb-opt and use them with CCE.

[robot1]

Originally posted by archaeo
robot1,
In v17, which command line enables 'fades on a static scene' in the ecl script? What should it read when I've enabled it?

thanks Sorry for the late reply... I didn't read before your post.
Anyway, you've found a bug: the setting simply isn't saved
:(
It will be fixed for next release.

You should find a line
no_move=
with 0 (default) or 1 (enables fades on a static scene)

I don't think is useful in RB-Opt (or in general with CCE) to enable it.
If you use CCE for a single encoding (not in DVD-RB) you should enable it just for the section where you can see the fades on the static scene.

[archaeo]

You should find a line
no_move=
with 0 (default) or 1 (enables fades on a static scene)

robot1, thanks for the reply. So, I can just add this line manually where needed, until the revision?

edit: apparently NOT in RB yet, only in CCE directly.

[raddygast]

Can someone tell me what the Link VOB-Id step is supposed to do? Would greatly appreciate it. My main film is just one vob-id (VTS 1 Vob-id 1).

Also, the option under DVD-RB (Mode menu) that says "steal space from extras". Is that option already in use, so to speak, when I open RB-Opt? I notice that everything but the main title is at a bitrate of about 1459, whereas the main title is set to around 3000.

Oh yeah, and is there a discussion of the matrices I can use somewhere? When I select a matrix, it shows as "Custom" but doesn't really give it a name. Would be nice if it showed the actual file name of the matrix you browsed for.

I heard AngelBestLow is really good for low low bitrate extras (like 1000-1500 bitrate). What should I use for a main movie hovering around 3100?

[TheSeeker]

The link vob-id step combines all vob-id's into one entry in rb opt so you can apply settings to all at once instead of one at a time. If you didnt select the steal space from extras mode before the prepare phase then no the steal space from extras option should not be in use. As for matrices I normally use kvcd notch or bach1 for low bitrates (2500-3000 or less) anything more than 3000 u can use the official ultra low or very low bitrate matrices that come with cce.

[raddygast]

Anything more than 3000 use the ultra low matrix that comes with CCE? I thought above 3000 was no longer low bitrate?

What would you use for a main movie around 3200? Maybe I should just use the standards until I know what I'm doing better than I do now.

[Boulder]

I'd give QLB a go, it should look very good at ~3000kbps. I wouldn't touch any of the matrices included with CCE:D

[TheSeeker]

Originally posted by Boulder
I wouldn't touch any of the matrices included with CCE:D

Yea cause they just make one of the best mpeg2 encoders on the planet. What do they know?

@Raddygast

According to the CCE manual anything right around 2500-4000 bitrate area use Very low bitrate, anything lower than that use ultra low bitrate. I have noticed bach1 and kvcd notch are also very good matrices. But those are more for really really low bitrates i think. I use them for like 2000-2500 area.

[Boulder]

Originally posted by TheSeeker
Yea cause they just make one of the best mpeg2 encoders on the planet. What do they know?

@Raddygast

According to the CCE manual anything right around 2500-4000 bitrate area use Very low bitrate, anything lower than that use ultra low bitrate. I have noticed bach1 and kvcd notch are also very good matrices. But those are more for really really low bitrates i think. I use them for like 2000-2500 area.
Well, if you look at the values in both "Low Bitrate" and "Ultra Low Bitrate", you'll see that the bitrate reduction is done by cutting off all the high frequencies. You'll get a nice ringing effect and lose a lot of details as well.

Suit yourself:rolleyes:

[artoor]

Originally posted by Boulder
Well, if you look at the values in both "Low Bitrate" and "Ultra Low Bitrate", you'll see that the bitrate reduction is done by cutting off all the high frequencies. You'll get a nice ringing effect and lose a lot of details as well.
Suit yourself:rolleyes:

I have a question. Does RB-Opt defaultly load "Standard" matrix even if bitrate can be below 3500kbps?? Or it is "intelligents" enough and it selects right Matrix according to bitrate (without my knowledge)??

[Boulder]

I think it uses the CCE default, but I'm not 100% sure. It might also depend on the default template you have in CCE.

[TheSeeker]

It uses the "Standard" matrices by default. It does not select a different matrice automatically. You have to do that yourself. Im guessing this is because everyone likes to use different matrices for different situations ya know.

[robot1]

RB-Opt uses the standard matrices in default, because DVD-RB doesn't change the default CCE matrix. It doesn't depend from the default template, because DVD-RB overrides it.

[artoor]

Ok. Now I understand it :) Thanks for every answer. So far I've used standard matrix... maybe it's high time to try something else with better result. I should experiment with another matrices :)
Once again - thx!

[raddygast]

Any chance on a new version of RB Opt soon -- one that is compatible with the new changes in DVD-RB Pro (i.e. setting up matrix preferences in RB itself).

[robot1]

We have had many features added in DVD-RB, and other will be added before 1.0 (probably multi-angle compression, menu handling...)
I don't know if it's better to update RB-Opt every DVD-RB release, or wait for the 1.0 and have a full update.

[raddygast]

Well can I ask you one question then?

When I go into RB Opt (loading the REBUILDER.INF after a given project's prepare step), if I click on a vobid, and then click the CCE Settings button, what does that read exactly?

I'm asking because I'm wondering how it reports the quantization matrix. With RB's new options, I take it if RB specifies a specific matrix, RB Opt will read that as "Custom" unless RB leaves it at Encoder Default (standard).

But talking with jdobbs he said that all qmat decisions (i.e. when to use the matrix you define for "low bitrate" or the matrix you define for "Very low bitrate") are made on the SEGMENT level, not the whole VTS or vobid level.

So in that case, how does RBOpt make the assessment that something is "Custom"? Does it basically check every segment within the vobid, and if just one of them is not set to "Standard" then it reports it as "Custom"?

I was working on The Pianist, disc 1. After the prepare step it seems there is just one VTS and Vobid (with a crapload of cells in it). The overall avg. bitrate is 2997, but if I remember correctly when I checked CCE Settings it wasn't Low Bitrate, it was Standard. So I'm still a bit confused. jdobbs says the bitrate is not based on the avg bitrate of the whole titleset, but on the bitrate of each segment.... but I don't think you can view the bitrate at the segment level in RB Opt. But in the ECL files I guess each item can have its own bitrate and qmat associated with it.

[robot1]

RBOpt checks the matrix used in the last cell for every VobID.
Probaly it shows "custom" because DVD-RB doesn't use the hardcoded matrices in CCE, but it writes them every time (but I haven't yet checked the rebuilder.ecl from the last version).
As now matrices could change for every cell, I have to re-think the whole interface, allowing to change them on a cell basis (???)

Anyway, as jdobbs has added so much features in the new releases, I see always less need to use RBOpt...
Waiting for users' suggestions.

[raddygast]

I would hate to stop using RBOpt. AT the very least I like to use RBOpt to check in on things and make sure they're ok. Sometimes I also don't use steal space from extras, because some of the extras (deleted scenes, etc.) I don't want to have reduced quality on, but other extras I don't mind. So I manually reduce the bitrate in RBOpt (and check/uncheck autosize accordingly). I also like to change targetsectors, but I think that can be changed once and for all in rebuilder's ini file anyway.

Ok, so it reports the LAST cell's bitrate. I knew it was showing custom because RB was hard coding matrices -- but didn't know how it decided what was what. That piece of knowledge helps me understand things.

I do hope you continue to develop RBOpt, though, but I can understand if it's not a priority for you. But yeah, changing matrices on a cell level would seem to make sense now.

[Smurf1127]

@robot1

I still see a need for RB-Opt because RB doesn't allow specified bitrates yet. I do agree that you may want to wait until RB has hit 1.0 will all the features that soon will be out, than intergrate Opt along with these new features. I use this program every time I do a backup and find it gives me freedome to customize my bitrates which is really nice.

Thank you for your hardwork

|Papa|

[Zyphon]

@robot1

I still see a need for RB-Opt because RB doesn't allow specified bitrates yet. I do agree that you may want to wait until RB has hit 1.0 will all the features that soon will be out, than intergrate Opt along with these new features. I use this program every time I do a backup and find it gives me freedome to customize my bitrates which is really nice.

Thank you for your hardwork

|Papa|

I completely agree with you, I definately think there is still a need for RB-Opt, I always use it after the Prepare phase and i'm thankful that JDobbs has always left the 3 button mode in DVD-RB.

I like to mess around with specific bitrates of certain VOBID's and DVD-RB combined with RB-Opt gives me excellent results.

I also think it may be a good idea to wait until DVD-RB Pro hits 1.0 Final. :D

[robot1]

An updated version.
Need testing, so please report any bug you find.
Download RB-Opt v0.18 (http://www.freewebs.com/robot1/RB-Optv0.18.zip) (right click -> save target as)
I hope to add soon a mirror, as sometimes there are problems to download from this host.

Changelog:
DVD-RB PRO support
Added compatibility to Rockas' Matrix Editor, and to the .mtx format for matrices
Fixed bugs in CCE 2.70 support
Moved "Fades on a static scene" switch in the "Tweak Cells" dialog (It's better to use for first scene and end credits, in my tests)
Added Goplength 18 options for NTSC interlaced sources

[Rockas]

I can't download it :(

@Robot1
Can you send me a copy by mail... I'll host it on www.dvdrebuilder.com.

[robot1]

@Rockas
sending right now.

[Rockas]

Done.

Download link: HERE (http://dvd-rb.dvd2go.org/modules.php?name=Downloads&d_op=viewdownload&cid=24)

[Rippraff]

@robot1
Nice to hear! :)
Did you change the behavior that RB-Opt looks only for the matrix in the last cell of a VOB-ID?

Edit: 2. Download link works! Thanks Rockas! :)

Cu Rippraff

[robot1]

@Rockas
Thanks. I will update the first post with your link.

@Rippraff
if you want a right prediction, you can't use different matrices in the cells of a single VobID.
RB-Opt asks you to choose one single matrix (same thing for other parameters, like dc precision and goplength).
It's not a limitation, it's the only way to have a good prediction. Anyway, OPV is meant to have a constant quality for the whole film (with a single Q). If you have different parameters, the quality would not be constant.

[djan]

Rb-Opt 18 closes when I load RB settings. Doesn't happen with 17b.

[Rippraff]

@Rippraff
if you want a right prediction, you can't use different matrices in the cells of a single VobID.
RB-Opt asks you to choose one single matrix (same thing for other parameters, like dc precision and goplength).
It's not a limitation, it's the only way to have a good prediction. Anyway, OPV is meant to have a constant quality for the whole film (with a single Q). If you have different parameters, the quality would not be constant.
Thank you for pointing this out. :)
But I didn't think of OPV, I've asked because you posted this before:
RBOpt checks the matrix used in the last cell for every VobID.
Probaly it shows "custom" because DVD-RB doesn't use the hardcoded matrices in CCE, but it writes them every time (but I haven't yet checked the rebuilder.ecl from the last version).
As now matrices could change for every cell, I have to re-think the whole interface, allowing to change them on a cell basis (???)
Cu Rippraff

[Zyphon]

@Robot1

Thank you so much for this update. :)

I am happy to hear that it is now compatible with RB-Pro also as I love to use RB-Opt to do OPV prediction on the movie portion on my backups and this tool allows for so much tweaking to DVD-RB. :)

Great work Robot1, I shall do some tests and get back to you with my results. :D

Thanks again for the update.

[Zyphon]

Hi Robot1,

I am currently testing out the new version of RB-Opt with DVD-RB Pro 1.00 RC3.

I love the way the new version remembers the settings from DVD-RB like the cusum matrix you used the DC value and the GOP value.

Would it be possible in future for RB-Opt to remember the min and max bitrate values that you enter so that you don't have to enter them manually for every VOB-ID? Is this possible?

Thank you so much for making RB-Opt work with DVD RB Pro and for listening to us for our requests you are a great guy imo. :)

[robot1]

Rb-Opt 18 closes when I load RB settings. Doesn't happen with 17b.
You have a PM

[Zyphon]

You have a PM

Thanks, read and replied. :)

Keep up the great work. :)

[robot1]

Rb-Opt 18 closes when I load RB settings. Doesn't happen with 17b.
My bad.

There was an error with DVD-RB FREE version (I tested only the PRO one,
and I didn't realize there are some slight differences in the files between the two versions).
I've fixed the bug, but I need other testing (I don't know if it saves some CCE 2.70 parameters...).

Tomorrow I will update RB-Opt.
Waiting for RB-Opt 0.19, DVD-RB free users should use the previous version.

[jdobbs]

Hmm... I'm trying to keep them compatible except for the Pro extensions (like ILVU). What was the difference you found?

[robot1]

My mistake was right on the ILVU parameter. Now I've corrected it.
Anyway, in the .ecl there are some CCE 2.70 parameters missing:
intra_dc_precision_9_max=113
intra_dc_precision_10_max=113

[TuRiSOft]

Possible issue :
RB-Opt does auto-check OPV on all ILVU segments and VBR not selectable!!! When I go saving it tries to calculate Q factor and gives an error (don't remember what it says).

[robot1]

Possible issue :
RB-Opt does auto-check OPV on all ILVU segments and VBR not selectable!!! When I go saving it tries to calculate Q factor and gives an error (don't remember what it says).
Thank you for your report.
I think I've solved this bug.

I'm testing right now, and I hope to release the new version in a few hours (or tomorrow)

[Zyphon]

Just tested RB-Opt 0.18 beta with DVD-RB Pro 1.00 RC3 and it worked o.k and I am pleased with the output.

Like I said earlier I love the way the new RB-Opt remembers what matrix you have selected in DVD-RB Pro very cool indeed as is the fact that DVD-RB Pro let's you select your matrix it makes life so much easier.

Thanks guys Robot1 & Jdobbs great work. :)

PS: Look forward to testing the next version of RB-Opt. ;)

[Zyphon]

@Robot1

Having done a very quick test with the new 0.19b version, it now remembers the bitrates you used so thank you for adding that feature.

However this version does not remember the Matrix you selected in DVD-RB Pro and you have to set the matrix for all the VOB-ID's manually.

Version 0.18b remembered the matrix that you selected in DVD-RB. Is this a bug?

Hope to hear from you soon. :)

[djan]

@Robot1

Having done a very quick test with the new 0.19b version, it now remembers the bitrates you used so thank you for adding that feature.

However this version does not remember the Matrix you selected in DVD-RB Pro and you have to set the matrix for all the VOB-ID's manually.

Version 0.18b remembered the matrix that you selected in DVD-RB. Is this a bug?

Hope to hear from you soon. :)Where is 0.19b ??

[robot1]

0.19b will be released soon.
Zyphon and I were testing some changes...

[berndy2001]

Thank you for the new Version!

I hope to add soon a mirror, as sometimes there are problems to download from this host.
For the future: i can give you some webspace including an ftp-account, or you can upload it to rapidshare (http://www.rapidshare.de/) (or other upload services).

[robot1]

However this version does not remember the Matrix you selected in DVD-RB Pro and you have to set the matrix for all the VOB-ID's manually.

It's not a bug.

In CCE Settings, the matrix combo is filled if all the cells of the VobID have the same matrix.
If the matrix is one of the CCE internal, or the matrix is in the matrix folder, you will find the name of the matrix displayed.
If the matrix is selected in another folder, you will find the indication "Custom"

If the matrix combobox is blank, DVD-RB has chosen to use different matrices for the cells (it's an option in DVD-RB PRO: you can chose to use different matrices according to the bitrate of the cell).
If you leave the combo blank, RB-Opt will not change the choice made by DVD-RB. Anyway, if you want to use OPV, you HAVE TO chose ONE matrix per VOB-ID (if you use different matrices, the prediction could never be good).

The same things apply to GOPLength and DCPrecision: if you see no check for those parameters, DVD-RB has chosen to use different values for the cells.

[Soshen]

but it have some problem whit ccesp?
it possible that it work only mading CCE in CBR 1pass mode?

[robot1]

but it have some problem whit ccesp?
it possible that it work only mading CCE in CBR 1pass mode?
Please, check your PM.

What version of CCE are you using?
Does DVD-RB works without RB-Opt?
(usually RB-Opt doesn't change the encoding type...)

[Rockas]

@robot1
by the way... it would be nice if you update the thread title :D

[robot1]

:)
I'm waiting for the 0.19

[robot1]

Here is the update:
RB-Opt v0.19 (http://rapidshare.de/files/3623928/RB-Optv0.19.zip.html)

(thanks to Berndy2001 for the suggestion!)

Changelog:
Bugfix: restored DVD-RB Free compatibility (broken in v0.18)
Fixed wrong VBR/OPV behaviour with short segments (thanks to TuRiSOft)


Thanks to all the betatester!

[robot1]

@robot1
by the way... it would be nice if you update the thread title :D
I've updated the title of the first post... but the thread title remains the same.
:(
How do I change the thread title? (I think something has changed till the forum change...)

[Rippraff]

Thanks for the new version! :)
I've updated the title of the first post... but the thread title remains the same.
:(
How do I change the thread title? (I think something has changed till the forum change...)
This is vbulletin 3.0.7 ;)
If I remember correctly, you can't change the thread title, you need to have moderator rights. This is how it works at german doom9 forum which uses the same board software. :rolleyes:
Edit: Here it works: Go to the first post => Edit => change the title => save
Edit2: Sorry, you mentioned that you've changed the first post, in my case it worked, here it didn't. :confused:

Cu Rippraff

[Soshen]

in vbulletin (maybe) only a moderator can change post topic

[jdobbs]

I changed it. That's an annoying "feature" of the new software. I ran into the same thing with the DVD-RB thread.

[Rockas]

I don't understand !?!?!?
I've been updating the Title of Rebuilder's Matrix Editor without any problems!?!?!?
... or is there someone doing that for me? :)

[Rockas]

By the way... I updated the download link on www.dvdrebuilder.com

it's, as usual:
http://dvd-rb.dvd2go.org/modules.php?name=Downloads&d_op=viewdownload&cid=24

[Zyphon]

It's not a bug.

In CCE Settings, the matrix combo is filled if all the cells of the VobID have the same matrix.
If the matrix is one of the CCE internal, or the matrix is in the matrix folder, you will find the name of the matrix displayed.
If the matrix is selected in another folder, you will find the indication "Custom"

If the matrix combobox is blank, DVD-RB has chosen to use different matrices for the cells (it's an option in DVD-RB PRO: you can chose to use different matrices according to the bitrate of the cell).
If you leave the combo blank, RB-Opt will not change the choice made by DVD-RB. Anyway, if you want to use OPV, you HAVE TO chose ONE matrix per VOB-ID (if you use different matrices, the prediction could never be good).

The same things apply to GOPLength and DCPrecision: if you see no check for those parameters, DVD-RB has chosen to use different values for the cells.

Hi Robot1,

Sorry I made a mistake.

Just tested again with three other DVD's and the matrix is fine and is listed as I set them up in DVD-RB.

Iwas an error on my part. It was late and I was tired when testing it, I realised I was pointing RB-Opt to a REBUILDER.INF that I wiped the original DVD source files from that is why it didn't see the matrix.

However it still doesn't remember the min and max bitrates I set for the previous VOB-ID and I have to again set the min a max bitrates manually.

I shall do some tests tomorrow with a full backup and post my results. :)

[robot1]

However it still doesn't remember the min and max bitrates I set for the previous VOB-ID and I have to again set the min a max bitrates manually.

If you have to change a setting for different VobIDs, you can try to link them ("Vob-ID Link" button) and change the parameters just one time.
Anyway I think now DVD-RB calculates always the right min&max bitrate (at least for me).

[Zyphon]

Hi Robot,

I read you PM you sent me regarding the disabling the "remembering the bitrates".

Check your PM. :)

[djan]

Hi Robot1,

Could you add some other options as Half D1 ? I know that we can add it editing avs file but it could be nice if the feature is directly available.

[Zyphon]

@djan

Do you mean Half D1 for the main movie? I know DVD-RB can do Half D1 for all the extras.

[Skunk]

Once I have gone through the prepare phase and used the preview/edit options to blank out some sections of the DVD they still show up in RB-Opt. Should I set the compression on them to the lowest setting or just ignore them? My main concern is that RB-Opt may override settings from DVD-RB and either not blank out the segment or that I may not get the full improvement in quality from the extra space gained.

If I am not clear just ask me what in sam hill Im talking about :)

[djan]

@djan

Do you mean Half D1 for the main movie? I know DVD-RB can do Half D1 for all the extras.For all VTS. I know that we can do it with DVD-RB for extras, but it could be nice to have it as an option in RB-Opt.

[SpazzHH]

For all VTS. I know that we can do it with DVD-RB for extras, but it could be nice to have it as an option in RB-Opt.
You can do it in RB for the Main Movie too.Options>AVS Options>Advanced (Expert) Options>Resize to Half D-1. Then choose the VTS of the Main Movie.

[Zyphon]

@SpazzHH

Thanks for the tip, I completely forgot about that. Thanks for the reminder. :)

[robot1]

For all VTS. I know that we can do it with DVD-RB for extras, but it could be nice to have it as an option in RB-Opt.
I think it's better to choose half D1 in DVD-RB: it's not only a matter of resize, but also changing some settings in the .ifo
Probably if DVD-RB expects a full D1 clip and finds a clip with HalfD1 resolution there could be problems, but only jdobbs knows this.
Anyway Half D1 is very well implemented in DVd-Rb-

[humax]

is there a bug in 0.19 ??
DVD-RB makes only 1 Pass when i edit settings with RB-Optimizer.
Or is DVD-RB RC 4.1 the error ???
When i dont use Optimizer it encodes right. ( 4 Passes like i want)

cu

[kabukijo]

hi,

Firstly like shumax stated, me 2 can confirm that when using rb-opt it only does 1 pass while i chose 3 passes through cce settings in rb-opt. Iam using dvd-rb 93.b, cce 2.70.02 and rb-opt 19.b. My biggest problem is oversizing whit no less than 300 - 400 mb!!! To make it fit on an dvd5 i was forced to delete some audio languanges afterwards very annoying. Ive read many stuff arround this pretty neat forum to overcome this issue but no vail. Ive done an couple of things theyve suggested like i applied VBR mode to all my files, through global options i reduced outputsize to 95%, i even changed VAF=1 to 0 in ECL , etc etc....but the output is always 300 a 400 mb to much!?! I realy hope theres an FINAL sollution to this, cuz i only can maintain Quality of full dvd9 if i can optimized it. Any suggestions R welcome to overcome this problem.


tnx in advance,

urs kab,

[robot1]

@all
If you experience a bug in RBOpt, please send me these files which are located in the D2VAVS subdir:
rebuilder.inf
rebuilder.ecl
rebuilder.inf.original
rebuilder.ecl.original

My email address is in the readme.txt file.
I can't repeat the bug. If I can find the bug, I can also fix it.
Thank you

[humax]

Hi
i send u my files.
Hope u can fix the problem - maybei its a RB Problem .
We'll see.

Great Work

[kabukijo]

hi,

U can count on me 2 for the files :script: ;)

[djan]

is there a bug in 0.19 ??
DVD-RB makes only 1 Pass when i edit settings with RB-Optimizer.
Or is DVD-RB RC 4.1 the error ???
When i dont use Optimizer it encodes right. ( 4 Passes like i want)

cuAre you sure you don't set OPV ? Choose VBR and verify the number of passes in CCE settings.

[humax]

hi
im sure not to used opv .
Its chosen VBR.

cu

[djan]

hi
im sure not to used opv .
Its chosen VBR.

cuSo verify the number of passes when pushing the button CCE Settings in RbOpt.

[humax]

its chosen 4 passes and he makes only 1 pass.
no vaf. und 3 passes only 1m2v pass. and thats not correct....

[djan]

Yes there is a problem.

[robot1]

I'm working to solve it.

[robot1]

New version:
RB-Opt v0.20 (http://rapidshare.de/files/3847011/RB-Optv0.20.zip.html)

This should fix the OPV-VBR error reported.
Thanks to humax and kabukijo for the reports.

[humax]

Nice Work

THX

[Rockas]

Alternative download link:
http://dvd-rb.dvd2go.org/modules.php?name=Downloads&d_op=getit&lid=23

[Zyphon]

Thanks for the update and bugfix Robot1, I will run some tests this weekend. :)

[kabukijo]

hi,

Robot1,

Iam glad to repport that the new update of the tool (rb-opt 20) works flawless thus sofar. I tested it on an Full dvd9 movie prox 7,39gb big with allot of noise (retouched/remasterd classic movie) and it works B-eatifull. Well, i only tested the VBR option in the tool no OPV selected. And i had no undersize nor oversize problems this time and the Quality is SUPERB something i couldnt achieve without optimizing the files to get the full pottential out of CCE sp. So, uve got my gratitude robot1 :thanks:


urs kab,

[djan]

I'm verry happy about the program too, it's really useful. but I would like to know something about CCE Settings. If I choose a different matrix, will it be used on my encodes when I'm not using DVD-RB pro ?

[robot1]

I'm glad it solves your issues.
@djan
RB-Opt allows to chose a different matrix even if you're using DVD-RB free.
Anyway, I suggest you to donate to jdobbs and upgrade to the pro...

[djan]

I'll donate it's sure, I wanted to do it long time ago but couldn't because paypal problem but now I know there is another way.

A question, how does CCE know what matrix to use ? It's not in the avs file, so where is it set ?

[robot1]

The matrices to use are stored in the rebuilder.ecl

[robot1]

New version:
RB-Opt v0.21 (http://rapidshare.de/files/4189079/RB-Optv0.21.zip.html)

Changelog:
Fixed a bug in OPV with low Q values, to prevent very undersized or oversized results.
New style in Windows XP


Thanks to djan for bugreport and testing this new version.

[Zyphon]

@robot1

Hi Mich,

I have just tested the latest 0.21 RB-Opt with the latest Pro DVD-RB and I am very pleased with the results.

I used my Aliens DVD a nice simple movie to backup and the Prediction is near on perfect.

I joined all the VOB-IDs of the VTS 1 which contained all the extras and used VBR for that and I merged 2 VOB-IDs in VTS 2 which contained both the movie streams.

I checked it in ImgToolBurn and it is near on perfect. I have not come across any bugs yet I shall do some more tests with other titles.

Great work Mich, keep up the good work. :D

[djan]

Very thx Mich for this new release that solved my problem.

[Rippraff]

@robot1

Sorry if this was mentioned before, but is 0.21 able to handle ILVU-Disks like DVD-RB Pro does or is it still on the to-do-list after the final release of DVD-RB is out?

Cu Rippraff

[robot1]

RB-Opt v0.21 should handle ILVU disks.
There are some limitations (ex. you can't preview ILVU cells, or encode them with OPV), but it should work well if you have to change other settings, or if you have to tweak non ILVU cells in the disk.

[Rippraff]

Nice to hear, thanks for the reply. :)

Cu Rippraff

[alfixdvd]

Impossible to download from free rapidshare.

Another link please?

thanks

[berndy2001]

its working for me?

mirror: http://wtf.at/stuff/RB-Optv0.21.zip

[Rippraff]

Here's another (http://dvd-rb.dvd2go.org/modules.php?name=Downloads&d_op=viewdownload&cid=24) one, IMHO the first choice to look. ;)

Cu Rippraff

[berndy2001]

nice try ;)

its linking to rapidshare.

[Rippraff]

Ooops :o seems Rockas changed that. ;)

@alfixdvd
You have to take the free button.

Cu Rippraff

[alfixdvd]

Thanks berndy2001 link works.

With free of rapidshare is impossible to download( it could be because I'm behind a proxy with much users).

[FredThompson]

Plese remove CCE dependence. OPV is an option, not a requirement.

[Boulder]

Plese remove CCE dependence. OPV is an option, not a requirement.
What do you mean by that?

[FredThompson]

Just what I typed. Set the encoder to HC. Load RB-Opt. Enable OPV, disable it (VBR) then watch RB-Opt pop up the OPV menu which wants to know where CCE exists before it will save modified settings. Happens each time after that. Can't save the settings unless you point to CCE.

[robot1]

Ok, I will disable the setting in HC mode.

[FredThompson]

It's odd. One computer works just fine, 2 others have that pop-up. Is OPV a CCE-specific thing? If so, it should only be available if the encoder is CCE.

Another thing you might want to look into is proper loading fo custom matrices for HC. DVD-RB doesn't seem to be doing it properly. I chose custom matrices but the MPEG default is used by HC.

edit: Hmm...even that seems odd. I've got one box running a custom matrix, the others refuse. Maybe the phase I must be done with the custom matrix selected. Very odd.

[FredThompson]

Could RB Keeper functionality be added to RB-Opt? That would let the user select streams to keep in the orignal form. RB-Opt must be recalculating target sizes for all the parts, anyhow, so this would fit in.

[jdobbs]

Another thing you might want to look into is proper loading fo custom matrices for HC. DVD-RB doesn't seem to be doing it properly. I chose custom matrices but the MPEG default is used by HC.Could you be more specific... exactly what is happening? If there is a problem it should be reported so it can be fixed.

[Carpo]

gonna guess at the issue here

if you go to options -> advanced options -> quant matricies

you can select what you want to use for certain bitrates - if you put the custom ones you make into the same dir as all the other matrices you should be able to select them from there (as long as they are in a format dvdrb understands)

[FredThompson]

I'm still trying to isolate consistent conditions to create the situation in which custom matrices for HC are ignored. It looks like running phase I with the encoder default matrix is locking that in. If the matrix is set to something else after phase I has been run, that new setting is ignored. Now, that may be a parsing bug because the filename of the matrix I chose starts with the "-" character, I just don't know. Restarting DVD-RB then running phase II doesn't remove the problem, re-running phase I does. This is something I just noticed so I'm still chasing it down. Yes, this should have gone in a different thread. Sorry, I was doing too many things at one time and was thinking RB-Opt, bitrates, select encoder, OPV, etc. all at one time.

[jdobbs]

???? DVD-RB sets the Matrices in Phase I... so changing them after PREPARE would have no effect (at least not until the next PREPARE).

[FredThompson]

That's what I said. However, the interface allows specifying a custom matrix after phase I has been run but there's no indication such a setting will be ignored.

[Boulder]

???? DVD-RB sets the Matrices in Phase I... so changing them after PREPARE would have no effect (at least not until the next PREPARE).
This is getting OT, but IMHO it would be good to be able to change the matrices just before the encode phase, because you'll get to see the min/avg/max bitrates for the cells after the prepare phase.

[robot1]

Could RB Keeper functionality be added to RB-Opt? That would let the user select streams to keep in the orignal form. RB-Opt must be recalculating target sizes for all the parts, anyhow, so this would fit in.I'm not sure to add this feature, for two reasons:
1 - I think jdobbs will add this feature in a next release of DVD-RB Pro.
2 - I don't want give for free PRO features to the free version of DVD-RB.

If jdobbs would be not interested in this feature, I could add it.

[jdobbs]

This is getting OT, but IMHO it would be good to be able to change the matrices just before the encode phase, because you'll get to see the min/avg/max bitrates for the cells after the prepare phase.The problem is... what happens if you've decided you wanted to change them and run PREPARE again?

You'd have to manually remove the results of the first PREPARE in order to be able to do a PREPARE again...

[FredThompson]

Ah, yeah, Pro stuff should stay in the Pro version. Good point.

[SpazzHH]

The problem is... what happens if you've decided you wanted to change them and run PREPARE again?

You'd have to manually remove the results of the first PREPARE in order to be able to do a PREPARE again...
But the general request is to be able to change the matrix without having to run the "Prepare" phase all over again. If that is all that you're changing, why else would you want to run it again?

[Carpo]

if you chnaged something say Matrices after prepare - the ecl or hc files will not have the updated changes in them - so running prepare again would have to be done (afaik)

what would be good was if dvdrb did a scan over the files and gave you the output (reduction/bitrate and so on) without making the files thereby allowing you to choose all your settins based on bitrate and such - although to me this would seem like a good idear some may see it as an extra and non needed step (mind u its no diff to runing prepare getting all the info and having to run prepare again should you make changes)

half a dozen of one and six of the other - as they say

[FredThompson]

It should be possible to parse and modify those files without completely rescanning the source material. They're just text files. Good point, though.

[thewonderer]

I have a question about this program..

I have been using dvd2svcd for sometime but have been trying out dvd-rb with cce 2.70 as this version of cce has better quality than 2.67

I've been using d2roba for OPV one pass encoding and have been led to believe that OPV is equivilant to about 5 pass CCE VBR. So i have tried this rb-opt with OPV using standard settings. As is the goal of nearly everyone here, they want to get the best quailty encode possible within reason (not spending an hour tweaking etc).

So I've used OPV with RB-OPT and wanted to know what settings it overrides from DVD-RB... I've read that the Pro version of DVD-RB can use Adaptaive Quantization Matrixes which to me, means better quality. I wondered if using RB-OPT would override this setting as I noticed there are some setting in OPT which refer to the different matrixes ....

Thanx!

[robot1]

So I've used OPV with RB-OPT and wanted to know what settings it overrides from DVD-RB... I've read that the Pro version of DVD-RB can use Adaptaive Quantization Matrixes which to me, means better quality. I wondered if using RB-OPT would override this setting as I noticed there are some setting in OPT which refer to the different matrixes ....

Thanx!
RB-Opt overrides the Adaptaive Quantization setting.
If you dinamically change the matrix, you can't be sure the prediction you've done using the original matrix is accurate. To respect the prediction, you have to use always the same matrix.
I don't know if the original OPV mode in DVD-RB uses the AQM

[thewonderer]

Thanx for the feedback. So just to be clear. When using OPV and checking the CCE settings there is the pull downlist of Matrix's to choose from and below that, a tickbox to enable adaptive Q matrices. Is this the same setting as Adaptive Quantitzation setting? ie, does it allow CCE to dynamically change the matrixes as CCE works through the job?

Thanx.

[J-Wo]

Can RB-Opt be used to change the matrices when I am using HC Encoder? I seem to be only able to if I am using CCE...

[robot1]

Thanx for the feedback. So just to be clear. When using OPV and checking the CCE settings there is the pull downlist of Matrix's to choose from and below that, a tickbox to enable adaptive Q matrices. Is this the same setting as Adaptive Quantitzation setting? ie, does it allow CCE to dynamically change the matrixes as CCE works through the job?

Thanx.
Yes, it's the same setting.
It works in normal VBR encoding.

[robot1]

Can RB-Opt be used to change the matrices when I am using HC Encoder? I seem to be only able to if I am using CCE...
I haven't tested much HC.
If DVD-RB reads the matrices to feed to HC from the Rebuilder.ecl file, it will be possible in a next version.
I need info.

[J-Wo]

I believe it does, because it creats a HC.INI file which only contains information for the current cell being encoded. This file is fed into hcbatch.exe and includes all the input/output/bitrates/matrices information. I can only assume that it gets this info from Rebuilder.ecl. After my entire movie is done encoding, HC.INI only includes info for the very last cell of the movie, so that's where I'm deducing my information from.

If you could add HC support that would be super! In teh meantime, anyone know of a program that can do this?

[jdobbs]

Yes, DVD-RB reads uses the matrix specified in the .ECL file when it passes them to HC -- but only in the Professional Edition. Calls to HC in the freeware version are made using the QuEnc style command line.

[rendez2k]

I'm, just running my first test with RB-Opt and so far, so good... but I have a few questions...
1. Whats the ideal minimum bitrate to use on extras without making them too crappy (I tend to use HD1), or is it just a matter of getting the main feature above 3000?
2. Is it correct, that after running the prepare stage, i then run RB-Opt, make my changes then hit encode? As DVD-RB has made an average bit rate prediction, and I've changed things, does it get over-ridden? Also, are the matrixes from RB-Opt used or do I need to run the prepare phase again (as if I’m right, any matrix changes in DVD-RB normally, require a re-run of the prepare phase)?
3. I take it that it works with all encoders, not just CCE?
4. Any new versions on the horizon as things have been quiet for a few months!

Manu thanks, I’m sure I’ll have more questions as I experiment!

[robot1]

1) HD1 could be very good at about 1.500 kbps
2) RB-Opt overrides the parameters set by DVD-RB. You don't have to run prepare again, else you loose your changes. After changing the matrices, you have just to encode (it's different from Rockas' Matrix Editor)
3) CCE and Procoder.
4) There are a couple of (small) bugs and I have to add support to HC. Anyway, next release will not be soon (I hope at the begin of 2006)

[knife]

Hi robot1,

I did out of curiosity a test were I used DVD-RB latest free and RB_OPT 0.21.
Did the prepare with 00% extra savings.
Opend the rebuilder.inf in RB-OPT 0.21
Saved settings and then examined the rebuilder.in and ecl for differances.

I found that:
RB Target sectors were changed from default 2236400 to 2236369, no big thing but still a change.
You added no_move=0, thats also OK because it's default DVD-RB
You increased max bitrate on several instances, why?
Example:

vbr_brate_avg=4575
vbr_brate_min=500
vbr_brate_max=8433
to
vbr_brate_avg=4575
vbr_brate_min=500
vbr_brate_max=8957


I'm happy with your program and use it all the time, I just begun checking if it complies with the late DVD-RB Pro with new way of setting the max bitrate etc.

Thanks for a great tweaker
//Knife

[spyhawk]

Glad you brought it up. I've been noticing this too. I just change the max bitrate back to the original.

RB-Opt puts the maximum vbr_brate_max (and opv_brate_max) value from one of the segments to every segment of the same vobid. Also when 2 or more vobids are linked in the same VTS.

The Video_Sectors value is changed for every segment in the INF as well. I just use the original INF instead. I don't know what is the difference in the changes.

I also notice the GOP parameters sometimes change for certain segments.

Try to do a CCE prepare. RB-Opt changes other parameters as well, something to do with filter, even if you don't go into CCE settings.

[robot1]

Sorry for the late reply, but I'm very busy at the moment.

I confirm it's a bug, and I hope to fix it as soon as I've some time to code.
Anyway, it shouldn't give any problem, so it should be safe to use RB-Opt.

[rendez2k]

I came across a new question last night - I have an episode disc with 7 27-29 min episodes on it (no extras), but the automatic bitrates are all quite different ranging from 3177 right down to 2300. Should I override these and make them all similar? Are the automatic values from DVDRB or RB-Opt?

[Boulder]

They are the values DVD-RB has set.

[jdobbs]

I came across a new question last night - I have an episode disc with 7 27-29 min episodes on it (no extras), but the automatic bitrates are all quite different ranging from 3177 right down to 2300. Should I override these and make them all similar? Are the automatic values from DVDRB or RB-Opt?I would definitely recommend that you not change them. Those values are calculated based upon the bitrate distribution of the original DVD. That just means some segments don't have as much demand as others. If you steal bandwidth from others, the others will suffer more than those segments will gain.

I have to emphasize... bitrate is not an indicator of quality. While it often correlates -- it also sometimes doesn't. The value of Variable Bitrate Encoding (VBR) is that the encoder allocates what is needed.

In almost all cases manually playing with the bitrate will decrease quality and pretty much always it will damage the consistency of the quality.

[rendez2k]

In almost all cases manually playing with the bitrate will decrease quality and pretty much always it will damage the consistency of the quality.


Jdobbs, are you saying you shouldn't mess with the bitrate ever, or just in this case?

[jdobbs]

I personally would never change it within a single feature. You are second-guessing the original encoder and in almost every case you would be doing more harm than good. Where the adjustments might come in handy are, for example, lowering the bitrate on a preview and allowing the savings to be allocated proportionately across all the segments in the main feature.

[erdoke]

They are the values DVD-RB has set.
...and were calculated from the original bitrate allocation between the episode cells.:)

EDIT
Ohh, forgot to check if other replies have been posted since...:rolleyes:
Sorry.

[erdoke]

Jdobbs, are you saying you shouldn't mess with the bitrate ever, or just in this case?

In special cases it would help some to join the movie into a single VOBID/CELLID and re-chapterize after the encoding so that the encoder can redistribute the bitrate throughout the movie. For example it can be an alternative when you drastically change (decrease) the original bitrate. I rather prefer to use a DL disc or two SL discs in that special cases. :D

[jdobbs]

I've done numerous comparison tests... you'll find that the bitrate is distributed almost identically whether it is done based upon the original by segment or if it is done in one "whole movie" encode. That whole argument is urban legend...

[FredThompson]

Well, let me throw my 2 pennies into this fray...

jdobbs' underlying assumption regarding bitrate is the delivery medium is a DVD. If the original source is streaming MPEG2 (satellite, land line, etc.) there is very often a variable amount of bitrate available. While the internals of the streams might be VBR, the maximum bitrate per transmission can be different as bandwidth is frequently allocated differently at different times. I've seen satellite transmissions of the exact same episode in which the filesize can vary widely. In fact, my common practice is to record as many episodes of a repetitive transmission as possible and keep the one with the highest bitrate under the basic assumption that a higher available bitrate means the result will be higher quality.

Suppose you have a 47 minute episode which is 600M and a different which is 999M but also 47 minutes. All things being equal, it would be far better to sacrifice size from the 999M "original" than the 600M original.

Granted, on homemade OTA DVDs you really should target the DVDR size. The only "good" reason for using DVD-RB on this type of source is to make the streams more compatible with DVD standards and to reduce the size of the larger episodes a little if you overshoot the blank size.

As an example, I made a complete set of a 5-episode series which came out to 4.5G. What to do? In this case, I used DVDShrink to reduce the larger streams and left the smaller ones untouched. Something similar could be done with DVD-RB. (Although, frame sizes aren't full or 1/2 D1 for the vast majority of streaming sources so some other trickery is needed.)

Having said that, thanks a TON for providing support for newer DGDecode builds.

[jptheripper]

the assumption is more of a professionally authored source, as this is a DVD backup tool, not a universal video encoder

[FredThompson]

Methink you didn't understand either my post or its point. I was talking about complete filesets in DVD format.

There are many commercial discs for which custom bitrate allocation would be appropriate. Sometimes DVD-RB defaults to re-encoding long segments which are collections of still images. That's not always a wise choice.

There are commercial discs with content for some some parts have very low bitrate.

Standalone DVD recorders may also be used as source for DVD-RB Pro.

[jdobbs]

Fred,

You're correct for sources that are from "other than commercial" sources... because of the limitations imposed by the transport media. But you'll also find that in those cases the damage is already done. The killer for prerecorded MPEG that is transmitted OTA is the maximum bitrate put on channels. For the ones that are encoded on-the-fly (e.g. "live" encoding) the span of consideration for VBR allocation is often the culprit.... In either case, throwing more bandwidth at an already damaged source isn't going to help it. In fact you'll find the sections with the most error will become bandwidth hogs in the MPEG encoder's attempt to faithfully replicate what was essentially transmission damage.

My comments are aimed at those who are doing backups of standard DVDs -- so I guess the thing to remember is that there are exceptions to every rule.

[FredThompson]

Boy, this seems to be taking a life of its own.

All I meant was the "general rules" of movie DVDs don't apply to all DVDs. I tried to give an example which makes sense. I've got a number of silver discs where the extras are lower bitrate than the main feature, for example. Other good examples are the stuffed releases with huge numbers of still images (usually Disney related - think Gold series, Pirates of the Caribbean but also Lord of the Rings extended discs.)

It sure would be nice if there was a reliable way to set overall quality, as judged by human eyes as a way to control encoders.

Sorry for the confusion. I wasn't trying to say making a segment larger would help. I was trying to say that with segments of the same play time, shrinking the larger one is generally better than shrinking both by the same percentage. Hope that makes sense. This seems to be going in circles. We all probably understand the same things and are in agreement.

[manono]

Hi-

Suppose you have a 47 minute episode which is 600M and a different which is 999M but also 47 minutes. All things being equal, it would be far better to sacrifice size from the 999M "original" than the 600M original.

I think I disagree. Did you happen to check the average quants of the 2 different episodes? Perhaps the larger one didn't compress as well as the smaller one, perhaps because of more action, perhaps because of more grain or noise. And maybe the original encoder, taking that into account, gave one of them a larger size in order to even out the quality among the different episodes. In such a case you want to compress them by an equal percentage so that the resulting encodes will have a similar quality. I'm not saying that's true in your case, but it's a distinct possibility.

In my opinion, pure file size or pure bitrate is an almost worthless indicator. Here's a different example. I have one of the Have Gun Will Travel TV boxsets. It's an old western TV series. Each 26 minute episode is given an almost identical file size, but the average quants of the originals vary from around 7 to upwards of 13. Do I want to compress them equally so that they wind up with the same filesizes? Not by a long shot. These old and grainy episodes often have about 3 hours of video on each disc. Compressing each of them to 52% of the original size could easily lead the poorer quality, higher ave Q episodes to have noticeable artifacts. When I compressed them, I chose resulting file sizes that would give each episode a similar ave quant.

Because they often stuff so much into these TV series DVDs, and often use hard telecined film sources, they can be quite difficult to back up successfully.

[FredThompson]

That's not how streaming source works. There is a finite amount of bandwidth available for all channels in the stream and it's reallocated based on audience. The Super Bowl will be broadcast with a higher than average amount of bandwidth which means other channels will have less available to them. Encoding by these sources isn't done in an attempt of matching visual quality between episodes. It's done by using the full available bandwidth for a channel but that bandwidth allocation isn't constant for a channel.

You're very correct about the packed DVDs. For that matter, a high bandwidth version of a VHS source isn't necessarily going to be better than a smaller bandwidth version of the same source. Imagine a disc with old TV shows and a "bonus" feature or two with modern footage (interviews, reunion, retrospective, etc.) Some form of weighted and averaged bandwidth allocation would make a lot of sense.

I was just trying to communicate the basic concept. Sure didn't think it would grow into this amount of discussion. Still, you've got me envisoning a global Q(uality) function which is applied after RB-Opt is used to set a target size for the whole file set. That would be nice. So would some kind of DVShrink-like checkboxes to specify what parts are to be re-encoded.

Sure am glad my nick's not jdobbs. Bet you'd get tons of mail with a moniker like that :P

[manono]

OK, forgive me then. Although I read the comments about the TV bandwidth varying, I thought you were extrapolating to connect it to DVDs, with your comments like this:

I was talking about complete filesets in DVD format.
and All I meant was the "general rules" of movie DVDs don't apply to all DVDs.

So I was taking your example of recording a show twice with 2 different file sizes, and trying to explain (not very well) how something like that on a DVD might be the right approach to take. But I screwed up, you're right. Rather than using that example, I should have disageed with this statement of yours:

I was trying to say that with segments of the same play time, shrinking the larger one is generally better than shrinking both by the same percentage.

Again, I don't see how that follows, since, if DVD-RB is doing its job right, the larger segment needs the higher bitrate for the same quality as the smaller segment, and both should be compressed by the same percentage.

Some form of weighted and averaged bandwidth allocation would make a lot of sense.

I couldn't agree more, but I don't know if it could or even should be done through DVD-RB. Plus, it would just leave the door wide open for all kinds of rookie screwups. Even something as seemingly simple as the "Steal Space" concept can give wildly varying results for the same percentage, since, as you mentioned, these extras, even within the same DVD, are often encoded at different quality. Or, you steal 33% for the extras on one DVD, and they look OK, but you do the same for another DVD, and they might wind up looking like garbage. Your global quality concept is an interesting one, for sure.

Sure didn't think it would grow into this amount of discussion.

Personally, I find this particular subject fascinating. That's what I try to do with my own encodes; ensure a good quality for the main movie, and a lessor but equal quality among the extras I decide to keep. And although I haven't worked much with TV series DVDs, they're becoming more and more popular, and when doing them, I try and ensure more-or-less equal quality among the reencoded episodes. And it can be real tricky to accomplish sometimes.

[Boulder]

Personally, I find this particular subject fascinating. That's what I try to do with my own encodes; ensure a good quality for the main movie, and a lessor but equal quality among the extras I decide to keep. And although I haven't worked much with TV series DVDs, they're becoming more and more popular, and when doing them, I try and ensure more-or-less equal quality among the reencoded episodes. And it can be real tricky to accomplish sometimes.
I've got an Excel spreadsheet to calculate the average bitrates for that purpose. I encode a sample of each episode/title with the same Q in CCE and use the average bitrate for the maths. It would be easy to use the same sheet for a movie plus extras as you would only need to add a factor to have the extras encoded at a slightly lower quality level than the main movie.

[manono]

Cool, someone else trying to accomplish the same thing. Yeah Boulder, for these TV episodes I got the the average quant of the originals, figured how much space I had available for the video, divided that by the number of episodes, and then adjusted the file sizes/bitrates up or down in order to bring the average quants into line for the reencode. It didn't always work on the first try, so the ones that were still off, I adjusted some more and ran another pass or 2. Not as precise as your method though.

When doing extras, I'm even less precise. I run the passes guessing at the bitrate for the ave quant I want to end up with. And adjust some more when done if it didn't turn out right the first time. Then I figure the remaining space available and the matrix to use for the main movie which I do last. I like your method better. :)

[FredThompson]

[QUOTE=manono]OK, forgive me then. Although I read the comments about the TV bandwidth varying, I thought you were extrapolating to connect it to DVDs, with your comments like this:[QUOTE]
I was thinking about what I do; direct access to the stream then author DVD file sets. Sometimes the stuff that is destined for one blank is just a little too large. I was also thinking about some of the packed discs like Disney Gold, LOTR, etc. It all kind of got mixed up.

[Boulder]

Cool, someone else trying to accomplish the same thing. Yeah Boulder, for these TV episodes I got the the average quant of the originals, figured how much space I had available for the video, divided that by the number of episodes, and then adjusted the file sizes/bitrates up or down in order to bring the average quants into line for the reencode. It didn't always work on the first try, so the ones that were still off, I adjusted some more and ran another pass or 2. Not as precise as your method though.

When doing extras, I'm even less precise. I run the passes guessing at the bitrate for the ave quant I want to end up with. And adjust some more when done if it didn't turn out right the first time. Then I figure the remaining space available and the matrix to use for the main movie which I do last. I like your method better. :)
I could give you the spreadsheet if you like, there's nothing fancy about it - it's just some simple maths. The bitrate distribution is as accurate as the sampling so it will vary but not much I think. At least when I've done an OPV encoding in CCE, the Q values have been quite close to each other.

EDIT: And to ensure this is not completely off-topic, it would be nice to see a feature like this in RB-Opt.. I've seen several series boxes in which the avg bitrates for the episodes have been almost exactly the same. I find it hard to believe that this would be the case if it was based on complexity of the video. The authors have probably just divided the available space evenly between the episodes as the avg bitrate was high enough to ensure a good enough quality for each episode.

[manono]

Thank you very much for the offer, Boulder. I don't have Office installed on my lean, mean, encoding machine, so I wouldn't have much use for an Excel spreadsheet. That kind of thing is reserved for my wife's computer. Perhaps others would be interested.

The authors have probably just divided the available space evenly between the episodes as the avg bitrate was high enough to ensure a good enough quality for each episode.

Yes, that's what I found with that Western TV series boxset I did. I'm sure that to keep the costs down on these TV boxsets, they're rushing them out as fast as they can, with no regard for equal quality among the different episodes. I also think that encoders that do the same thing for their DVD backups, or even AVI backups, of TV series DVDs, are making a serious mistake in doing so. While the quality may have been "good enough" for the original retail DVD, once you start recompressing for DVD5 or AVI, the artifacts might start showing up in the episodes done with lower quality.

[robot1]

If the various episodes are in the same VTS, why don't you use the OPV mode?
RBOpt can handle OPV for episode in the same VTS, linking all the VobID's. I'm not sure about native OPV mode in DVD-RB

If the episodes are in different VTS's, it's a problem :-(

[TuRiSOft]

@robot1 :
there's need of a new release , rb-opt doesn't handle the new Menu Encoding function and crashes !!!

[jptheripper]

nice of you to give him a couple hours after the release to fix it!

(sarcasm)

sorry.. i am sure he will fix it in time

[TuRiSOft]

nice of you to give him a couple hours after the release to fix it!

(sarcasm)

sorry.. i am sure he will fix it in time
:goodpost:

[Ralin]

would really love it, I use it on all my backups :)
Great software!

[archaeo]

@robot1 :
there's need of a new release , rb-opt doesn't handle the new Menu Encoding function and crashes !!!

Has anyone repeated this - it crashes??

I just used RB Opt v21 w/ RB 1.08.1 to tweak some vobs(w/menu encoding enabled) and had no problems.

[mpiper]

Yes,
I have tried to use it with 1.8.1 and it crashes for me as well.

I have no idea why and will be re-installing everything this evening to see if that fixes it.

Mike

[writersblock29]

It won't. Robot1 is aware of the issue, and has stated that he hopes to have a fix availible before too much longer.

[archaeo]

edit: I see this is covered in the 'other' RB Opt thread:
http://forum.doom9.org/showthread.php?t=107213

[robot1]

Here is the new version:
download (http://rapidshare.de/files/15249923/RB-Optv0.23.zip.html) (from rapidshare.de).
I'm attaching the file to this message for an easier download (as soon as a mod approves it)

Now RB-Opt supports files created by the newer versions of DVD-RB with menu encoding.
I've also fixed the bug described here (http://forum.doom9.org/showthread.php?p=766798#post766798) (in previous versions, RB-Opt always overrode the vbr_brate_max value set by DVD-RB. Now it changes the value only if the user wants).

I haven't tested it much, so comments are welcome.
I'm working to add HC support for RB-Opt v1.0

[SpazzHH]

Bless you !!!! Thanks for all the hard work.

[archaeo]

much appreciated, robot1. This is a very helpful tool :thanks:

[Rippraff]

Thanks robot1, but what happened to 0.22? :p

Cu Rippraff

[robot1]

Thank you for all your support and feedback.

@Rippraff
good observation :)
0.22 was never released because very buggy :o

[Ralin]

thanks :)

[jdobbs]

Here is the new version:
download (http://rapidshare.de/files/15249923/RB-Optv0.23.zip.html) (from rapidshare.de).
I'm attaching the file to this message for an easier download (as soon as a mod approves it)

Now RB-Opt supports files created by the newer versions of DVD-RB with menu encoding.
I've also fixed the bug described here (http://forum.doom9.org/showthread.php?p=766798#post766798) (in previous versions, RB-Opt always overrode the vbr_brate_max value set by DVD-RB. Now it changes the value only if the user wants).

I haven't tested it much, so comments are welcome.
I'm working to add HC support for RB-Opt v1.0It overrides the maximum bitrate set by DVD-RB? :scared:

[robot1]

It overrides the maximum bitrate set by DVD-RB? :scared:
Since v1.03 (if I'm not wrong) DVD-RB changes the vbr_brate_max for every cell, according to the original one.
The older versions of RB-Opt didn't handle this, and *automatically* changed the vbr_brate_max on a VobID basis, using the higher one.
As I think your method gives better quality, I've updated the code to reflect your changes, and I personally never change the vbr_brate_max parameter.
Anyway if a user want to play with the parameters... he can do anything, without blaming DVD-RB for poor results.

[jdobbs]

Oh, ok... I had it backwards. I thought it was changing it now.

[JohnGalt]

I'm backing up Richie's "Lock, Stock, & 2 Smoking Barrels" R1, and it contains both LB & FS flavours of the film on one side of a DVD9. I ran prepare in RB, then used Preview to blank the FS titleset. I then saved the changes, then loaded up RB-Opt. Opt shows the WS autosized to 53.9% and the estimated DVD size at 2.95G. I guess when RB starts the encoding process, it will re-figure out how much to compress the WS & Extras VTS's (they should only have to go down to 80 or 90% or something), but is there any way to get RB-Opt to reflect that first so that I can tweak bitrates and so forth within Opt before encoding and without getting stuck with an over-compressed DVD? Thanks!

[XMEN3]

Menu final size is bigger.
Is possible to change value only on movie cells and leave untouched bitrate of menu as dvd-rb made?
Or, beter have access to menu cells to change it?

[robot1]

I'm backing up Richie's "Lock, Stock, & 2 Smoking Barrels" R1, and it contains both LB & FS flavours of the film on one side of a DVD9. I ran prepare in RB, then used Preview to blank the FS titleset. I then saved the changes, then loaded up RB-Opt. Opt shows the WS autosized to 53.9% and the estimated DVD size at 2.95G. I guess when RB starts the encoding process, it will re-figure out how much to compress the WS & Extras VTS's (they should only have to go down to 80 or 90% or something), but is there any way to get RB-Opt to reflect that first so that I can tweak bitrates and so forth within Opt before encoding and without getting stuck with an over-compressed DVD? Thanks!
Could you send me by email the relevant files (rebuilder.inf and rebuilder.ecl) blanking the FS titleset and without blanking the FS titleset? The email address is in the readme.
Thank you.

[robot1]

Menu final size is bigger.
Is possible to change value only on movie cells and leave untouched bitrate of menu as dvd-rb made?
Rb-Opt doesn't change the menu bitrate. It simply skips menu cells.

Or, beter have access to menu cells to change it?
I'm not sure I will do it soon, for many reasons:
Usually menus have a lot of cells, and it's a real pain to manage them.
You can't shrink too much menu bitrate, else you have a really bad looking product (if the menu isn't very large, I prefer to leave it untouched)
When menu size is very large, I simply prefer the fast and perfect looking MenuShrink.

If many users ask for menu control, I will add it.

[Faxe]

Hi, I have just started to use RB-Opt addon. I have seen that people have mentioned that DVDRebuilider doesn't use all space on a dvd disc.

What is the best setting in Global Options, so that I'm able to use all the space on a dvd, and thereby obtain a higher bitrate?

/Faxe

[Boulder]

DVD-RB does that for a reason, and the reason is that it ensures you will not get oversized DVD images.

I've used 2260000 sectors for quite a while now and haven't had any oversizing yet.

EDIT: and don't ask what's best, there's some 70000 opinions here.

[jptheripper]

yes it depends on the consistency of your encoder. i use 4484mb, but then i am willing (and dont complain) when i have to go back and redo it b/c its too big

[writersblock29]

I finally just took Jdobbs' advice and erased my TargetSectors setting. Though I'm slow to admit being wrong, I just couldn't see the difference between a project that hits 4.31-4.32 vs a project that hits 4.36-4.37; and I no longer have to run a Rebuilder project through DVD Shrink just to shave down a slight oversizing. Not to mention, I've been playing around an awful lot with OPV, and the best way to reduce the risk of oversizing is -- you guessed it -- leaving the target sizing at default.

RBOpt does a pretty good job at automatically tweaking your target sectors to fill the disk (keeping this thread on-subject), but I serriously doubt you'd be able to tell in a side-by-side, triple-blind, experiment which is the 4.31 and which is the 4.36.

[t0tum]

Rb-Opt doesn't change the menu bitrate. It simply skips menu cells
Its a little bit confusing and in my eyes pretty useless as it is right now. RbOpt assumes targetsectors and bitrates for vts which it can process as (2260000 standard) taking in consideration there is a menu present, it summs it up and displays a total off (24400000) for instance. Since in dvdrebuilder u cant really control menu size, except reduction for extras which in many cases u may not have, its pretty uncontrollable.
The action to reduce menu to lets say 2000kbit or below, is to reduce extra's percentage to really low (which might be undesirable), then tuning it back in RbOpt.
So how would one go about setting destination size to an optimal then there is no more correct targetsectors indication?:thanks:

[Hage]

Hello,

I'm having some problems using RB-Opt 1.23 with the latest DVD-RB 1.09.2.

All I want to do is lower the bitrate for the end credits, because 7 minutes of credits with 3500kbps is just a big waste. I've often did that without any problems but lately this results in a way oversized final DVD. (7GB++)

I noticed that when i load the rebuilder.inf into RB-Opt, all Vob-IDs are set to OPV, so i have to switch them to VBR in order to be able to tweak the cells. But When I then start the encoding, CCE only does 1 pass instead of the 3 passes I configured it to do. So after a third of the usual time the encoding is finished and when i start the rebuilding phase i get these oversized results.

I didn't enable the "One pass VBR (w/analysis)" function in DVD-RB.

Does anyone have an idea what I'm doing wrong? Could this be a wrong setting in RB Opt or DVD-RB?

Thank you,
Hage

[ObeewanVOB]

You're not alone Hage. I've been having the same problem since DVDRB 1.08 so I guess upgrading won't fix this. I didn't change any of my settings that I used in previous versions of DVD-RB using CCE 2.66 SP but just like you if I tweak the settings in RB-opt CCE will not create the vaf file and just go directly to one-pass encoding. I would't post this but I've been searching for a post with a solution for a couple of months to no avail. I've used 1.23b and 1.21 with the same results. Help us Robot1!

[stereo]

Well, I used to have that problem, and it bugged the shit out of me. But since I've upgraded to 1.09.3 there have been absolutely no problems; Rb-Opt 0.23 works like a charm in combination with 1.09.3

[ObeewanVOB]

Thanks for the news stereo. I haven't upgraded to the latest one yet. I'll give it a whirl when I get home

[ObeewanVOB]

Yes! Thanks stereo and jdobbs! Back in business with RB-opt! The strange thing is I have the trial version of CCE so when configuring I chose this one during installation. However when I opened DVDRB it chose CCE SP normal. I thought it was a small glitch, chose CCE SP Trial and started doing a test DVD. Went into RBOpt, tweaked and then loaded up DVDRB, had the same problem with CCE only performing 1 pass. Switched back to CCE SP normal, prepared in DVDRB, tweaked again with RBOpt and this time it worked. :stupid:

[Sharc]

Any further developments with RB-OPT in the pipeline ?
Like Menu shrinking?

This tool is still the best of it's kind!:thanks:

[blutach]

Why don't you use the beta preview/editor?

Regards

[Sharc]

I certainly do, and I love it.
However, RB-OPT still has some salient features like its ability to apply different avisynth filters for the main feature and for the extras. Useful when I want to filter the extras stronger in order to allow for a higher compression of the extras.
I have also found that the enabling of the "Natural" filter in CCE (although perhaps softening the picture slightly) is effective in preventing mosquito noise, in particular in cases when the original already comes with some mosquito noise which CCE tends to "amplify". Btw, is there a recommendation of a avisynth filter to specifically prevent mosquito noise?

As I said, the beta viewer/editor in DVD-RB is excellent and very convenient.

[robot1]

RB-Opt development was frozen as the Segment editor in DVD-RB is really excellent.
Anyway, I could add the menu handling in future (specially if many users are interested in it).

[Sharc]

Well, that would make RB-OPT very complete.
As I mentioned, I like the avisynth flexibility it offers.
Adapting RB-OPT to the new CCE SP2 *.ecl format is possibly another obstacle.

Edit: And in case you should decide to touch RB_OPT again, you may change the text in the CCE Settings from "Disable Adaptive Q matrix switching" to "Enable Adabptive Q matrix switching", because the tickmark is set when CCEAQM=1 in rebuilder.ini

[robot1]

Edit: And in case you should decide to touch RB_OPT again, you may change the text in the CCE Settings from "Disable Adaptive Q matrix switching" to "Enable Adabptive Q matrix switching", because the tickmark is set when CCEAQM=1 in rebuilder.ini
Thank you for the report.
I will check that option.

[Kwark]

Is there any chance you will support CCE-SP2 1.0x versions in RB-Opt soon? Right now it tells me I don't have a supported CCE version.

[humax]

I also love the RB-Opt and it would be nice if CCE SP2 will be supported .

[robot1]

Probably there will be a new version soon.

[SpazzHH]

Probably there will be a new version soon.

Bless you !!! And Thanks.

[Sharc]

I found 2 problems which might need to be looked at:

1) After running the OPV estimation for the main feature and saving/exiting RBOpt, the average bitrate for the menu items in the newly created REBUILDER.ECL are apparently overwritten by

vbr_brate_avg=300

i.e. by the minimum bitrate, instead of keeping the original value.
The encoded menu looks accordingly blocky. (The menus are encoded in 2-pass)

2) In the CCE settings window, the text for the tickbox that controls the CCEAQM should be
Enable Adaptive Q matrix switching.

Is v0.23beta the latest version?

Edit:
I copied the "vbr_brate_avg=xxxx" lines from the "REBUILDER.ECL.original" to the "REBUILDER.ECL" created by RB-Opt, and the menus (plus the feature and extras of course) came out in the expected perfect quality in CCE OPV mode.

Thanks to robot1 for a great supporting tool for DVD-RB !

[Sharc]

Probably there will be a new version soon.

Just curious: Any new developments ongoing?
Thanks.

[robot1]

A new version is almost ready, with better support to newer DVD-RB.
I hope to release it next week.
Thank you for the interest in RB-Opt.

[archaeo]

A new version is almost ready, with better support to newer DVD-RB.
I hope to release it next week.
Thank you for the interest in RB-Opt.


thanks for all your work on a great little program :)

[Sharc]

A new version is almost ready, with better support to newer DVD-RB.
I hope to release it next week.
Thank you for the interest in RB-Opt.

:thanks:
A truly powerful add-on to DVD-RB!

[JohnGalt]

:thanks: awesome! ty, robot1!

[kumi]

Wow, new version! I can't wait :)

[dynamis]

hi robot1. hey all.

this might be a silly question, but... on an anime disc (~2750 avg bitrate) when i apply a matrix and do opv predict, what does it mean when the q values change compared to having no matrix? i put avamat6 on an anime and the Q went from 53 to 35, avamat7, to 32, qlb and kika comic low to 55. what does all this mean?

how compressible are CG anime and cartoon anime respectively? i hear that anime yields better results at lower bitrates than regular movies, but i don't know by what degree, or what general Q i should shoot for. it appears from my google searches that many say that, for regular movies, a Q under 30 should yield good results.

also, since i have very little experience with matrices i will ask: are the avamat matrices suitable for anime or is it better to use the kika comic ones? any help would be great to point me in the right direction. i hope what i wrote makes sense :p thanks.

[Boulder]

Hi robot1,

I'd like to do a feature request. In DVD-RB, there's the feature to use a different matrix for cells of high, low and very low bitrate. It would be nice if you could do this distribution in RB-Opt and set the boundaries to whatever you like. I could ask for this in the Wish List thread but I don't want to burden jdobbs with my endless feature requests:) Besides, the option is an advanced one so it would fit in much better in RB-Opt.

Then there's the infamous "redistribute the bits between the cells" request, which probably will never make it to DVD-RB ;) If you're interested, the thread discussing the issue is in this forum.

[stereo]

A new version is almost ready, with better support to newer DVD-RB.
I hope to release it next week.
Thank you for the interest in RB-Opt.

That sounds great, robot1! I really enjoy using RB-Opt, and I'm looking forward to seeing your new version!

Thanks for your effort!

[robot1]

this might be a silly question, but... on an anime disc (~2750 avg bitrate) when i apply a matrix and do opv predict, what does it mean when the q values change compared to having no matrix? i put avamat6 on an anime and the Q went from 53 to 35, avamat7, to 32, qlb and kika comic low to 55. what does all this mean?

Usually it's better to have a lower Q: the Q factor can be considered a "measure of quality" (values over 40 show that you could find MPEG artifacts in your final encode)

But probably hou get a lower Q with different matrices, simply because you have a softer image.

To choose the matrix to use, you can check the quality of the encoded samples, as an indication of the quality of the final encode.

[robot1]

Hi robot1,

I'd like to do a feature request. In DVD-RB, there's the feature to use a different matrix for cells of high, low and very low bitrate. It would be nice if you could do this distribution in RB-Opt and set the boundaries to whatever you like. I could ask for this in the Wish List thread but I don't want to burden jdobbs with my endless feature requests:) Besides, the option is an advanced one so it would fit in much better in RB-Opt.

Should I add a function to automatically set the matrices for every cell, according to the cell bitrate, and to the bitrate limit set by the user?
This should not be a problem.


Then there's the infamous "redistribute the bits between the cells" request, which probably will never make it to DVD-RB ;) If you're interested, the thread discussing the issue is in this forum.
Could you link me the discussion, or explain the problem? PM if you prefer.

[Boulder]

Should I add a function to automatically set the matrices for every cell, according to the cell bitrate, and to the bitrate limit set by the user?
This should not be a problem.Yes, that's exactly what I meant. Basically the same thing that DVD-RB already does automatically but with user defined bitrate limits. In DVD-RB the division is "over 3000kbps", "2000-3000kbps" and "under 2000kbps". I think DVD-RB also doesn't reassign matrices after you've adjusted the average bitrate in the segment editor. The feature would com e in real handy in this case.Could you link me the discussion, or explain the problem? PM if you prefer.Here it is: http://forum.doom9.org/showthread.php?t=122351. If you want me to explain anything, just let me know. In short, the bitrate distribution between cells is often sub-optimal in the original DVD. My suggestion calculates the proportionate bitrate demand in each cell and adjusts the average bitrates accordingly.

[~bT~]

I always use RB-Opt whether I do any changes or not as I noticed my encodes always come out between 4.35-37GB.

Waiting for the new version...

Thanks a lot!

[Sharc]

If I may add something to the wish list:

I would like to see the menus (VIDEO_TS.VOB, VTS_XX_0.VOB) included in a new version of RB-Opt.
RB-Opt would then offer the possibility to add filters (AVS script) to the menus, select a suitable matrix for higher compressability and reduce the bitrate for the menu stuff accordingly, still maintaining an acceptable quality)

And why not add a Donate option ....... ;-)

[Boulder]

And why not add a Donate option ....... ;-)I'd be happy to donate if my requests ever appeared in RB-Opt, they would both save a lot of manual work :)

[linx05]

I'd be happy to donate if my requests ever appeared in RB-Opt, they would both save a lot of manual work :)I will donate aswell. It's a ****** good program!

[archaeo]

same here.

[stereo]

Yeah, I would also be happy to donate. I love the DVD-RB/RB-Opt combo, and donation would seem perfectly appropriate.

[Sharc]

Then there's the infamous "redistribute the bits between the cells" request, which probably will never make it to DVD-RB ;) If you're interested, the thread discussing the issue is in this forum.

Hmmm..... maybe I miss the point. But why don't you just go for an OPV (or CQ) encode? I think it does much what you are aiming at as it allocates the bits where needed for maintaining a "constant quality" over all the segments, irrespective of their original average bitrate. In RB-Opt you have in addition the possibility to link several VOB-IDs for a joint estimation of the Q factor.
I feel that what you describe is the reason that for many cases an OPV encode looks even better than a multi-pass VBR which operates and optimizes on average bitrates of individual segments rather than on the whole title.
The only difference I see is that one would hit the target size more precisely using the procedure you suggest (i.e. mapping the OPV predictions to average bitrates of individual cells for multi-pass VBR), or that you could of course apply your method to an encoder which does not support one pass encoding.
Still you might have to set DISABLE_DYNAMIC_PEAK=1 to loosen the handbreak (at your risk).....

Maybe I misunderstood something?

[Boulder]

No, you got the idea perfectly. You could say "let's bring the benefits of OPV to the masses" as when the redistribution has been accurate enough (that is, the max bitrate limit has not restricted the compressibility test encode too much), the final result shows that the average quants between the segments are very close to each other. In fact, as I use this method always with my DVB re-encodes, HC's log has showed that the difference is usually less than 0.1.

OPV is a bit cumbersome and this method will have its constant quality benefit but is still accurate in filesize. The downside is that you have to spend the time creating the compressibility test encodes. With current CPUs that is not a big problem IMO.

[robot1]

Here is the new version.
RB-Opt v0.25 (http://www.savefile.com/files/636578)
I've fixed all the bugs I was aware of, and now it fully supports CCE SP2 and parameters for Menu Encoding.
Consider the beta status of this version, as I need more testing, especially for the new features.

Next version will have bitrate redistribution and dynamic matrices selection (as requested by Boulder). Anyway i can add these features only when using CCE. I think DVD-RB generates the parameters for HC and QuEnc at runtime (there isn't the equivalent of Rebuilder.ECL). Can anyone confirm this?
(if there is a request, I could code the bitrate redistribution also for HC and/or QuEnc)

[Rippraff]

Thanks a bunch robot1, I'll give it a go. :)
Edit: Seems you don't like even numbers... :D

Cu Rippraff

[SpazzHH]

Ah robot1, Bless you.

[Boulder]

Next version will have bitrate redistribution and dynamic matrices selection (as requested by Boulder). Anyway i can add these features only when using CCE. I think DVD-RB generates the parameters for HC and QuEnc at runtime (there isn't the equivalent of Rebuilder.ECL). Can anyone confirm this?
(if there is a request, I could code the bitrate redistribution also for HC and/or QuEnc)Hey, that's great news :)

I think you are correct, DVD-RB creates the ini files on the fly based on the data in rebuilder.ecl. This means you can actually use any encoder to do the redistribution pass. Just do a constant quant/constant quality encode using the DVD-RB created avs files with any encoder you like and use the results to calculate the new average bitrates, then edit the rebuilder.ecl file accordingly. DVD-RB will happily do the rest.

[robot1]

Hey, that's great news :)

I think you are correct, DVD-RB creates the ini files on the fly based on the data in rebuilder.ecl.
I think rebuilder.ecl is used for the bitrate, but not for other parameters (matrices, dc precision...).

This means you can actually use any encoder to do the redistribution pass. Just do a constant quant/constant quality encode using the DVD-RB created avs files with any encoder you like and use the results to calculate the new average bitrates, then edit the rebuilder.ecl file accordingly. DVD-RB will happily do the rest.
Yes, that's possible and will be the first release. But what if I have only free encoders (HC and QuEnc) and want to run bitrate redistribution? Probably RB-Opt have to use also these encoders.

[Boulder]

I think rebuilder.ecl is used for the bitrate, but not for other parameters (matrices, dc precision...).I'm not sure..I think I've tampered with the ecl file and the changes have been there in the HC GUI.

Yes, that's possible and will be the first release. But what if I have only free encoders (HC and QuEnc) and want to run bitrate redistribution? Probably RB-Opt have to use also these encoders.You can simply use the avs files DVD-RB created, if needed, replace ConverttoYUY2 with ConverttoYV12 in them. Then for every avs file, create an HC ini file which does the CQ encode and run the ini files. For the calculations, you need the length in frames in every avs file and the average bitrate of every created m2v file.

The ini file can be as simple as this:
*INFILE d:\temp\dvd-rip\rebuilder\d2vavs\v01000000001001.avs
*OUTFILE D:\Temp\DVD-Rip\Rebuilder\D2VAVS\V01000000001001.m2v
*MAXBITRATE 8500
*PROFILE best
*ASPECT 4:3
*CQ_MAXBITRATE 4.000
*DC_PREC 10
*MATRIX mpeg
*WAIT 0
The only requirement for the redistribution pass is that every avs file is encoded in constant quality/quant mode using the exact same parameters. The encoder you wish to use (in DVD-RB or for the redistribution pass) doesn't matter :)

[Rippraff]

I think rebuilder.ecl is used for the bitrate, but not for other parameters (matrices, dc precision...).
No, DC precision is stored in rebuilder.ecl and matrices for CCE as well. But I don't know how matrices for HC are stored.

Cu Rippraff

[Boulder]

No, DC precision is stored in rebuilder.ecl and matrices for CCE as well. But I don't know how matrices for HC are stored.

Cu RippraffIt's easy to parse the matrices from rebuilder.ecl. In fact they could probably be used without any editing at all. Though I'm not sure if the format changes along with the different CCE versions.

[robot1]

RBOpt parses (and can edit) the rebuilder.ecl.
But will DVD-RB consider this editing for the actual encoding in HC?
Example:
segment 1 has DC precision = 10.
RB-Opt can change DC precision to 8 or 9.
Using CCE or Procoder, you will have the real encoding with the new parameter.
But what if you encode with HC or QuEnc? Will DVD-RB use it's internal parameter?
Same thing for other parameters (probably only bitrate editing will be taken in account).

[Boulder]

I'll give it a whirl. I'll run the prepare phase in HC mode to make sure it's HC-compatible rebuilder.ecl we're seeing and see what happens when I edit the items.

[Rippraff]

It's easy to parse the matrices from rebuilder.ecl.
There are no matrices in .ecl to be parsed if you choose HC for example.

Cu Rippraff

[Rippraff]

But will DVD-RB consider this editing for the actual encoding in HC?
Example:
segment 1 has DC precision = 10.
RB-Opt can change DC precision to 8 or 9.
Using CCE or Procoder, you will have the real encoding with the new parameter.
But what if you encode with HC or QuEnc? Will DVD-RB use it's internal parameter?
I guess RB will use the setting which are originally stored for CCE basic (intra_dc_prec=1) and will parse this to HC.ini.

But maybe we should stop the speculation and wait for jdobbs' reply. ;)

Cu Rippraff

[Voodoochild]

Hi I'm new to RB-Opt and played now with it to see what I can understand of it. I saw I can choose matrix from the DVD-RB folder even when using OPV.
I know CCE using the default Matrix of CCE when in OPV mode, can I change that using RB-Opt ?? If yes and I can do OPV with avamat6 for example that will be awesome.

10x Elad

[Boulder]

There are no matrices in .ecl to be parsed if you choose HC for example.

Cu RippraffYes, there are matrices.

qmat=
08 20 24 28 33 34 37 43
20 20 28 30 34 37 43 47
24 28 33 34 37 43 43 48
28 28 33 34 37 43 47 50
28 33 34 37 40 44 50 60
33 34 37 40 44 50 60 73
33 34 37 43 48 58 70 87
34 37 44 48 58 70 87 104
16 22 23 24 25 27 28 29
22 23 24 25 27 28 29 30
23 24 25 27 28 29 30 32
24 25 27 28 29 30 33 34
25 27 28 29 32 33 34 35
27 28 29 30 33 34 35 38
28 29 30 33 34 35 38 39
29 30 32 34 35 38 39 42
I did the tests and everything else except for the intra DC precision changed. There might be some key values to use (2 means DC precision of 10bits, that much I know), but jdobbs sure knows if he wishes to reply here.

[robot1]

Hi I'm new to RB-Opt and played now with it to see what I can understand of it. I saw I can choose matrix from the DVD-RB folder even when using OPV.
I know CCE using the default Matrix of CCE when in OPV mode, can I change that using RB-Opt ?? If yes and I can do OPV with avamat6 for example that will be awesome.

10x Elad
Yes, you can change matrices in OPV mode.

[robot1]

I did the tests and everything else except for the intra DC precision changed. There might be some key values to use (2 means DC precision of 10bits, that much I know), but jdobbs sure knows if he wishes to reply here.
Thank you for the test. It should possible to change HC parameters editing the rebuilder.ecl. Am I right?

[Boulder]

Yes, according to the quick test. The only thing that wouldn't change is the DC precision but it's possible that there are just some specific things you need to do to edit it.

[Sir Didymus]

Yes, Robot1, you are right.

The prepare phase is both logically and from the implementation point of view separated from the following encoding and rebuild steps. The "database" linking the prepare step to the following phases is exactely the rebuilder.ecl file. This holds for all of the supported encoders, AFAIK...

Best regards,
and thanks a lot for your tool!

Edit: don't know why the change of the DC prec. in the test of Boulder is not accepted, however... :confused:

[Rippraff]

Yes, there are matrices.
Guess what the problem was? I've forgotten that I had mistakenly OPV ticked... :rolleyes:

There might be some key values to use (2 means DC precision of 10bits, that much I know), but jdobbs sure knows if he wishes to reply here.
The precision is set for CCE Basic by:
intra_dc_prec=n
Where n is 1 for 8 bit, 2 for 9 bit, and 3 for 10 bit.
Edit: Made some additional tests:
For HC it seems
n is 0 for 8 bit, 1 for 9 bit, and 2 for 10 bit (which is also default/auto)

Cu Rippraff

[Boulder]

Setting intra_dc_prec to 0 doesn't change anything here...it's still 10bits.

[Rippraff]

Well, what I wrote above are only the rebuilder.ecl entries, I can't tell anything how jdobbs parse this to HC.ini.

Cu Rippraff

[Sharc]

Awesome! Thanks robot1 for the new version!

[jdobbs]

Ok... I zipped through the numerous posts -- hope I got the gist of it.

The ECL file is used by DVD-RB to set the values for HC on the Pro Version. It is read and interpreted, and an INI file is generated at encode time. For DC_PREC the value comes from REBUILDER.INI (or the associated project file) using the "DCPrec=n" (which is set by the selection in the OPTIONS tab) -- if n = 1 it sets it to 8 bit, 2 to 9 bit, and 3 to 10 bit. Zero uses the encoder default.

Lots of values are derived from the ECL, including:

- Aspect Ratio
- OPV setting
- Bitrates (min, average, and max)
- progressive/interlaced settings
- TFF or BFF
- The selected Matrix.
- Input/Output filenames.

[Boulder]

Yep, I kind of guessed that DC precision would be in the ini file because editing wouldn't work.

What happens when you prepare a project, then edit DC prec in the DVD-RB options and then exit DVD-RB, open it again and begin encoding? Would it be possible to add the feature to use the value set in rebuilder.ecl in DVD-RB?

[jdobbs]

For CCE the value is set... because it was already added to the ECL file. For HC and QuEnc, it is read at startup or when a project is loaded, and only changes when it is done via the Options Panel. I could make it read the value from the ECL file easily enough...

[Boulder]

IMO it would be great if all the settings were available in the ecl file, at the moment the DC precision is the only one not available there :)

[jdobbs]

GOP size is also read from the INI rather than the ECL. I'm trying to decide whether moving it is a good idea. If it's stored in the ECL file, you'd have to reaccomplish the PREPARE in order to change it. But, on the other hand, that's how it is with CCE now (since it uses the ECL no matter what).

[Voodoochild]

Hi
I saw that Q value from DVDRB is Different from RB-Opt.
DVDRB uses 2% of the movie, I think as default while RB-Opt use 1% even though that can be changed easily.

My Question, is it better to set the DVD-RB Q value with RB-Opt, or to let RB-Opt to do its own calculation?

10x
Elad

[Boulder]

Does the rebuilding phase need the GOP length and structure information? Many times I've had to rerun the prepare phase because I've forgotten to switch GOP length to 15 frames or to auto depending on the encoder I've used.

[Boulder]

Hi
I saw that Q value from DVDRB is Different from RB-Opt.
DVDRB uses 2% of the movie, I think as default while RB-Opt use 1% even though that can be changed easily.

My Question, is it better to set the DVD-RB Q value with RB-Opt, or to let RB-Opt to do its own calculation?

10x
EladYou can't say, it's more like a matter of luck. Theoretically, the larger the sample size, the better the accuracy but in real life, it's not that simple. The calculations probably differ as well. tylo's CCEFront has a quite good accuracy, I don't know if either DVD-RB or RB-Opt uses its method.

[Voodoochild]

You can't say, it's more like a matter of luck. Theoretically, the larger the sample size, the better the accuracy but in real life, it's not that simple. The calculations probably differ as well. tylo's CCEFront has a quite good accuracy, I don't know if either DVD-RB or RB-Opt uses its method.

10x Boulder, I guess I'll use DVD-RB Q value, if that comes undersize by match or Oversize, I can always set the opv higher / lower and encode again.

10x
Elad

[Boulder]

I caught some bugs in v0.25beta: when you are in Tweak Cells menu and use the arrow up or down keys on your keyboard, the focus jumps to the first cell. This also at least once reset all the changes I had made.

Also when I had edited the avg bitrates, applied the changes and then tweaked the average bitrate of the whole VTS in the main window to avoid oversizing, the bitrates were reset to the original values. I don't know if this is done on purpose, DVD-RB does the same thing. Still it's not convenient at all :)

EDIT: actually when you tweak the cells, click on apply and then go back to tweaking them, the bitrates are reset. The "autosized" tick box is not reset though.

[robot1]

I caught some bugs in v0.25beta: when you are in Tweak Cells menu and use the arrow up or down keys on your keyboard, the focus jumps to the first cell. This also at least once reset all the changes I had made.
Thank you for your report.
This bug is fixed for v0.26beta.


Also when I had edited the avg bitrates, applied the changes and then tweaked the average bitrate of the whole VTS in the main window to avoid oversizing, the bitrates were reset to the original values. I don't know if this is done on purpose, DVD-RB does the same thing. Still it's not convenient at all :)

EDIT: actually when you tweak the cells, click on apply and then go back to tweaking them, the bitrates are reset. The "autosized" tick box is not reset though.
I'm not sure about your process.
You should:
1) tweak avg bitrates (in the main windows)
2) tweak single cells bitrates.
If you change the avg bitrate of the VobID (even if you join vobid's and then change the avg bitrate) you lose your edits.
Please report back your results.

[humax]

Nice - a new version available

thx robot

[Boulder]

I'm not sure about your process.
You should:
1) tweak avg bitrates (in the main windows)
2) tweak single cells bitrates.
If you change the avg bitrate of the VobID (even if you join vobid's and then change the avg bitrate) you lose your edits.
Please report back your results.
I just got it reproduced.

1) Tweaked a couple of avg bitrates of in Tweak cells.
2) Switched to Excel (Office 2003) to get more numbers to feed. I didn't actually do anything, just ALT+TABbing there and then back again.
3) Bitrates were reset.

I noticed that it doesn't happen every time but very often.

Try disabling autosized from the first cell, then enter some value in the input field. Choose the second cell and switch to Excel (I don't know if any other programs cause this, maybe it's just the Office 2003 package), then switch back to RB-Opt. The first cell is reset. If you have tweaked many cells, all of them will be reset.

When you tweak only one cell and keep it selected when switching to Excel, the cell is not reset. When it is not selected, it will be reset.

The funny thing is that you don't even need to do anything in Excel:confused:

[Sharc]

@Boulder:
I could reproduce this 'oddity' here.
Workaround is to adhere to this sequence:
1) Tweak the cells in RB-Opt
2) Push <Apply> (=> Close the "Tweak Cells" window)
3) Switch to Excel
4) Switch back to RB-Opt and push <Tweak cells>
5) go to 1) ......

Not so convenient, but it will preserve your tweaks.

Actually it's not related to EXCEL. It happens whenever the "Tweak Cells" window looses focus.

[Boulder]

Actually it's not related to EXCEL. It happens whenever the "Tweak Cells" window looses focus.When I wrote that, I had tried switching to DVD-RB and Notepad but they didn't cause the problem, I could reproduce it only with Excel:devil:

[robot1]

Actually it's not related to EXCEL. It happens whenever the "Tweak Cells" window looses focus.
Ok, bug reproduced.
:devil:

[Boulder]

If you change the avg bitrate of the VobID (even if you join vobid's and then change the avg bitrate) you lose your edits.This option is something that would be nice to expand so that when you have edited the bitrates and touch the average bitrate of the VOBID/joined VOBIDs, the adjustments would be done according to the edited values instead of the original ones. This means that the calculations would have to be adjusted so that the ratios of avg bitrates between cells remain the same.

[robot1]

Here is the new version, with some new features and bug fixing
RB-Opt v0.26 (http://www.savefile.com/files/648426)

Changelog:
Fixed the bugs reported in the posts previous posts
Added a new feature: "Bitrate redistribution". This feature now works with CCE (and also with ProCoder2 and AQE). I will support HC and QuEnc for the next release.

In short, the idea is by Boulder in the thread http://forum.doom9.org/showthread.php?t=122351
For 99.9% of the discs, the way DVD-RB allocates the bitrate is optimal. But there are some bad mastered discs, encoded in CBR. In these cases the default bitrate allocation is sub-optimal.
For these backups, an OPV method could give better quality.
With the "Bitrate redistribution" you can have an encoding similiar to OPV, but with two advantages:
1) Perfect size
2) ability to further tweak the end credits cell, and/or use different matrices.

I will appreciate some feedback.
Mich

[Boulder]

I ran a test on Cold Feet, season 5, disc 1. After the redistribution, RB-Opt suggested new bitrates which were all negative. Here's the ecl file DVD-RB created: http://www.megaupload.com/?d=Y5Z23D3U

A suggestion to HC and QuEnc related parts: the ability to use more than one encoder as in DVD-RB. It will make redistribution faster by a fair bit.

I was able to reproduce the "clicking on the VOBID causes values to go all crazy". It happens after the redistribution pass has been done and the new values are accepted. Then I just clicked once on the VTS I had done the redistribution on and it happened.

[gurkan]

Tried RB-opt for the first time, the new distribution function being the main reason.
Must say that I thought it was terrific.
IMHO I think that BIG3 used to produce better results than DVD-RB when it came to dealing with CBR-sources. Nice to see that combined with RB-opt this is no longer true.:thanks:

BTW, DVD-rb complained about "item.m2v" during rebuild. I assumed this was a temp-file created for the opv, so I just deleted it and tried it again and it seemed to work.

[robot1]

BTW, DVD-rb complained about "item.m2v" during rebuild. I assumed this was a temp-file created for the opv, so I just deleted it and tried it again and it seemed to work.
Yes, you can delete the file. I've already fixed this little bug for next version.
Anyway, consider bitrate redist is in early beta stage.
Use it for a VobID (or a set of VobID linked in a VTS)without the "autosized" flag, and as last step before rebuilding. Opening the rebuilder.inf again in RB-Opt could cause problems. Next version will fix these bugs.

IMHO I think that BIG3 used to produce better results than DVD-RB when it came to dealing with CBR-sources. Nice to see that combined with RB-opt this is no longer true
We have to thank Boulder for the idea :)

[jdobbs]

IMHO I think that BIG3 used to produce better results than DVD-RB when it came to dealing with CBR-sources.Well, just MHO -- but I still think that if you have a CBR source the best you can do is a bitrate that is equal to the one used in CBR... otherwise you'd have to be getting the additional missing detail out of the cosmic ether. DVD-RB sets the max to the CBR rate because anything higher would probably only amplify the error (blockiness).

But, as I always say, too each his own.

[Boulder]

Well, just MHO -- but I still think that if you have a CBR source the best you can do is a bitrate that is equal to the one used in CBR... otherwise you'd have to be getting the additional missing detail out of the cosmic ether. DVD-RB sets the max to the CBR rate because anything higher would probably only amplify the error (blockiness).

But, as I always say, too each his own.As I wrote in that redistibution thread, the method tries to minimize the extra distortion caused by recompression. This is achieved by using an optimal bitrate curve instead of the one provided by the original encode.

There is a big difference between encoding at q3 and q5, be it recompression or encoding from a lossless source, and this is what may happen if the original, CBR-based distribution of bits is used. The method I suggested shifts the bits so that every cell is encoded at roughly the same quant.

@robot1: you need to edit your post a bit: as last step before rebuilding-->as last step before encoding:) I've never unchecked "autosized" before doing the redistribution, does it still change the avg bitrates or do the pass but leave them unaffected?

[jdobbs]

This is achieved by using an optimal bitrate curve instead of the one provided by the original encode. Ok. I get what you're saying. It's not the maximum bitrate -- but the distribution between segments that is the problem. What I don't understand is why using OPV alone wouldn't solve it, since it redistributes bits between segments based upon quality.

[Boulder]

OPV does solve the problem but it has its problems, unpredictability being one of them. Doing the redistribution pass has the best of both worlds, the constant quality from OPV and the accuracy from a multipass encode. Of course, the downside is the extra time it takes, but a modern CPU doesn't need that long to do the extra pass.

Also the option to include several VTSs/VOBIDs (coming up sometime, I assume) to the redistribution improves quality. There are series DVDs in which every episode is in its own VTS which are the same size regardless of the complexity of the content. The redistribution will fix this issue, OPV cannot do that.

[gurkan]

anything higher would probably only amplify the error

I guess this is the part I don't understand.
I know that this is a rather crippled analogy, but if you save a jpg-picture with
the same low quality-setting twice, the result would be inferior to saving it the
second time with a better quality-setting.
And if there is an excess of bits laying around in, let's say a slow out of
focus scene in one vob-id, then why not use it for a fast moving detailed scene in
another vob-id instead?

[FredThompson]

OPV window is showing up when the "Save Settings" button is pressed. It should not do this unless OPV is requested.

[robot1]

OPV window is showing up when the "Save Settings" button is pressed. It should not do this unless OPV is requested.
Could you check if there is a short segment encoded in OPV, even if the main segment is VBR ?
Could you send me the rebuilder.inf and the rebuilder.ecl (modified and original) - my email adress is in the readme.

[FredThompson]

Nothing was encoded. I did the preparation phase then tried to reduce the global total by 3M. I'll have to recreate this for you. Give me a day. It's after 5AM and I have been up all night. Time for some sleep.

[gurkan]

Pulled up the sample to 100% to increase accuracy. This managed to recreate the bug Boulder mentioned before.
during encode the reported bitrates look fine but when they're summarised in the final state they turn into negatives.

[robot1]

Pulled up the sample to 100% to increase accuracy. This managed to recreate the bug Boulder mentioned before.
during encode the reported bitrates look fine but when they're summarised in the final state they turn into negatives.Thank you for your report.
This bug is fixed for next release (I think I will release it tomorrow).
With 0.26 beta, please use at maximum a sample of 50%.

[gurkan]

Thanks for the quick updates.
BTW, since the opv is only used as an analyze-pass to get the right bitrates, does it really matter what I set as Q Factor?

[Boulder]

No, it doesn't matter. I recommend a value that doesn't make the bitrate bang the maximum constantly because it will distort the curve. I usually use Q30, sometimes Q40 if the material is high-motion and/or interlaced.

[jdobbs]

Not sure if I'm understanding completely... But if you're using CCE's OPV to do a first pass it definitely makes a difference if your are not close to the bitrate. Here's a quote from the CCE manual:

... a video information file should be
recreated when you made a substantial change in bitrate setting. The
change of bitrate setting may not cause an error, however a renewed
information file will bring the better results in limited number of encoding
passes. When an average bitrate is increased twice or more or
decreased less than half, it is better to recreate the video information
file.

[Boulder]

The vaf file isn't used in anything in the redistribution pass, the only function is to gather information to tweak the bitrate. The actual encoding happens normally.

[gurkan]

Would you consider Terminator 2 dir. cut PAL high motion? It´s one of my favourite reference-movies. Doing it right now on q30. I know it´s not cbr but it´s one of the movies that to my eyes looked better in big3´s hands. Thought that the optimal bitcurve on 8gb vs 4.37 would differ a bit. Plus that the raw-material changes after the first encode.

[robot1]

Anyway I think that using the right Q value (the one you would use for an opv disc) would give the maximum quality, as encoding is a non linear process.
If time doesn't matter, you could use a Q prediction before the redistribution step.
Anyway, if you want to use 100% sample, wait for next version, ore use this test build:
http://www.savefile.com/files/661393
I'd be glad to receive feedback about the quality you get.

[gurkan]

Cheers! Will try it out.

[gurkan]

Bitrates don't come back negative with the new build. =)

[jdobbs]

The vaf file isn't used in anything in the redistribution pass, the only function is to gather information to tweak the bitrate. The actual encoding happens normally.I guess I don't understand what you're doing then. So you don't perform the second part of a two part (OPV/VBR) encode?

[Fishman0919]

The vaf file isn't used in anything in the redistribution pass, the only function is to gather information to tweak the bitrate. The actual encoding happens normally.

Yes for that "Q" setting or bitrate...or something real close... if the bitrate is changed quite a bit. The .vaf from the OPV is pretty useless.

[Boulder]

I wrote a small FAQ which I will post in the redistribution thread. I think we should discuss the method there to keep this thread cleaner.

The thread is here : http://forum.doom9.org/showthread.php?p=992511

[Sharc]

Anyway I think that using the right Q value (the one you would use for an opv disc) would give the maximum quality, as encoding is a non linear process.
If time doesn't matter, you could use a Q prediction before the redistribution step.


That would suggest to include in RB-Opt as a first step a (say 1%, does not take much extra time) Q prediction automatically and to base the bitrate redistribution on that initial Q estimate rather than on some fix value.

[robot1]

Updated version:
RB-Opt v0.27 beta (http://www.savefile.com/files/673077)

Changelog:
Fixed bugs and improved "Bitrate Redistribution" (now you can use 100% sample size).

Added Support to HC and QuEnc in "Bitrate Redistribution".
For HC and QuEnc the Q parameter is in CCE scale (is divided by 10). Example: to use Q=4.5 in HC you have to insert 45.

Various minor bug and cosmetic fixes.

[robot1]

That would suggest to include in RB-Opt as a first step a (say 1%, does not take much extra time) Q prediction automatically and to base the bitrate redistribution on that initial Q estimate rather than on some fix value.
You can predict Q value for CCE:
set the vobid as OPV.
Save and start prediction.
When you have found the Q value, cancel saving, and set again the vobid as VBR.
Start the bitrate redistribution, using the Q value found.

It's not very simple... on request I could automatize these steps.

[Sharc]

Thank you, yes, that's how I did it manually to find the "correct" Q for the subsequent redistribution.

Anyway, if you would find the time to automate these steps in a coming release I think that RB-Opt would be the first solution to solving the imminent and much discussed file size problem (undersized / oversized) of OPV, with all the benefits of encoding speed, quality and now even file size accuracy.

An encouragement rather than a request :)

[~bT~]

1st try using v0.27 and spot on 4.36GB! I had previously done the same DVD and it was undersized. Lets see how the next one goes..

[gurkan]

I'm curious if it's possible to make a variable Quantizer Characteristics. Or at least make the setting changeble betwen the segments.

[robot1]

I'm curious if it's possible to make a variable Quantizer Characteristics. Or at least make the setting changeble betwen the segments.
For every VobID, you can change the Quantizer Characteristic in the CCESettings window. I don't think it's necessary to have a variable quantizer characteristic for two reasons:
1) I don't see a straight relationship between quantizer characteristic and other parameters (length, bitrate)
2) Default value often works well.

[~bT~]

on request I could automatize these steps.Yes pls! :thanks:

[archaeo]

Have tested two discs now with v27b using bitrate redistribution, and both have been right on the money. Very pleased with this feature. I have been going with a 3% sample size for initial Q prediction, and a 15% sample for the actual redistribution step.

The automation step would be a plus, but can you retain the sampling size choice for both steps?

[~bT~]

^ I've just done the 2nd one. Also spot on. Sample size for Q=2% and for RD=20% without filters.

[Sharc]

I have tested v0.27 using bitrate redistribution with 0.5% for initial Q estimation and 33% sample size for the actual redistribution. I used avamat6 (aka AutoQ1) matrix.
=> Target size was hit on the spot. Quality is excellent.

The significant difference for some of the segments between the original average bitrate and the new bitrate after the redistribution is amazing: The orignal size reduction was about 62%, same for all segments of course. After the redistribution the reduction for the individual segments was between 11% (end credits, bold white letters on black background) and 83% (demanding scenes). Just as an example, the end credits were given an original average bitrate of 3350 kbps, after the redistribution the average rate was 603 kbps with no noticeable loss of quality.

These results underline Boulder's idea. Thanks Boulder for sharing your experience, and thanks robot 1 for implementing it in RB-Opt.:)

[~bT~]

Its seems like whichever way u do it, the combo of both hits on target. Good stuff!

[gurkan]

For every VobID, you can change the Quantizer Characteristic in the CCESettings window.

I wasn't aware of this. No reason to implement something that's already there. :-)

I'm backing up a movie with a ridiculousley low bitrate (to keep the commentary-track). All the segments look fine with a certain quantizer characteristic, except for one. And changing the setting for all would make the other segments look bad.

Making a variable quantizer would probably be virtually impossible anyway, since beauty's in the eye of the beholder.

[robot1]

The automation step would be a plus, but can you retain the sampling size choice for both steps?
I'm working to add this feature to next release.

[archaeo]

I'm working to add this feature to next release.

:) excellent

[tom942]

If I want try bitrate distribution with HC, could I use as Q value the one that I get with CCE for OPV?.

For instance, if I get Q=16 with CCE, could I use that value with HC?.

And will you implement OPV for HC in the same way that you did it for CCE?

Thanks :).

[robot1]

If I want try bitrate distribution with HC, could I use as Q value the one that I get with CCE for OPV?.

For instance, if I get Q=16 with CCE, could I use that value with HC?.

And will you implement OPV for HC in the same way that you did it for CCE?

Thanks :).
For HC you have to use the value in the same scale of CCE: if you want to use 1.6, you have to insert 16.
Anyway, the optimal Q in CCE will not be the optimal Q for HC.
I've implemented the optimal Q finding in HC. Next version will be ready in a couple of days.

[tom942]

For HC you have to use the value in the same scale of CCE: if you want to use 1.6, you have to insert 16.
Anyway, the optimal Q in CCE will not be the optimal Q for HC.
I've implemented the optimal Q finding in HC. Next version will be ready in a couple of days.

Okey. Then I'll wait to try your next release :).

BTW, I have just done a CCE test with Casino Royale R2 with two AC3 tracks and menus with motion, following Boulder's suggestion from the other thread (except I have used Avamat6) and the image quality is :eek:, with an average bitrate of 3223 kbps. The bitrate in some segments changes near 1000 kpbs :).

[robot1]

Here is the new release
RB-Opt v. 0.28 (http://www.savefile.com/files/693580)

Changelog:
Added Automatic Q find in "Bitrate Redistribution" (works also for HC).
New setup dialog.

[~bT~]

thanx mate! will test it out over the weekend. cheers!

[Rippraff]

Thanks robot1. :)

Small typo by the way. ;)

Cu Rippraff

[robot1]

:)
typo fixed for next release.

[Sharc]

Thanks robot1 for the new version.

Suggestion:
When changes have been made and pressing the "EXIT" button without "Save settings" before, a warning should be displayed "Exit without Saving? Yes / No". Otherwise there is a risk that the changes will be lost.

[jdobbs]

Maybe I'm a little confused. I wanted to do some testing with the redistribution method... but when I save it and compare the ECL file to the original, it doesn't seem to change???

[tom942]

I'm using latest DVD-RB free. I would like to know if it is possible to use with HC a diferent matrix than MPEG (like AVAMAT6) or a diferent DC when it does the OPV prediction and later the BD.

Would it be a good idea to implement something similar to "CCE settings" but for HC?. Another button where you could set the matrix, dc, bias..., and even pass some arguments?

Regards and thanks for this great "little" app :)

[Rippraff]

Using custom matrices is a feature which is only available in the Pro version.
Thinking of jdobbs' well deserved donations I hope this (http://forum.doom9.org/showthread.php?p=727052#post727052) is still valid.

Cu Rippraff

[tom942]

I'm waiting a credit card that I request for send money to jdobbs among other users of the forum :). It will be my first purchase through paypal :).

Meanwhile, I just asked if it could be possible to implement it in RB-OPT :).

Regards,

Tom

[jdobbs]

If people started adding Pro capabilities to the freeware version there wouldn't be a lot of incentive for me to keep developing DVD-RB, would there?

[tom942]

@jdobbs

Don´t get me wrong. I'm agree with you, but I thought it couldn´t interfere with Pro version in the same way that already there is an option for CCE settings, so why not other for HC.

Please, I didn´t wanted to bother you. Sorry :(

[robot1]

DVD-RB free version doesn't use the .ecl to pass parameters to HC. It's not possible to tweak HC settings with the free version.
I suggest you to upgrade to pro, it's a great step ahead.

[tom942]

Thanks for the clarification :)

[manolito]

AFAIK the free version 0.98.2 of DVD-RB supports HC with custom matrices quite nicely. You just have to specify the desired matrix in the HC.ini file. The line in HC.ini could look like this:
*MATRIX AVAMAT7

DVD-RB free does not try to manipulate the HC.ini at all because it thinks it is dealing with QuEnc.

Cheers
manolito

[tom942]

@Manolito

It is what I'm doing, but I just wanted to try the new method of Bitrate Distribution with RB-OPT.

But instead of using the matrix, the DC or the bias that I've got set under HC.ini (AVAMAT6) in DVD-RB, RB-OPT uses MPEG matrix and its own DC. I mean it overrides my HC.ini, and this was the thing I asking for, nothing else.

And like RB-OPT allow to modify all these things for CCE, I just asked for something similar for HC (like a menu). The only thing that I would like is can use the settings from my HC.ini in the prediction of RB-OPT. :)

PS: Excuse my english. It is not my mother tongue. I hope to express well.

[Sharc]

@robot1:
RB-Opt includes a very handy AVS editor. It is applicable on a per VOB-ID basis.
Would it be possible - in a future version - to allow the AVS editing on a per cell basis as well, for example in the "tweak cells" window? This would be very handy for filtering individual scenes differently or selectively.

[dirio49]

@robot1
Thanks for the new version.
One suggestion.
In the redistribution, it would be nice if we had a choice to exclude some cells for the redistribution.
Like credits, that i like to just kill. with the lowest bitrate .
thanks

[Sharc]

I had again a case:
After redistribution and pressing OK, the new cell bitrates were not transferred to the ecl.
Not sure however if I pressed the button sequence OK => EXIT, ie skipping Save Settings.
Should I - after redistribution - always press OK => Save Settings => (Settings Saved) OK => Exit?

[Boulder]

I always do the save settings part, it probably is needed to save the new bitrates.

[Sharc]

@robot1:
When I blank the first cell of a VOB-ID by means of the DVD RB editor, the subsequent Q estimation or OPV prediction of RB-Opt fails to deliver correct results.

Trying to run the AVS editor in RB-Opt delivers the (correct) error message of unequal lengths of the avs script files -- due to the previous blanking of cells with the DVD Rebuilder editor.

When I unblank the first cell everything works correctly.

[robot1]

@robot1:
RB-Opt includes a very handy AVS editor. It is applicable on a per VOB-ID basis.
Would it be possible - in a future version - to allow the AVS editing on a per cell basis as well, for example in the "tweak cells" window? This would be very handy for filtering individual scenes differently or selectively.
Sorry for the late reply, I was away.
Yes, it will be possible, and I will add this feature.

[robot1]

@robot1
Thanks for the new version.
One suggestion.
In the redistribution, it would be nice if we had a choice to exclude some cells for the redistribution.
Like credits, that i like to just kill. with the lowest bitrate .
thanks
You should have the redistribution step, than tweak the end credits cell to the lowest possible value. The saved bitrate will be given to the other cells.

[robot1]

Should I - after redistribution - always press OK => Save Settings => (Settings Saved) OK => Exit?
Yes, you have always to save the settings to make changes permanent.

[robot1]

@robot1:
When I blank the first cell of a VOB-ID by means of the DVD RB editor, the subsequent Q estimation or OPV prediction of RB-Opt fails to deliver correct results.

Trying to run the AVS editor in RB-Opt delivers the (correct) error message of unequal lengths of the avs script files -- due to the previous blanking of cells with the DVD Rebuilder editor.

When I unblank the first cell everything works correctly.
I have to fix this. It's easy if you blank the first or the last cell, and I think that next version will have this fix. It's more troublesome when you blank a cell in the middle (but it's a very rare case).

[Sharc]

:thanks: for considering my proposals in a future release.

[Sharc]

Yes, it will be possible, and I will add this feature.
Thanks for taking this into consideration.
I imagine that it may become difficult for the OPV prediction when individual cells have different filter scrips. I would assume however that only very few cells (1 or 2) in a VOB-ID will need an individual filter script, hence the OPV prediction reliability should not be unduly affected.

[~bT~]

Feature Request:

Option to select starting Q factor.

[Dashiell]

Hey guys,

This may be a dumb question, I'm not an RB noob but I am an RB-OPT noob.

I see that you can select the CCE filters and select the "Natural Filter" without a problem, but does it actually stick? I've heard tale that it cannot be activated/used with CCE Basic. I own Basic 2.70.1.15.

Thanks!

[Sharc]

@robot1:
When Rebuilder assigns different -- ie bitrate dependent -- matrices to the cells within a VOB-ID, RB-Opt will ask for a manual re-assignment of a specific matrix for redistribution. Means in the subsequent encode the bitrate dependent matrix selection will be lost.
Don't know if this could be fixed in a future release.

[robot1]

Hey guys,

This may be a dumb question, I'm not an RB noob but I am an RB-OPT noob.

I see that you can select the CCE filters and select the "Natural Filter" without a problem, but does it actually stick? I've heard tale that it cannot be activated/used with CCE Basic. I own Basic 2.70.1.15.

Thanks!
I think CCE basic hasn't filtering capability.

[robot1]

@robot1:
When Rebuilder assigns different -- ie bitrate dependent -- matrices to the cells within a VOB-ID, RB-Opt will ask for a manual re-assignment of a specific matrix for redistribution. Means in the subsequent encode the bitrate dependent matrix selection will be lost.
Don't know if this could be fixed in a future release.

OPV prediction couldn't be exact if there are different matrices in the segments.
Anyway, I could disable this check only if you calculate Q factor in the redistribution step, as optimal Q isn't fundamental.

[Sharc]

Yes, for OPV this is definitely a problem. and one should stick to one single matrix.
For redistribution, disabling this check would be useful because redistribution normally even increases the swing of the average bitrates, hence preserving (or even automaticallly re-assigning ?) the bitrate dependent matrix selection would be beneficial to the final result, IMHO.
Thank you for considering this possibility.

[Dashiell]

I think CCE basic hasn't filtering capability.

Yes, this is true.

I am told, however, that the four "basic" filters contained within CCE are present in every version.

Natural, Animation, etc, etc...

[Video Dude]

CCE Basic has 3 filter presets: Natural Picture, Computer Graphics, and Animation.

But you can't customize or tweak the filter options. You are limited to the 3 presets only.

[Snarko]

This bitrate redistribution and automatic Q finding stuff is great!

I'm using HCEnc 0.21, and generally not using the MPEG default matrix. Is there any way RB-Opt could use the matrices specified in DVD-RB Pro to calculate the Q and redistribution passes, instead of always using the MPEG matrix? Or is it about as close as matters already, even if a matrix like AVAMAT6 compresses more than the MPEG matrix? Thanks.

[gurkan]

CCE throws me a "OPV VBV ovf frame# 124812 (01:23:12:14) I 81616 max 81327,95 rel 288,05,1,00 qsv 4,90->5,41".
This happens in the opv prediction (sample 100%) before Bitrate Redistribution, during second pass when it tries to go for Q=1.
Max Bitrate in RB-Opt settings says 8014.
Any tips on how I can avoid this kind of error?

[Boulder]

Set the Q value manually to something higher than Q1.

[gurkan]

If it's setting the q-value of the redistribution to an arbitrary guess that you mean, than sure I could do that.
But I would've really liked RB-Opt to calculate the optimal Q for me instead since I don't really trust my guesses.
Sorry if I've misunderstood you.

[Boulder]

Well, I don't think it really is crucial to predict the Q value for redistribution. In fact, I never do that myself when I use HC. The ratio between different segments should remain pretty much the same, although that should be tested to be sure.

[Sharc]

I did various tests regarding the impact of the Q-factor on redistribution with CCE.
It appears that there exists an asymptotic behaviour:

a) For very low Q factors (Q=1,2,3) the redistribution follows more or less the standard multipass VBR distribution of DVDRB
b) With increasing Q facor the redistribution deviates more and more from the standard multipass VBR curve, generally increasing the swing
c) With further increasing Q, the redistribution converges to an asymptotic redistribution which does not change much when Q is further increased.

Q-factors that correspond to the DVD-5 target size are normally in the asymptotic range of c).

In the graph below, Q=18 would approximate the DVD-5 target size. There is little change when increasing Q to 64 for setting up the redistribution profile.

The tests I did apply to CCE.

[Sharc]

And here another example showing the influence of Q on the redistribution, for Q=1, 12, 64.
Q=12 applies for a DVD-5 target size and produces the same profile which one would get for standard OPV.

[Sharc]

The Q factor for a given target size depend heavily on the selected matrix -- for example Q=9 for Avamat6, Q=18 for CCE Default, Q=58 for FHE for the same title.

After having done more tests with the selection of Q for redistribution, my recommendation is to do the redistribution with a Q factor which approximates the target size for the selected matrix or to let RB-Opt do the choice -- a small sample size of 0.5% to 1% is sufficient. With a Q corresponding to the target size, the redistribution even becomes fairly independent of the selected matrix.
All my test are with CCE.

When a low Q is selected with a high bitrate matrix like FHE, I noticed that CCE may be aborted, skipping the rest of the cell -- possibly because the bitrate becomes excessive (?).

[Boulder]

I actually thought that the redistibution is always done using the MPEG standard matrix. That's what is used with HC at least, no matter what you have chosen to use in DVD-RB.

[Sharc]

You can select any matrix for redistribution with CCE and RB-Opt, using the "CCE settings" button in RB-Opt.

I have no experience with HC and OPV for redistribution though. Unfortunately, for some odd reason, I cannot run HC in OPV mode on my system. It does not produce an OPV test file.

[Sharc]

Here a plot for differnet matrices.

Q always corresponding to a DVD-5 target size for the given matrix. The redistribution then appears to be fairly independent of the matrix.

[Boulder]

Do you have XviD or DivX5 or higher installed? HC needs an YV12 decoder to work.

[Sharc]

Yes, I have DivX5 and ffdshow (XviD) installed.
HC runs perfectly in multipass mode, it only fails when I want to use it for OPV or redistribution when generating the testfile for Q estimation. Seems to be something wrong with the avisynth script. I double checked it, but I did not find anything unusual.

[Boulder]

Could you post the script that is used for the prediction and also the ini file? You should also be able to see an error message in the HC GUI window if there is something wrong.

[Sharc]

Thank you for your help.

In order not to deviate from the main subject of this thread I suggest to continue this discussion in my former thread:
http://forum.doom9.org/showthread.php?t=122803.

Thanks again.

[Insomniak4700]

ATM, the bitrate redistribution has to be run one VTS at a time... Would it be possible to have an option to run it on multiple VOB IDs at the same time? This could be usefull for episodic discs

[~bT~]

ATM, the bitrate redistribution has to be run one VTS at a time... Would it be possible to have an option to run it on multiple VOB IDs at the same time? This could be usefull for episodic discs
I was going to post this request too. Not only episodic DVD's but some movies have multiple VTS' too. :)

[Sharc]

@robot1:
Bitrate prediction for OPV and Redistribution:

Based on the % value for the sample size, the sample size may become too small for a reliable bitrate allocation for small cells.
I would therefore suggest to base the sample size on a function like:
SampleSize=Max(percentage;number of frames)

with
percentage = the percentage as selected in RB-Opt
number of frames=500.

Means at least 500 frames (or the entire cell if it should be smaller than 500 frames) will be included in the sample. This should be adequate for a reliable bitrate estimation.

This issue has been recently addressed by jdobbs:
http://forum.doom9.org/showthread.php?p=1012292#post1012292

[robot1]

ATM, the bitrate redistribution has to be run one VTS at a time... Would it be possible to have an option to run it on multiple VOB IDs at the same time? This could be usefull for episodic discs
This is in my Todo-List.

[robot1]

@robot1:
Bitrate prediction for OPV and Redistribution:

Based on the % value for the sample size, the sample size may become too small for a reliable bitrate allocation for small cells.
I would therefore suggest to base the sample size on a function like:
SampleSize=Max(percentage;number of frames)

with
percentage = the percentage as selected in RB-Opt
number of frames=500.

Means at least 500 frames (or the entire cell if it should be smaller than 500 frames) will be included in the sample. This should be adequate for a reliable bitrate estimation.

This issue has been recently addressed by jdobbs:
http://forum.doom9.org/showthread.php?p=1012292#post1012292
I have read the thread, and right now I was coding that.

[robot1]

Here is the new build:
RB-Opt v. 0.29 beta (http://www.savefile.com/files/801164)

Changelog:
Used dvd-rb defined matrices in Bitrate redistribution for HC and QuEnc.
Allowed different matrices and parameters in the segments to redistribuite.
Fixed a minimum sample length for cells to encode in bitrate redistribution (default 500, can be changed in the RB-Opt.ini)
Disabled Scene Change detection for HC encoder in bitrate redistribution, to have a better size estimate.
Handling of cells set to "no reencode", "blank" or "slideshow" in DVD-RB Segment Editor
In avs editing, if the script for the first cell or the last one is different, the different cell is ignored (example: only one cell interlaced - usually the last one). It's possible to edit the .avs for all the standard cells of the VobID


Next version will have redistribution among different VTS's

[~bT~]

Awesome job mate! Thanx a lot!

[Sharc]

Thanks! Useful improvements which I will definitely try out.

[archaeo]

Next version will have redistribution among different VTS's

Great :) I am very appreciative of the renewed energy that you have been applying toward RB-Opt development as of late - many thanks.

[Insomniak4700]

Here is the new build:
RB-Opt v. 0.29 beta (http://www.savefile.com/files/801164)


Thanks robot1! While I was trying the last version yesterday I was wondering how much of an impact not using the same Q matrix would have! I can compare the two now!

[TomBrooklyn]

Hi,
Nice work robot1. I didn't want to read through all 16 pages of this thread, but I read in the beginning that the first beta was not supporting HC. Is it usable with HC now? Regards, TomBk

[Boulder]

Hi robot1,

here are some small comments regarding using HC:

1) When doing bitrate redistribution and you choose to calculate the optimal quantizer to use, the "ignore filters" option is not considered in the prediction phase. (this probably applies to all encoders)

2) In the forementioned prediction phase, you probably should use a 15-2 GOP if the source is PAL and autoGOP is selected in DVD-RB. In NTSC, 12-2 is probably the most accurate choice.

3) In the actual redistribution phase, you should use the GOP settings from DVD-RB like before, now it looks like 12-2 is used there too.

[robot1]

Hi robot1,

here are some small comments regarding using HC:

1) When doing bitrate redistribution and you choose to calculate the optimal quantizer to use, the "ignore filters" option is not considered in the prediction phase. (this probably applies to all encoders)

2) In the forementioned prediction phase, you probably should use a 15-2 GOP if the source is PAL and autoGOP is selected in DVD-RB. In NTSC, 12-2 is probably the most accurate choice.

3) In the actual redistribution phase, you should use the GOP settings from DVD-RB like before, now it looks like 12-2 is used there too.
These adjustments will be in next version.

[robot1]

Hi,
Nice work robot1. I didn't want to read through all 16 pages of this thread, but I read in the beginning that the first beta was not supporting HC. Is it usable with HC now? Regards, TomBk
RB-Opt works with HC, but some advanced options are not available for this encoder.

[tom942]

This question goes to Boulder or anyone that can help me.

I was reading in the help of Ammon82's AutoQ that 12 was better because it is related to the framerate,and also I've seen that when HC does CQ One pass, it selects 12-2, so why is better for 15 gop than 12?. Could you tell me where can I find info related to this?.

And why is better 10 bits of DC precission than 8 or 9?. I've done several test with SP and HC, and I've seen the image improves with 10,but, why?.

Sorry for the off-topic, if so, I'll move it to other place in the forum.

Greetings.

[Boulder]

I think you should post your question as a new thread in the MPEG2 encoding forum as it's a general one and doesn't deal directly with RB-Opt.

In general, a longer GOP compresses better because there are fewer I-frames. Then again, a long GOP may affect quality because there are more frames that are "constructed" using other frames as a reference. See http://en.wikipedia.org/wiki/Video_compression_picture_types for detailed info.

I very rarely use 12-frame GOPs, only when having encoder saturation. I use autoGOP with a maximum of 15 frames 99% of the time.

I'll leave the DC precision part for someone else to answer.

[tom942]

With affect quality, you mean a bit worse?.

What do you mean with encoder saturation?.

I move it to the other forum. BTW, thank you for the answer :).

[kumi]

@Boulder:

I read somewhere that pulldowned sources need special care when choosing GOP. Can you tell me how to determine when a 12-frame GOP is _necessary_?

[~bT~]

^ this thread may answer your questions: http://forum.doom9.org/showthread.php?t=124824

[kumi]

Thank you for that link. But I'm still not sure how to tell when the output of DVD Rebuilder is going to use rff flags. Where do I look?

[jdobbs]

If the source is 23.976. DVD-RB will reimplement the same TFF/RFF sequences as the original.

[tom942]

@robot1

Could you add a log with the old and new bitrate distribution in a similar way that DVD-RB does to compare the final results?

:thanks:

[robot1]

Here is:
RB-Opt v. 0.30 (http://www.savefile.com/files/814252)

Changelog:
Redistribution can now involve multiple VOBIDs (useful for episodic discs)
Support for HC Lumgain and Autogop parameters, through settings in RBOpt.ini
In redisitribution process, if checked "disable all filters", filters are ignored also in the Q search phase
Changed the final log in the redisitribution, to compare original and redistributed values
Improved Q finding precision for HC encoder

As always, feedbacks are welcome.

[~bT~]

^ Much appreciated update. :thanks:

[tom942]

:thanks: for the update robot 1 :)

[kumi]

Thanks a lot for version 0.30, robot1 :)

I have a few questions about bitrate redistribution, my apologies for using a list format:

1/ Does HC_LUMGAIN > 0 play along nicely with RBOpt's bitrate redistribution?

2/ Will bitrate redistribution work with ProCoder projects? I know I've read somewhere that OPV mode in ProCoder is broken... but can't the redistribution be done with HC or CCE?

3/ When using filters that affect Q (sharpening, denoising etc.) is it advisable to use "disable all filters"?

4/ Sharc mentioned on page 30 of this thread that "a small sample size of 0.5% to 1% is sufficient", but the RBOpt default value is set to 20%. Is it safe to use a sample size of 1% here?

[Sharc]

Let me comment on 4/:

There are 2 different %-age settings:
a) One relates to the redistribution of the segments
b) One relates to the estimation of Q

For a) I normally select 25% because this is in relation to the number of frames of the individual segments.

For b) I normally select 0.5% to 1% because this is in relation to the number of frames of the entire movie (or all linked VOB-IDs, respectively).

Generally speaking, I select the percentages for each case such as to grab a sufficient number of frames. I consider about 500 ... 1000 frames sufficient. Therefore the 25% for a) and the 1% for b).

[robot1]

1/ Does HC_LUMGAIN > 0 play along nicely with RBOpt's bitrate redistribution?

I haven't tested it much, and I'm not sure if this setting is important in OPV encoding or only in VRB encoding. Anyway, I'd set LUMGAIN at the same value used in DVD-RB.


2/ Will bitrate redistribution work with ProCoder projects? I know I've read somewhere that OPV mode in ProCoder is broken... but can't the redistribution be done with HC or CCE?

Redistribution works with EclPRO, only if you are using ProCoder 2.
Anyway, I'd use always Q=1, and the results are a bit different from the ones you get with other encoders. Need more (visual) tests for a better answer.


3/ When using filters that affect Q (sharpening, denoising etc.) is it advisable to use "disable all filters"?
There are tests in another thread. If I remember well, the results are similiar with filters enabled or disabled. If time is not an issue, leave all filters enabled.


4/ Sharc mentioned on page 30 of this thread that "a small sample size of 0.5% to 1% is sufficient", but the RBOpt default value is set to 20%. Is it safe to use a sample size of 1% here?
See the previous post by Sharc. I would not go under 10% for redistribution.

[kumi]

Thanks, Sharc & robot1.

I haven't tested it much, and I'm not sure if this setting is importantHave you tested, then, with CCE's AQM? This and LUMGAIN both operate in a similar fashion if I'm not mistaken, so if you have experience with AQM+redistribution it's probably valid to extrapolate to LUMGAIN+redistribution.


Redistribution works with EclPRO, only if you are using ProCoder 2. Anyway, I'd use always Q=1I see, so I should use a Q factor of 1, and disable "Calculate optimal Q"? I'd be happy to do some ProCoder 2 testing, if I can determine the right way to go about it.

[Boulder]

If I remember correctly, CCE's adaptive quant matrices feature is not applied when you do an OPV encode. I personally wouldn't use LUMGAIN in the redistribution at all unless a 100% sample size is used in the redistribution phase. Otherwise it'll add an uncertainty factor in the process - we are doing a constant quant encode in which the matrix has a key role what comes to final filesize and thus the final bitrate distribution among the segments.

ProCoder's problem is that the Q scale is very bad, even at the maximum quality, you often undersize. That's why you should use Q=1 and not predict it (prediction is mostly a complete waste of time in ProCoder).

[kumi]

Thanks for the clarification Boulder.

I've been trying to test the redistribute function, but I am running into a problem with RBOpt. It freezes after encoding the penultimate segment, with RBOpt.exe pegged at 100% CPU usage.

For reference, I am using RBOpt 0.30, DVD-RB 1.26 Pro and HC 0.21. I use Windows XP SP1 with an AMD Sempron 2600+ and 512MB RAM, with absolutely the bare minimum of services and running programs.

I open the Redistribute tab, and use these settings:
Two VobIDs selected on the left: VTS 1 - Vob-ID 1 and VTS 1 - Vob-ID 2
Sample size: 20%
Q Factor: 20
Threads: 1
Launch Encoder Minimized: yes
Calculate Optimal Q: no
Ignore all filters: no

I've also tried with Calculate Q on, Ignore all filters on, and encoder default matrix set in DVDRB. It's always the same story: RBOpt finishes encoding the next to last segment, and then the "Bitrate Redistribution" windows becomes "Not Responding" and freezes with 100% CPU. The last lines in the log read:
=== Completed encoding VTS 1 VobID 2 segment 11
Size of the segment: 38442 KB
Segment bitrate: 4952

It never starts the final VTS 1 VobID 2 segment 12. What could be the problem?

[Boulder]

Have you tried with minimized encoder window unchecked?

By the way, I'm not even sure if LUMGAIN is considered when you do a constant quant encode..I've never checked the matrices of a constant quant encode with DGIndex.

[robot1]

It never starts the final VTS 1 VobID 2 segment 12. What could be the problem?
I will check.
Meanwhile, could you test with RB-Opt 0.29 and with 0.30 selecting one VobID?
Thank you.

[kumi]

OK, in RBOpt 0.29, the redistribution completes successfully.

I ran RBOpt 0.30 twice (both times with "launch encoder minimized" unchecked):

Running it on only Vob-ID 1: Success
Running it on only Vob-ID 2: Freezes after penultimate segment completes.

So it appears the problem is related to the last segment of VTS 1 - Vob-ID 2 (a small cell with only 49 frames), and only in RBOpt version 0.30.

Here's my REBUILDER.INF:
http://pastebin.ca/574797

And my REBUILDER.ECL:
http://pastebin.ca/574799

[robot1]

OK, in RBOpt 0.29, the redistribution completes successfully.

I ran RBOpt 0.30 twice (both times with "launch encoder minimized" unchecked):

Running it on only Vob-ID 1: Success
Running it on only Vob-ID 2: Freezes after penultimate segment completes.

So it appears the problem is related to the last segment of VTS 1 - Vob-ID 2 (a small cell with only 49 frames), and only in RBOpt version 0.30.

Thank you for your tests.
I've PM'ed you a test version - hope to have solved the bug.

[kumi]

robot1: *ding* You've got mail

On an unrelated and somewhat unimportant note, is it possible for RBOpt to consume less RAM on startup? It eats up ~240MB of my 512MB system total, which is quite a burden when it spawns HC (which eats up another ~200MB).

EDIT: Nevermind, memory usage is fine at ~15MB, I was looking at the wrong column.

[robot1]

Solved the bug reported by Kumi
RB-Opt v. 0.31 beta (http://www.savefile.com/files/822335)

Added through RBOpt.ini support in redistribution for:
HC_Profile (0 fast - 1 normal - 2 best) -default best
QuEnc_Qual (0 normal - 1 high) - default high
QuEnc_Trellis (0 off - 1 on) - default off

[tom942]

@robot1

I don't know if it's a bug, but when HC starts the Q value prediction it sets DC precision to 12 :eek:. Later, when it starts to encode it sets it to 11 (the max value in HC, I suppose).

Is it possible that RB-OPT takes the value that is set in DVD-RB or set it through RBOPT.ini?

:thanks:

[kumi]

I'm seeing the same behaviour: both the Q prediction HC .ini files and the bitrate prediction item0.ini files both have:

*DC_PREC 12

But the HC GUI shows "dc prec 11". My DVDRB DC Prec is set to "Auto".

[kumi]

I ran a redistribution on a disc with 10 short films (1 per VTS, 1 per segment) and noticed segment 2's new bitrate is quite a bit higher than the original DVD9:

http://img261.imageshack.us/img261/3746/imagebl5.png



I'm not sure what to make of this. Common sense tells me it's more desirable to subtract bits from the source, rather than add bits ;)

[robot1]

I'm seeing the same behaviour: both the Q prediction HC .ini files and the bitrate prediction item0.ini files both have:

*DC_PREC 12

But the HC GUI shows "dc prec 11". My DVDRB DC Prec is set to "Auto".
Could you send me rebuilder.inf and rebuilder.ecl?
Thank you.

[robot1]

I'm not sure what to make of this. Common sense tells me it's more desirable to subtract bits from the source, rather than add bits ;)
http://forum.doom9.org/showthread.php?p=1014831#post1014831

The distribution graph is interesting, but we need visual test to check if redistribution gives a better visual result than a standard vbr encoding.

[kumi]

Could you send me rebuilder.inf and rebuilder.ecl?Sure thing. FYI: when I encode this project from DVD-RB as VBR, there is no *DC_PREC directive in the intermediate HC.INI files created, and the HC GUI reports "dc prec 9" for all of the segments.

REBUILDER.ECL
http://pastebin.ca/579264

RFBUILDER.INF
http://pastebin.ca/579270



we need visual test to check if redistribution gives a better visual result than a standard vbr encoding.I will run some comparisons and report my findings. Is the max_reduction variable in rbopt.ini responsible for limiting bitrates to a percentage of the original?

EDIT: Nope, I guess it isn't. Also, I just noticed that DVD-RB won't accept +100% compression levels on any segments, and seems to set any that have "overshoot" to 100% compression when you start an ENCODE phase. But the saved bits aren't redistributed back to the other segments, so I think this is a problem (and might cause undersizing?)

[robot1]

Download here:
RB-Opt v. 0.32 beta (http://www.savefile.com/files/826263)

Fixed the bug reported by Tom942 and Kumi: in some circustancies, the DC Precision for HC was wrong.
Added in RBOpt.ini support for HC_AutoDC (0 Disabled - 1 Enabled)

[robot1]

I will run some comparisons and report my findings. Is the max_reduction variable in rbopt.ini responsible for limiting bitrates to a percentage of the original?

EDIT: Nope, I guess it isn't. Also, I just noticed that DVD-RB won't accept +100% compression levels on any segments, and seems to set any that have "overshoot" to 100% compression when you start an ENCODE phase. But the saved bits aren't redistributed back to the other segments, so I think this is a problem (and might cause undersizing?)
You have to change also a setting in the Rebuilder.ini
Anyway, as you stated above,
Common sense tells me it's more desirable to subtract bits from the source, rather than add bits
I suggest you to leave
max_reduction=100
in RB-Opt.ini, so you don't have problems, and will get the right size because RB-Opt redistribuite the saved bits.
I tell you more: if I get a 100% reduction, I'd tweak the cell, lowering its bitrate, to give more room to other cells. Else, you can set the cell at "no compression" in DVD-RB

[Sharc]

EDIT: ...... But the saved bits aren't redistributed back to the other segments, so I think this is a problem (and might cause undersizing?)
I think this is on jdobbs' agenda:
http://forum.doom9.org/showthread.php?p=1014800#post1014800

[Sharc]

.....I tell you more: if I get a 100% reduction, I'd tweak the cell, lowering its bitrate, to give more room to other cells.
Or set max_reduction=90, for example, to have it done automatically?

[robot1]

Or set max_reduction=90, for example, to have it done automatically?
Probably it should work, but I haven't tried.
max_reduction is a very beta setting, and I haven't played much with it.

You have to check the exact reduction (and bitrate) in the tweak cell dialog, because the log in the redistribution reports the calculated bitrate. The check against max_reduction is performed later, when you press the OK button.

[Sharc]

I see, thanks. I will try.

[kumi]

robot1, thanks a lot for version 0.32 :cool:

I finished a visual comparison of a CBR-ish DVD, pitting HC VBR versus RBOpt redistributed (the graph I posted above). The source is Korean Academy of Film Arts - My Beautiful Short Stories Vol. II, 'Naui Areumdaun Danpyeon Vol.II' (2007) R0:

As opposed to other 8 segments, segments 1 and 2 are shot on old handhelds (8mm, perhaps) with tons of noise, grain, and film speckles/dust. The VBR versions are positively swimming in blocks, compared to the redistributed versions.

Looking at segment 8, where VBR bitrate minus redistributed bitrate is greatest, the VBR version of segment 8 is a bit better than the redistributed version. A little bit less mosquito noise and macroblocking. The other seven segments I consider pretty much a tie.

So huge thumbs up for redistribution on this particular disc, one with a high variance in original video quality from segment to segment. I look forward to testing now on more common VBR-encoded one-movie type discs.



I suggest you to leave max_reduction=100 in RB-Opt.ini, so you don't have problems, and will get the right size because RB-Opt redistribuite the saved bits.OK, I understand now. Redistribution writes to the Reduction= and Video_Sectors= in REBUILDER.INF. If a segment overshoots the original bitrate, RBOpt redistributes the saved bits exactly like you said. The sum of Video_Sectors remains about the same before and after redistribution, which was my clue it's saving bits correctly.

It's confusing, because the values reported in the Bitrate redistribution log do not account for the Reduction= safety mechanism. Could you add some extra info in the log to segments that get 'Reduced'?

More importantly, why doesn't RBOpt write the correct vbr_brate_avg values to REBUILDER.ECL? In cases of overshot bitrate, the values before reduction are written, instead of the actual, compensated bitrates:

Actual rebuilder.ini Percent
Segment Bitrate vbr_brate_avg Deviation
------------------------------------------
01 5251 5251 0%
02 5724 6495 +13%
03 3069 3069 0%
04 2880 2880 0%
05 2972 2972 0%
06 3688 3688 0%
07 3023 3023 0%
08 2360 2360 0%
09 3749 3749 0%
10 2503 2503 0%

Can this be done automatically by RBOpt?


- - -
P.S.: I noticed RBOpt adds lines containing "no_move=0" to REBUILDER.ECL. Just curious, what does that do?

[Sharc]

@kumi
Just for my understanding: Is "Actual bitrate" in your table the bitrate of the final ecnode? Means for segment 2 the encoding was done correctly at the reduced (original, 100%) bitrate, and the +13% overshoot is only a matter of the rebuilder.ecl?

[kumi]

Yes, exactly.

[tom942]

Thanks robot1. I'm going to try it.

[robot1]

OK, I understand now. Redistribution writes to the Reduction= and Video_Sectors= in REBUILDER.INF. If a segment overshoots the original bitrate, RBOpt redistributes the saved bits exactly like you said. The sum of Video_Sectors remains about the same before and after redistribution, which was my clue it's saving bits correctly.

It's confusing, because the values reported in the Bitrate redistribution log do not account for the Reduction= safety mechanism. Could you add some extra info in the log to segments that get 'Reduced'?
Yes, you are right. I haven't changed the log because I want to show what would be the ideal bitrate for a given Q for that cell.

More importantly, why doesn't RBOpt write the correct vbr_brate_avg values to REBUILDER.ECL? In cases of overshot bitrate, the values before reduction are written, instead of the actual, compensated bitrates:

Actual rebuilder.ini Percent
Segment Bitrate vbr_brate_avg Deviation
------------------------------------------
01 5251 5251 0%
02 5724 6495 +13%
03 3069 3069 0%
04 2880 2880 0%
05 2972 2972 0%
06 3688 3688 0%
07 3023 3023 0%
08 2360 2360 0%
09 3749 3749 0%
10 2503 2503 0%

Can this be done automatically by RBOpt?

RB-Opt should write the same bitrate in Rebuilder.ecl and Rebuilder.inf. Do you find different avg_bitrates? Can you post Rebuilder.inf/ecl and the .original ones?


- - -
P.S.: I noticed RBOpt adds lines containing "no_move=0" to REBUILDER.ECL. Just curious, what does that do?
It's a swicth for CCE SP 2.70.

[kumi]

Here you go, .ECL/.INF before and after redistribution:

http://www.savefile.com/files/828723

[tom942]

I think I found a little bug.

I've been testing CCE SP OPV and when you set sample size to 3% and try for instance with HVS-Better o Jawor's 2CD matrices, CCE fails and reports a Q=1. Meanwhile if you set it to 2% or 4%, the prediction works fine.

[Sharc]

It seems to me as if the reduction to the original bitrate (100%) does not work as it should when the redistributed bitrate exceeds the original.
For example, I got the following values (max_reduction=100) for cell 5:

Original: 5668 (measured with DGIndex)
Redistributed: 6368 (from log and rebuilder.ecl)
Actual encoded: 6161 (measured with DGIndex)

There seems to have been some reduction from 6368 to 6161, but not to 5668 (100%) as I would have expected.

I did a new redistribution pass with max_reduction=90. After pressing OK at the end of the redistribution pass the rebuilder.ecl still indicated vbr_brate_avg=6368. I did not do the encode, though.

[kumi]

I'm not seeing a discrepancy when I measure bitrates with Elecard StreamEye or when I simply look at .M2V file sizes:

vbr_brate_avg Original Original Encoded
deviation DVD9 .m2v DVD9 .m2v .m2v Original Re-encoded
from 100% Bitrate Bitrate Bitrate DVD9 .m2v .m2v
Segment Reduction (Elecard) (DVD-RB) (Elecard) Filesize Filesize
-------------------------------------------------------------------------------
02 +13% 5732 5724 5719 382MB 387MB

I think DGIndex uses a different method of bitrate estimation than DVD-Rebuilder. Have you compared the original DVD9 .M2V filesize to the re-encoded one? In my case they're very similar, and so are the bitrates as reported by Elecard.

EDIT: Hmm, in my case DGIndex 1.4.9 reports 100% bitrate (5723), not 113% bitrate (6111).

[Sharc]

Thanks for the hint. May be it's related to the method of bitrate measurement. I will check again with other methods.
Still, what makes me wonder a little is that I measured the original disk and the final RB-encode using the same method (DGIndex) and got different results.

[kumi]

I just edited my post with my DGIndex results. Maybe your bitrate discrepancy is caused by the way DVD-RB uses a common framerate to ensure hybrid discs come out OK.

Edit: also, you might want to check if DGIndex is misreporting with a normal, less-than-100%-Reduction segment. Just encode it straight from DVD-RB and check the reported bitrate against the vbr_brate_avg value.

Edit 2:Testing the .M2V created from an ENCODE phase might not be enough: you might have to complete REBUILD phase and then demux the .M2V. Then compare it against the original .M2V (demuxed from the source disc.)

[Sharc]

I just did your "Edit1" and found no discrepancy ....

I also made a comparison between the *.VOBs of the original and the REBUILD (assuming that DGIndex reports the video bitrate and not the muxed bitrate).

Edit: Mmmm..., I was probably using version RB-Opt v0.30 or 0.31 in this case. Could be that the reduction has not yet been implemented in the earlier versions..... Sorry for the confusion.

[robot1]

Thank you for your tests.
I've found the bug: there is a line of code in which i set the bitrate without checking for the max. I'm testing right now, and will post a new version tomorrow.

[Sharc]

Thanks robot1. No hurry. Time to go to bed now .....

[Sharc]

RB-Opt v0.32b:
The max_reduction is reset to 100 each time I restart RB-Opt, means the setting in the RBOpt.ini is not permanent. Is this so by intention?

The DVD Estimated Size under Global Options seems to be wrong (too low).

[robot1]

RB-Opt v0.32b:
The max_reduction is reset to 100 each time I restart RB-Opt, means the setting in the RBOpt.ini is not permanent. Is this so by intention?

No, it should be saved, and RB-Opt doesn't modify it in my tests.
Probably it's a dumb question, but have you edited the .ini before running RB-Opt?


The DVD Estimated Size under Global Options seems to be wrong (too low).
The DVD Estimated size in Global options is the same reported in the main window. It's an estimate, so it can't be exact, but I'd like to receive feedbacks on the final size of the encoded project.

[Sharc]

Probably it's a dumb question, but have you edited the .ini before running RB-Opt?
At least I thought so. I will doublecheck next time.....


The DVD Estimated size in Global options is the same reported in the main window.
Hmm... I don't get any size info in the main widow since v0.30 or so (?)
In the Global options I get 1609769 sectors. I noticed this "undersize" before, but the final size came out correctly(about 2245000).
Anyway, I will wait for the current encode to finalize.

[kumi]

I've noticed this discrepancy also. Three examples (these are values reported by both programs):

Encode DVDRB DVDRB RBOpt RBOpt
Type Size Compression% Est. Size Compression%
-----------------------------------------------------
VBR 4.32GB 67.9% 4.30GB 100%
RBOpt 4.18GB 65.5% 4.16GB 96.46%

VBR 4.32GB 67.9% 4.30GB 100%
RBOpt 4.26GB 66.9% 4.24GB 98.51%

VBR 4.32GB 52.7% 3.56GB 100%
RBOpt 4.32GB 52.7% 3.56GB 100%


I'm still waiting for my encodes to finish so I can say whether the size is actually misreported or not.

[Sharc]

Here my final results:
DVD-RB in Editor Window: 4.34 GB (= 4444 MB)
RB-Opt in Global Options: 3184 MB, 1609769 target sectors
NERO burning: 4448 MB

So the final size of the encode was perfect.
The error seems to be in the RB-Opt reporting.

[Sharc]

@robot1:
Suggestion: The "min_redist_frames=" parameter (or a similar one) should perhaps also be applied to the Q estimation. Otherwise very few frames may be grabbed from small VOB-IDs for the Q estimate.

[robot1]

@robot1:
Suggestion: The "min_redist_frames=" parameter (or a similar one) should perhaps also be applied to the Q estimation. Otherwise very few frames may be grabbed from small VOB-IDs for the Q estimate.
It's a good suggestion. I will correct this.

RB-Opt in Global Options: 3184 MB, 1609769 target sectors
NERO burning: 4448 MB


Could you send me the rebuilder.inf and rebuilder.ecl (and, if changed, also the .original) to my email? The email is in the readme file.


I've noticed this discrepancy also. Three examples (these are values reported by both programs):


Encode DVDRB DVDRB RBOpt RBOpt
Type Size Compression% Est. Size Compression%
-----------------------------------------------------
VBR 4.32GB 67.9% 4.30GB 100%
RBOpt 4.18GB 65.5% 4.16GB 96.46%


I'm not sure about the second row. In the first one you report the size estimated by DVD-RB and RBOpt. What is in the second one?

[kumi]

Sorry, that chart wasn't very clear. The first row are the reported sizes of a D2VAVS created straight from DVD-Rebuilder in VBR mode. The second row are the reported sizes of the same D2VAVS after redistributing bitrates in RBOpt.

I finally finished three test projects. I used a PREPARE phase in DVD-RB, then RBOpt to redistribute bitrates. Then I recorded the estimated sizes in DVD-RB and RBOpt.
Estimated Estimated Actual
Size in Size in Size of
DVD-RB RBOpt Output
-------------------------------
4.18GB 4.16GB 4.18GB
4.26GB 4.24GB 4.26GB
4.32GB 3.56GB 4.32GB

It seems that DVD-RB reports final sizes more accurately than RBOpt, in line with what Sharc was experiencing.





Something I'm regularly encountering with redistribution, in ProCoder and HC projects, is a chronic undersizing of the output. In the above table, you can the size of the first project was 4.18GB. I've even seen one ProCoder project come out to 4.07GB.

In none of these cases was the encoder saturated, so I guess the reason is the lack of granularity of the Q scale? ProCoder CQ seems to be especially flaky in this regard.

Since you're on a roll, robot1, I would like to request a fix for the undersizing issue ;) Maybe RBOpt could do something like this:

1/ Before redistribution, RBOpt estimates size. For example: 4.32GB.
2/ User initiates redistribution on some segments.
3/ RBOpt calculates the final output size is now less than 4.32GB.
4/ RBOpt increases the redistributed segments' bitrates by a certain percentage, to bring the estimated size back to 4.32GB.

[Sharc]

@kumi:
The reason for my "undersizing" could be traced to my preprocessing: Removing of Extras, and 25% reduction on the remaining Extras which RB-Opt didn't account for correctly.
A cosmetic reporting problem only. as it did not affect the final size of the encode. Robot1 is going to fix it.

[kumi]

Yes I understand. For me, RBOpt reports too-low "Estimated Size" values with 00% Steal Space settings, and no preprocessing. But yeah, you're right: it doesn't affect actual output size.

But apart from that cosmetic problem, there is the other undersizing issue in my last post, that does result in actual undersized output. Have you ever seen one of your redistributed projects come out undersized?

[robot1]

The size estimation routine in RB-Opt was written many versions ago, and it should work well with the free version of DVD-RB.
Nowdays, with DVd-RB Pro, it's clear that the size estimation is worse than the one in DVD-RB (I'm working to fix it), but, as mentioned by Shark, it's an'estetical problem.
The internal routines don't take that size in account, but the Total Video Size %, which should always be 100 and is related to the DVD-RB calculated output.

The undersizing problem could be caused by the reduction going over 100% in redistribution.
Could you check in Rebuilder.inf if there are segments with Src_Video_Sectors lower than Video_Sectors?
If this case applies, the new version should take care of that problem.

[Boulder]

Would it be possible to have the CQ_BFACTOR and CQ_PFACTOR options in the redistribution phase? It would be useful IMHO, since the normal 2-pass encode usually shows that I- and P-frame quantization is nearly the same while the B-frames have a somewhat higher quantizer, the multiplier being usually 1.5-2.0.

[robot1]

Would it be possible to have the CQ_BFACTOR and CQ_PFACTOR options in the redistribution phase? It would be useful IMHO, since the normal 2-pass encode usually shows that I- and P-frame quantization is nearly the same while the B-frames have a somewhat higher quantizer, the multiplier being usually 1.5-2.0.No problem to add those parameters.
What should be the default values, according to your experience?

[Boulder]

I would probably use 1.05 for PFACTOR and 1.6 for BFACTOR, they are close to what I've seen lately. The actual ratio depends a lot on the material but I'd say these ones are from an average encode.

[kumi]

I have 2 requests for future RBOpt versions, I hope you can consider them:


First:
Add a no_reencode_threshold directive to rbopt.ini. So, for example, if rbopt.ini contains no_reencode_threshold=95, any segment with a calculated redistributed bitrate of 95% or more would have Action=3 set in REBUILDER.INF. no_reencode_threshold=0 would disable this feature.


Second:
Provide a way to export (and import) a project's segment bitrates. I ask for this because calculating redistribution with ProCoder 2 is a dicey affair. Sometimes the redistributed bitrate values are very different to those calculated with HC or CCE (or QuEnc, apparently (http://forum.doom9.org/showthread.php?p=1018585#post1018585)). It would be helpful if we could redistribute bitrates with HC/CCE/QuEnc, change the DVD-Rebuilder project type to ProCoder, and then apply the previously calculated values with RBOpt. A possible workflow would be:

1/ Run a PREPARE phase (VBR) in HC Mode.
2/ Redistribute bitrates in RBOpt.
3/ Use the new "Export bitrates" RBOpt function.
4/ Switch the DVDRB Mode to ProCoder, and re-run PREPARE phase.
5/ Use the new "Import bitrates" RBOpt function with the file created from step 3/.

AFAIK, you could probably pull this off by recording just four variables from the .ECL/.INF files:

vbr_brate_avg
Action
Reduction
Video_Sectors

[Fishman0919]

I have 2 requests for future RBOpt versions, I hope you can consider them:


First:
Add a no_reencode_threshold directive to rbopt.ini. So, for example, if rbopt.ini contains no_reencode_threshold=95, any segment with a calculated redistributed bitrate of 95% or more would have Action=3 set in REBUILDER.INF. no_reencode_threshold=0 would disable this feature.


Second:
Provide a way to export (and import) a project's segment bitrates. I ask for this because calculating redistribution with ProCoder 2 is a dicey affair. Sometimes the redistributed bitrate values are very different to those calculated with HC or CCE (or QuEnc, apparently (http://forum.doom9.org/showthread.php?p=1018585#post1018585)). It would be helpful if we could redistribute bitrates with HC/CCE/QuEnc, change the DVD-Rebuilder project type to ProCoder, and then apply the previously calculated values with RBOpt. A possible workflow would be:

1/ Run a PREPARE phase (VBR) in HC Mode.
2/ Redistribute bitrates in RBOpt.
3/ Use the new "Export bitrates" RBOpt function.
4/ Switch the DVDRB Mode to ProCoder, and re-run PREPARE phase.
5/ Use the new "Import bitrates" RBOpt function with the file created from step 3/.

AFAIK, you could probably pull this off by recording just four variables from the .ECL/.INF files:

vbr_brate_avg
Action
Reduction
Video_Sectors

Correct me if I'm wrong... but one of big benefits to redistribution is using the info provided by the encoder for that movie... see how that encoder deal with the video... if you are using HC,QuEnc or CCE to get the info. Who's to say that would be how Procoder would deal with it. Would it real be any benefit?

Just my 2 cents

[kumi]

I'm asking for the second feature because I get wierd filesizes sometimes in ProCoder CQ mode. My comparisons with HC and CCE on a few redistributions have shown ProCoder (@ Q=1) always results in wilder bitrate swings. I can live with that, and perhaps that's just the optimal configuration for ProCoder. But in one my projects, a segment resulted in an extremely low bitrate; completely different from HC and CCE. And sure enough, it looked like crap. I'll make sure and post an example next time I encounter this.

I just don't trust CQ mode. I would rather live with marginally suboptimal bitrate distributions, that occasionally encounter a segment with extremely high or low bitrates.

[Boulder]

It shouldn't matter whether you use CCE, HC or QuEnc to do the redistribution as Sharc had noticed in his tests. In fact, when I do the redistribution manually (when dealing with my DVB captures), I use CCE for doing the redistribution pass and then HC for the final encode. The reason why I do this is that CCE is somewhat faster which will save me some time.

[robot1]

RB-Opt v. 0.33 beta (http://www.savefile.com/files/843117)

Changelog:
Better Size estimation with DVD-RB Pro
Fixed the max_reduction setting in RBOpt.ini
Added HC_PFACTOR (default 1.00 - suggested 1.05) and HC_BFACTOR (default 1.00 - suggested 1.6) options for HC through RBOpt.ini
Used the min_redist_sample value also in Q search phase (to avoid bad predictions on very small VobID)

[robot1]

I have 2 requests for future RBOpt versions, I hope you can consider them:

First:
Add a no_reencode_threshold directive to rbopt.ini. So, for example, if rbopt.ini contains no_reencode_threshold=95, any segment with a calculated redistributed bitrate of 95% or more would have Action=3 set in REBUILDER.INF. no_reencode_threshold=0 would disable this feature.

I could add a no_reencode_threshold, acting in this way:
if the segment reduction is over the threshold, and there are no filters (the .avs is standard), I could set it as No reencode in the rebuilder.inf


Second:
Provide a way to export (and import) a project's segment bitrates. I ask for this because calculating redistribution with ProCoder 2 is a dicey affair. Sometimes the redistributed bitrate values are very different to those calculated with HC or CCE (or QuEnc, apparently (http://forum.doom9.org/showthread.php?p=1018585#post1018585)). It would be helpful if we could redistribute bitrates with HC/CCE/QuEnc, change the DVD-Rebuilder project type to ProCoder, and then apply the previously calculated values with RBOpt. A possible workflow would be:

1/ Run a PREPARE phase (VBR) in HC Mode.
2/ Redistribute bitrates in RBOpt.
3/ Use the new "Export bitrates" RBOpt function.
4/ Switch the DVDRB Mode to ProCoder, and re-run PREPARE phase.
5/ Use the new "Import bitrates" RBOpt function with the file created from step 3/.

AFAIK, you could probably pull this off by recording just four variables from the .ECL/.INF files:

vbr_brate_avg
Action
Reduction
Video_Sectors
It's a complex process. I'd use a
redistribuite_with_HC
(or redistribuite_with_QuEnc)
switch in RBOpt.ini
If the switch is on, and the encoder is CCE Basic or Procoder (and possibly QuEnc and AQE), it uses HC for redistribution.
I'd use HC because I think it's CQ mode is better than the QuEnc one.
Feedback welcome.

[kumi]

I could add a no_reencode_threshold, acting in this way:
if the segment reduction is over the threshold, and there are no filters (the .avs is standard), I could set it as No reencode in the rebuilder.inf

Hmm, my DVD-RB Filter Editor is always populated with #comments and P:, I:, E:, F: conditionals. Not all of the PREPARE phase .avs files would have filters applied, but they would still have extra lines added to them. If there's no work-around for that it's no big deal, I think what you suggested would be fail-safe.



I'd use a redistribute_with_HC (or redistribute_with_QuEnc) switch in RBOpt.ini

I hesitated to ask for something like that, since I thought it would cause you too much work to switch all the different parameters in the .ECL/.INF files.

I also thought of asking for RBOpt to automatically "remember" the last set of bitrates after clicking "Save Settings". And then having an additional function to "Restore Last Bitrates". IMHO that might be more flexible than an rbopt.ini setting.

[kumi]

A silly question: in the OPV Prediction window, what is the purpose of the "Check Quality" and "Save" buttons? They always seem to be grayed out and inactive.

Oh, and what is the "Safety Margin" for? :stupid:

[Sharc]

Check Quality:
You can watch the encoded sample and then decide to go ahead - or not - with the OPV encode.

edit: ... and did you enter the path for the Media Player in the Setup?

Safety Margin:
You can set it to 1% or so if you are afraid of possible OPV oversizing :devil:

[Sharc]

.... Add a no_reencode_threshold directive to rbopt.ini.....
Just for my understanding: Is there another reason for this apart from saving time?

[kumi]

Ahh... I forgot about the media player path setup. Thanks.


Is there another reason for this apart from saving time?

Well, that is my main concern. Especially if robot1 can code it in a manner that avoids the tedious process of adjusting a bunch of segment bitrates downwards to meet the TargetSectors value after nudging certain segments up to 100% (i.e. no re-encode.)

[robot1]

Hmm, my DVD-RB Filter Editor is always populated with #comments and P:, I:, E:, F: conditionals. Not all of the PREPARE phase .avs files would have filters applied, but they would still have extra lines added to them. If there's no work-around for that it's no big deal, I think what you suggested would be fail-safe.
It's easy to ignore comments.
A standard .avs should have only:
comments
loadplugins
mpeg2source
trim
converttoyuy2
AudioDub(BlankClip())
If there are other filters, than the clip has to be encoded.




I'd use a redistribute_with_HC (or redistribute_with_QuEnc) switch in RBOpt.ini

I hesitated to ask for something like that, since I thought it would cause you too much work to switch all the different parameters in the .ECL/.INF files.

I also thought of asking for RBOpt to automatically "remember" the last set of bitrates after clicking "Save Settings". And then having an additional function to "Restore Last Bitrates". IMHO that might be more flexible than an rbopt.ini setting.
It's much easier my solution... really simple to implement (and I think solves the problem with the encoders unable to perform a CQ encoding).


Well, that is my main concern. Especially if robot1 can code it in a manner that avoids the tedious process of adjusting a bunch of segment bitrates downwards to meet the TargetSectors value after nudging certain segments up to 100% (i.e. no re-encode.)
(When there are no bugs) the program always adapts the size of the other segments (set as "Autosize"), to meet the TargetSectors.

[kumi]

You're the boss :) Any way you choose to implement redistribute_with_whatever would be very much appreciated. Thanks for listening.

Oh, call me stupid... I just discovered last night what Autosize does. :p Duhhh...

I still think a no_reencode_threshold, and/or a "No Reencode" checkbox in the GUI would be useful.

[Sharc]

In he standard script the mpeg2source() is presently not editable in order to protect it from unintentional changes.
Could it be made editable (as an option), for example to allow insertion of the cpu=x parameter?

[robot1]

In he standard script the mpeg2source() is presently not editable in order to protect it from unintentional changes.
Could it be made editable (as an option), for example to allow insertion of the cpu=x parameter?
Yes, I had the same issue.
Will be in next version.

[Sharc]

Thanks, robot1.
It has really been your RB-Opt which has encouraged and enabled me to do all the tests about redistribution and eventually to prove to myself and demonstrate to others the benefit of Boulder's suggestion. :)
:thanks:

[dynamis]

silly question, but i gotta ask! does this mean that with Bitrate Redistribution i could do less vbr passes, say 2, instead of 3? :) my thinking is some of the calculations of how much bitrate to put where has been done already. or does Bitrate Allocation just determine how much to allow for a particular segment to keep video quality consistent across all segments?

also, since i never seem to know completely how OPV and multi-pass work, i will ask: does it matter that Bitrate Redistribution cannot be done with an OPV encode? i care more about quality than filesize, but if i can save some time..... should multi-pass with Bitrate Redistribution give me better results than OPV in most cases?

thanks robot1, Boulder, Sharc, and others for all your work to make my backups look better!

[Boulder]

If CCE's adaptive quant matrices feature is enabled, I would use 3 passes, otherwise two. The redistribution feature only redistributes the bits between the different segments, not inside them.

Doing an OPV encode is pretty much the same as doing the redistribution followed by a multipass VBR encode. The difference is that the resulting filesize is accurate with the redistribution, which is usually not the case in OPV encodes.

[stereo]

@Boulder

Do you mean that if CCEAQM=0, you would use the initial .vaf pass + 2 passes, meaning 3 passes altogether?

[Boulder]

If CCEAQM=0, I would do vaf+1 pass so the total is two passes. If CCEAQM=1, then vaf+2 passes=3 passes.

[stereo]

OK, thanks, Boulder.

I normally do 1+3 vbr passes (I almost never use CCEAQM=1), but last night I was playing around with RB-Opt 0.33 (just learning how to use the new features), and like dynamis I was wondering if my normal 1+3 passes hadn't become somewhat overkill.

[stereo]

Sorry, this is probably a stupid question:

After doing the initial linking of VobIDs in the main (first) window, the Q prediction (second window) and the redistribution passes (third window), I get the message "=== Done. Press OK to save the results. Warning: original bitrates will be overwritten". I then press OK, and the redistribution window closes, sending me back to the first RB-Opt window. My question is: Should I still press "Save settings" or just press "Exit" in this first window?

[Boulder]

You should save the settings.

[robot1]

... I get the message "=== Done. Press OK to save the results. Warning: original bitrates will be overwritten". I then press OK, and the redistribution window closes, sending me back to the first RB-Opt window. My question is: Should I still press "Save settings" or just press "Exit" in this first window?
I will change the text for next version.

[stereo]

OK, thanks both of you.

I figured, I should save, and thats what I did. I just wasn't sure.

So far, the new RB-Opt seems great, but I'll have to do some more testing / viewing to see if the encodes are improved.

[dynamis]

...The redistribution feature only redistributes the bits between the different segments, not inside them...

so if the total bitrate of VTS 2 (main feature) is 3900Kbps and VTS 2 (extras) is 2400, the total average of each will still be the same, 3900 and 2400? will bitrate go from one VTS to another? i've seen menus and extras come out with higher bitrates after redistribution and started to wonder where that extra bitrate was coming from because the total avg bitrates were now higher. is that normal? is that good? :P

also i was wondering why CCEAQM=1 would need the extra pass. i just read about CCEAQM in another thread. i've never used it before, but if i understand correctly, it can provide better video quality at the cost of compatibility with certain yard sale dvd players :P i'm thinking about using this together with Bitrate Distriburion, so i would like to know how the extra pass help things. thanks.

[Boulder]

so if the total bitrate of VTS 2 (main feature) is 3900Kbps and VTS 2 (extras) is 2400, the total average of each will still be the same, 3900 and 2400? will bitrate go from one VTS to another? i've seen menus and extras come out with higher bitrates after redistribution and started to wonder where that extra bitrate was coming from because the total avg bitrates were now higher. is that normal? is that good? :PIf both VTSs are included in the same redistribution pass, the average bitrates will change. If they are redistributed separately, the average bitrates will remain the same.
also i was wondering why CCEAQM=1 would need the extra pass. i just read about CCEAQM in another thread. i've never used it before, but if i understand correctly, it can provide better video quality at the cost of compatibility with certain yard sale dvd players :P i'm thinking about using this together with Bitrate Distriburion, so i would like to know how the extra pass help things. thanks.IMHO, the adaptive quant matrices feature needs the extra pass because the first actual pass after the vaf file creation will have a lot of changes in the matrices. I do not think that CCE can do an optimal distribution of matrices in the first pass and do an optimal allocation of bits at the same time. This is why I feel it should be given the second VBR pass - to do some fine adjustments. Also, in some cases when the compressibility of the video is very high, using only one VBR pass causes undersizing which is fixed by a second VBR pass.

[dynamis]

wow.. thanks Boulder! one last question, if i may, before i try some encodes. in your opinion, should menus or extras be redistributed? i'm thinking it depends... i've only tried calculations on a few movies, but so far i've kinda noticed that movies with lower Q factors seem to give bits to menus and extras and those with higher Q factors seem to take bits away. but then again... i rarely watch extras. i just throw them in if i have room and usually shrink them down with dvd shrink leaving the movie untouched. thank you.

[Boulder]

I usually uncheck Autosized for all menus and lower their avg bitrates and then do a redistribution pass with all menu-related items selected - or simply use MenuShrink on them.

Using extras in the same redistribution pass as the main movie really depends on your decision, if you rarely watch them, I don't think that it makes much sense to have the extras there. They usually need more bits than the main movie because they are interlaced.

[dynamis]

i will check out MenuShrink. thanks again, Boulder.

[Sharc]

IMHO, the adaptive quant matrices feature needs the extra pass because the first actual pass after the vaf file creation will have a lot of changes in the matrices......

I have seen frequent changes of the matrix in standard multipass VBR mode with CCEAQM=1. Did you or anyone experience frequent changes happening in redistribution mode as well? I wonder because the redistribution sets the segment bitrates according the the "Q-plus-matrix combo" and hence I wouldn't expect frequent changes happening during the encode afterwards.
I have so far not been using CCEAQM=1 in redustribution mode at all because I felt that changing the matrix dynamically would somehow conflict with the constant Q idea. So I doubt if CCEAQM=1 will have any benefit- but as I said I have not made any comparative tests.

[Boulder]

The adaptive quant matrices are not used in OPV mode, and this applies to HC's LUMGAIN option as well. However, I don't think it is a problem to use either option in the multipass encode, I've been using LUMGAIN 4 all the time.

The redistribution just makes the quality equal, the encoder can then decide what to do with the bits. For example, HC's LUMGAIN mode lowers the quant matrices coefficients in darker GOPs whereas CCE apparently makes its decisions based on the amount of motion (not sure though).

[Sharc]

I understood that CCE switches matrix to a higher bitrate matrix (1/2, 1/4) when the quantization gets very low and encoder runs into saturation. That's why I assumed that CCE would have no reason to switch the matrix after it has done the redistribution based on a fixed Q which would normally not let the quant drop to very low values. Anyway I might have to do some tests later.

[Boulder]

You may run into saturation even with redistribution. After all, if some segment is allocated less bits, some segment(s) must get those bits that are left over. If the average bitrate is high enough, there is a chance of saturation.

[stereo]

@Boulder (or robot1)

In your post #697 you write

If both VTSs are included in the same redistribution pass, the average bitrates will change. If they are redistributed separately, the average bitrates will remain the same.

Does this mean that it's possible to

1. adjust bitrates between movie and extras placed in let's say VTS_01 (4.500 Kbps. avg.) and VTS_02 (3.500 Kbps. avg.), just as one would normally do
2. complete a redistribution pass on VTS_01 (excluding VTS_02) (reaching the message "=== Done. Press OK to save the results. Warning: original bitrates will be overwritten")
3. Press OK, but without saving the settings in the main RB-Opt window
4. complete a new redistribution pass on VTS_02 (excluding VTS_01)
5. Press OK + Save settings + close RB-Opt

This method should ensure that

a. the initially adjusted average bitrates in VTS_01 and VTS_02 would be kept at 4.500 and 3.500 Kbps. respectively, while
b. the two separate redistribution passes would optimize the distribution within each VTS, without tampering with theses initially asigned bitrates (4.500 and 3.500 Kbps. respectively)

This would be just perfect. But am I correct in assuming that the above workflow would be possible (and constitute the correct method)?

Sorry for all these long questions...

[Boulder]

Yes, you are correct. The average bitrates of the two VTS's will remain at what you have set them to. It doesn't matter if you saved the settings between the two redistribution passes, I would save them in case something went wrong in the second redistribution pass (on VTS_02).

[stereo]

damn you're fast :D thanks a lot!

[EuropeanMan]

hi guys, my first time posting in this section...

i have been using DVD-RB for nearly 6 months now with CCE...nothing else (meaning, none of the other encoders)...and wish to continue doing so.

many of my movies in my collection are interlaced, TFF...these dVD9s are usually film2pal conversions. i live in the Usa...and these dvd9s are now ntscd..so basically i have interlacing...maybe i am not making any sence yet.

i'm wondering a few things...IF i use

AssumeTFF()
FieldDeinterlace()

will the results become deinterlaced, and what other settings of DVD-RB do i need to change to make sure my end-product is without all those interlaced lines...or is there something better to use filters-wise or settings...

2) on those interlaced films, is it recommended to use LSF for example ? will MT also work in the the aVS filter box...along with setmemorymax(1024)

3) i had used a script to take the frame rate back to 24.975 (no, not above 2 lines...i used leakkernelbob & repal)...but audio was off...is there any solution for this?

4) re: matrices...I'm still reading up on this...my question regarding this...is there a general place (ie: avisynth.org where u can get all the filters) where i can find other matrices that people have come up with?

5) I realise that OPV use comes with the assurity that one will not always atttain 4.35gb...but undersizing will occur when we have high compressibility...so i usually do 3 passes...with filters use for avs...am i correct in thinking OPV is NOT good for this?

thanks in advance for any help...

[jdobbs]

1. Are these commercial sources?

DVD-RB properly handles telecined sources and you don't have to do anything special. iVTC is something that is only required for "hard telecined" source -- which are very rare.

2. I would never recommend adding AssumeTFF() -- let DVD-RB reproduce it in the same format as the original. If you input from a BFF source and put that line in, your output will be hosed. FieldDeinterlace() should in most cases only be used if your primary playback device is going to be a PC.

3. ???

4. You'll find almost all of theim posted in this forum in one place or another. Rockas' RME includes a bunch, I think.

5. My recommendation is to use multiple passes in pretty much every circumstance.

[manono]

Hi-
i'm wondering a few things...IF i use

AssumeTFF()
FieldDeinterlace()

will the results become deinterlaced
Yes, and it's a very bad idea as you'll make the blending much worse.
2) When I unblend a bad PAL2NTSC conversion, I also sharpen it. And I use SetMTMode(2) with both the RePAL filter and with LSF.
3) If the audio became out of synch, it's not because of the RePAL filter, which gives you video after unblending exactly the same length as the source. Must be for some other reason, like maybe you encoded it incorrectly. You can't use RePAL within DVD-RB anyway, as the framerate changes.
4) They went matrix crazy in the XviD forum a few years back. I don't know why you'd be interested in amateurs' matrix creations, though, when there are so many available off retail DVDs, created by professionals. I know of no place with a collection of good MPEG-2 matrices. HCEnc comes with a big collection of both good and bad ones. And here's LiGH's collection:

http://www.ligh.de/software/qmatrix.zip

5) Perhaps someone else can answer that one.

Edit: jdobbs was faster on the trigger. :)

[jdobbs]

And I use SetMTMode(2) with both the RePAL filter...
Man, I must be getting out of touch now that I'm working this new (too busy) job. An entire discussion on multithreading support within AVISYNTH has been going on and I've remained clueless.

[EuropeanMan]

^ yes, i have bought many many indian films...cuz well i like them. so i do cces & hand them over to mom or her friends so they can watch...so yes, commercial sources.

thanks for the answers. i guess i'll leave fielddeinterlace alone... :(

one of these days i'm gonna figure out a way to CCE w/o DVD-RB...just waiting for someone who'll be patient enough to teach me.

tx guys for the answers...i'm sure i'll have more soon.

[stereo]

so i do cces & hand them over to mom or her friends so they can watch...so yes, commercial sources.

strictly speaking that doesn't belong in this forum

[dynamis]

maybe i missed it, but are there any issues when using Q=1 with Bitrate Redistribution?
i was calculating an anime disc w/ CCE SP 2.70, AVISYNTH 2.5.6.0 and rb-opt 0.33 beta:

- Reduction Level for DVD-5: 77.5%
- Overall Bitrate : 5,422/4,338Kbs
- Space for Video : 3,841,930KB
- HIGH/LOW/TYPICAL Bitrates: 8,616/400/4,338 Kbs

i had rb-opt determine the optimal Q factor and got a factor of 1:


Bitrate for VTS 4 VobID 1 segment 1: original 4406 - redist. 6129
Bitrate for VTS 4 VobID 1 segment 2: original 4457 - redist. 4596
Bitrate for VTS 4 VobID 1 segment 3: original 4541 - redist. 1582
Bitrate for VTS 4 VobID 1 segment 4: original 3908 - redist. 5121
Bitrate for VTS 4 VobID 1 segment 5: original 3685 - redist. 3244
Bitrate for VTS 4 VobID 1 segment 6: original 3558 - redist. 4708
Bitrate for VTS 4 VobID 1 segment 7: original 4760 - redist. 6462
Bitrate for VTS 4 VobID 1 segment 8: original 4467 - redist. 4787
Bitrate for VTS 4 VobID 1 segment 9: original 4387 - redist. 4630
Bitrate for VTS 4 VobID 1 segment 10: original 4448 - redist. 6240
Bitrate for VTS 4 VobID 1 segment 11: original 3642 - redist. 4202
Bitrate for VTS 4 VobID 1 segment 12: original 3549 - redist. 327
Bitrate for VTS 4 VobID 1 segment 13: original 4994 - redist. 6279
Bitrate for VTS 4 VobID 1 segment 14: original 4403 - redist. 4459
Bitrate for VTS 4 VobID 1 segment 15: original 4412 - redist. 4048
Bitrate for VTS 4 VobID 1 segment 16: original 4461 - redist. 5839
Bitrate for VTS 4 VobID 1 segment 17: original 3735 - redist. 3772
Bitrate for VTS 4 VobID 1 segment 18: original 3589 - redist. 4639
Bitrate for VTS 4 VobID 1 segment 19: original 4805 - redist. 6549
Bitrate for VTS 4 VobID 1 segment 20: original 4344 - redist. 4281
Bitrate for VTS 4 VobID 1 segment 21: original 4456 - redist. 5124
Bitrate for VTS 4 VobID 1 segment 22: original 4401 - redist. 6096
Bitrate for VTS 4 VobID 1 segment 23: original 3832 - redist. 5152
Bitrate for VTS 4 VobID 1 segment 24: original 3904 - redist. 4091
Bitrate for VTS 4 VobID 1 segment 25: original 400 - redist. 193

segment 12's bitrate seemed a bit odd so i tried Q=2:

Bitrate for VTS 4 VobID 1 segment 1: original 4406 - redist. 5804
Bitrate for VTS 4 VobID 1 segment 2: original 4457 - redist. 4237
Bitrate for VTS 4 VobID 1 segment 3: original 4541 - redist. 4699
Bitrate for VTS 4 VobID 1 segment 4: original 3908 - redist. 4785
Bitrate for VTS 4 VobID 1 segment 5: original 3685 - redist. 2809
Bitrate for VTS 4 VobID 1 segment 6: original 3558 - redist. 4348
Bitrate for VTS 4 VobID 1 segment 7: original 4760 - redist. 6126
Bitrate for VTS 4 VobID 1 segment 8: original 4467 - redist. 4418
Bitrate for VTS 4 VobID 1 segment 9: original 4387 - redist. 4216
Bitrate for VTS 4 VobID 1 segment 10: original 4448 - redist. 5875
Bitrate for VTS 4 VobID 1 segment 11: original 3642 - redist. 3900
Bitrate for VTS 4 VobID 1 segment 12: original 3549 - redist. 4868
Bitrate for VTS 4 VobID 1 segment 13: original 4994 - redist. 5905
Bitrate for VTS 4 VobID 1 segment 14: original 4403 - redist. 4073
Bitrate for VTS 4 VobID 1 segment 15: original 4412 - redist. 3681
Bitrate for VTS 4 VobID 1 segment 16: original 4461 - redist. 5500
Bitrate for VTS 4 VobID 1 segment 17: original 3735 - redist. 3406
Bitrate for VTS 4 VobID 1 segment 18: original 3589 - redist. 4173
Bitrate for VTS 4 VobID 1 segment 19: original 4805 - redist. 6203
Bitrate for VTS 4 VobID 1 segment 20: original 4344 - redist. 3898
Bitrate for VTS 4 VobID 1 segment 21: original 4456 - redist. 4770
Bitrate for VTS 4 VobID 1 segment 22: original 4401 - redist. 5732
Bitrate for VTS 4 VobID 1 segment 23: original 3832 - redist. 4862
Bitrate for VTS 4 VobID 1 segment 24: original 3904 - redist. 3727
Bitrate for VTS 4 VobID 1 segment 25: original 400 - redist. 186

the segment in question appears to be the ending credits: a still pictures with credits fading in and out. sounds simple, right?

both sample sizes were 20%. i also tried Q=5 and got 4093. who do i believe~~? :p do i need a bigger sample size or something, or should i always use a Q more than 1 even if it's calculated?

edit: 100% sample with Q=1 got me 304. 100% sample with Q=2, 4717 :confused:

also. if i wanted to use 100% sample size will the calculations take as long as it would take for a nomal OPV encode? (~45 min on this setup) thanks

[Boulder]

maybe i missed it, but are there any issues when using Q=1 with Bitrate Redistribution?An identical case to yours is being discussed in the "RB v1.26bitrate redistribution" thread in this same subforum. It seems there are some problems with CCE and OPV. One more reason to use HC ;)

if i wanted to use 100% sample size will the calculations take as long as it would take for a nomal OPV encode? (~45 min on this setup) thanksYes, it will take the same amount of time. If you use any filtering, you can disable those for faster performance.

[dynamis]

wow quick response. thanks Boulder. umm, how do i use HC for Bitrate Redistribution and still encode with CCE?

[Boulder]

At the moment, you can't do that. You should ask robot1 if he could add the feature, it might be useful to others as well.

[Boulder]

I have a DVD which is incorrectly detected as progressive by RB-Opt. The whole redistribution phase is done as if the whole DVD was progressive which it is not as you can see from the DVD-RB created ecl file. Some segments are flagged as progressive though, maybe that causes the confusion.

http://www.savefile.com/files/926492

[Sharc]

Are there any (serious) consequences on the redistribution from that?
I have seen many (PAL) DVDs that are effectiveley progressive, however flagged as interlaced - for whatsoever reason. I think this is normally harmless, whereas interlaced material which is erroneously flagged as progressive - as in your case - may be more critical.

Edit: Well, it probably confuses the filters with i: and p: prefixes in DVD-RB, as I assume that they obey the flags?

[Boulder]

DVD-RB is correct, there's no problem there. The problem is that in this case RB-Opt does progressive encoding on stuff that is pure interlaced video (and the ecl states progressive=0 in those segments). DVD-RB's internal redistribution encodes correctly, some segments are progressive, some interlaced.

This is one of the few correctly mastered PAL DVDs, the ones that are progressive are actually encoded as progressive and not as interlaced.

[Sharc]

So if I understand you correctly: Only the sample encodes for redistribution (i.e. Q estimation and distribution profile) are not correctly encoded when using RB-Opt for redistribution. The .ecl for the final multipass encode remains intact, and the final multipass encoding will be done correctly?
If so, is the redistribution profile (bitrates) significanty affected by the incorrect encoding? Or is this just the concern?

[Boulder]

I didn't let the process run through, I switched to DVD-RB's redistribution for that disc so I don't know what would have happened to the final ecl file. I could check it when the current encode process finishes. Encoding interlaced material as progressive is a big no-no and would have a significant effect in the redistribution. Every field is different from each other whereas in progressive video they are the same. Motion is detected falsely and chroma will take a huge hit.

[Sharc]

Interesting finding. How did you discover the wrong encode for the distribution pass? Did you analyze the sample .m2v, or was the sample file visually crap when viewing it? Were you on HC or CCE?

[robot1]

I have a DVD which is incorrectly detected as progressive by RB-Opt. The whole redistribution phase is done as if the whole DVD was progressive which it is not as you can see from the DVD-RB created ecl file. Some segments are flagged as progressive though, maybe that causes the confusion.

http://www.savefile.com/files/926492
Thank you for your report.
I have fixed the problem and will release an update soon.

[Boulder]

Interesting finding. How did you discover the wrong encode for the distribution pass? Did you analyze the sample .m2v, or was the sample file visually crap when viewing it? Were you on HC or CCE?HC is kind enough to show all the settings during the encode process so I immediately spotted that there's something wrong when I saw that the q prediction was being done as if it was progressive. I actually thought that there would only be interlaced segments as the video is a compilation of concerts and regular video footage and interviews. Then I checked the ecl file and noticed a couple of progressive segments and thought that they might be causing the issue.

@robot1: Thanks :)

[robot1]

New version:

RB-Opt v. 0.34 (http://www.savefile.com/files/927683)

Changelog:
- It's possible to force the use HC for redistribution in place of other encoders
- In avs editing, now it's possible to edit mpeg2source line (example: to add a cpu= parameter)
- When ignoring filters, also cpu parameter in mpeg2source is ignored
- Added in .ini HC_NoVBV, to disable buffer check in prediction (HC can be much faster - default FALSE = VBV enabled)
- Redistribution log is saved in a textfile - redist.txt
- Base_Q value in prediction changes according to the matrix used (could speed up the process, and could avoid CCE crash)
- Fixed a bug in OPV prediction and Redistribution with cells interlaced and progressive in the same VobID
- Minor cosmetic changes.

As always, feedbacks and bug reports are welcome

[Sharc]

Thanks robot1.

[archaeo]

thanks for the 'save log' feature!

[blutach]

Thanks for the new version robot1. From my tests, I would actually suggest HC_NoVBV default to on.

Regards

[Sharc]

@robot1:
When redistributed segments exceed the bitrate of the original DVD and are scaled down to 100% (or whatever is specified as max_reduction= ) the final adjustments are not reflected in the redist.txt. The.ecl and the encode are correct, though.
Btw. I like the matrix dependent initial_Q. It greatly reduces - or even eliminates (?) - the risk with the annoying cce bug for custom matrices.

[dynamis]

- It's possible to force the use HC for redistribution in place of

thanks robot1 for the new features. i have question about the one above. do i have to turn off ConvertToYUY2() everytime i want to use HC for Bitrate Redistribution and still use CCE to encode? the dvd-rebuilder beginner's guide says i should leave it enabled if i am using cce? the cce faq says that there is no version of cce that can natively read read YV12 input. thanks.

[Sharc]

I had the same issue.
At present you must select "ignore all filters" in RB-Opt in your case. This comments out the "ConvertToYUY2()" line in the script for redistribution with HC.
Rbobt1 is going to fix this with the next release.

[dynamis]

thanks.

[~bT~]

Donated after ages of usage! :D

[Sharc]

@robot1:
I wonder if it would be possible to introduce <HC settings>, similar to <CCE settings> in RB-Opt. In particular I find the selection of matrices very convenient and useful.

[kumi]

I agree, HC settings would be extremely useful (especially matrix adjustment). Doubly so, since HC appears to be the most popular (http://forum.doom9.org/showthread.php?t=129631) encoder around these parts. :)

[blutach]

Can I 3rd the motion? - having matrices for HC would just be icing on the cake.

Regards

[tom942]

Hehe, I asked for that sometime ago, and someone told me that add this kind of settings was a bad idea because it is a unique feature of DVD-RB, but I also support the motion :).

[Rippraff]

someone told me that add this kind of settings was a bad idea because it is a unique feature of DVD-RB
No, I told you that this is a Pro feature and even Robot1 (http://forum.doom9.org/showthread.php?p=727049#post727049) wasn't sure in the past if adding additional Pro features is a good idea.


Cu Rippraff

[Sharc]

Well, it would be nice if the Matrix could be changed after the prepare, i.e.when the bitrates are known.
I used this a lot for experimenting with redistribution. Otherwise I would alway have to rerun a prepare from scratch.

[robot1]

This feature will be added (and will work only with DVD-RB pro version, as it's a pro feature).
I hope to have it ready next week.

[Boulder]

About setting progressive/interlaced, does RB-Opt also adjust the flags according to what jdobbs says here: http://forum.doom9.org/showthread.php?t=129386. If not, I think that might be a good idea to implement as well ;) I've had to rerun the prepare phase many times just because I've forgotten to set "Disable interlaced" for the main movie.

[blutach]

Wonderful news robot1.

Thank you

Regards

[tom942]

@rippraff

I didn´t remember that you told me that :). I understood you that under any circunstance, this feature could not be implemented. BTW, as robot1 said, just checking if we are using free or pro version, then we can use these new features. :).

@robot1

Thank you for the coming version :).

Greetings.

[robot1]

About setting progressive/interlaced, does RB-Opt also adjust the flags according to what jdobbs says here: http://forum.doom9.org/showthread.php?t=129386. If not, I think that might be a good idea to implement as well ;) I've had to rerun the prepare phase many times just because I've forgotten to set "Disable interlaced" for the main movie.
I'm not sure about the problem.
You have an interlaced video, but flagged (and detected by DVD-RB) as progressive.
What is the problem about just changing the ecl in interlaced (you can do that with RB-Opt) and rebuilding with the original flags (progressive)? You should have the same result of the original DVD (wrong flags, but image ok, as the encoder knows it's interlaced).

[dynamis]

if i use HC for the Redistribution pass, is the value for "Q Factor" actually HC's CQ value? on one dvd, i get a Q Factor of 14 with CCE and 34 with HC. i know the range of CCE's Q Factor is 1-300. what is HC's range and is there any way to calculate and get an idea of what the CCE value would be? i read the HC manual.pdf but i didn't see what i was looking for. thanks.

[robot1]

if i use HC for the Redistribution pass, is the value for "Q Factor" actually HC's CQ value?
Yes, it's the CQ value, scaled by 10 (example: for a CQ value of 3.4 you get a 34 Q factor).

on one dvd, i get a Q Factor of 14 with CCE and 34 with HC. i know the range of CCE's Q Factor is 1-300. what is HC's range and is there any way to calculate and get an idea of what the CCE value would be? i read the HC manual.pdf but i didn't see what i was looking for. thanks.
There is no relationship between HC and CCE values.
Anyway I hope you can get a better answer from an HC expert.

[Boulder]

I found a little something to tweak in the q prediction phase. Currently there is no control in what region the q value is being searched. First RB-Opt may try 79, then jump to 88 and go down to 76 even though 79 was determined to be too low.

[robot1]

@robot1:
I wonder if it would be possible to introduce <HC settings>, similar to <CCE settings> in RB-Opt. In particular I find the selection of matrices very convenient and useful.

Well, it would be nice if the Matrix could be changed after the prepare, i.e.when the bitrates are known.
I used this a lot for experimenting with redistribution. Otherwise I would alway have to rerun a prepare from scratch.

I'm working right now to add some new feature to RB-Opt.
I would add the matrix selection for HC, but probably it's useless.
At the moment, DVD-RB doesn't read the matrices for HC in the Rebuilder.ecl (as it does for CCE), but it reads the matrices from it's own Rebuilder.ini.
Advantage: you can change the matrix for HC after the prepare phase without running a new prepare from scratch.
Disadvantage: if you prepare a project, than change the option in DVD-RB, you'll find the new option also for the old project.

As far as I know, from my tests, DVD-RB reads from Rebuilder.ecl these parameters with HC:
Progressive/Interlaced flag
Gop Length to use
VBR Max bitrate

I'm waiting for suggestions:
do you think I have to read and write the Rebuilder.ini file?
Is it needed, as it's possible to change the other HC parameters in DVD-RB without running the prepare?

[blutach]

@robot1

Thanks for your continued work.

I'd keep the INI file as the user wanted it. I'd say matrix selection for HC would be a very useful feature, but since jdobbs is considering adding "intermediate" matrices (see here (http://forum.doom9.org/showthread.php?p=1058876#post1058876)), it might be less of a "requirement". Though for tweakers on the cell level, I suspect that it will still appeal greatly.

Regards

[Sharc]

I used the CCE Matrix selection of RB-Opt mainly to overwrite the DVD-RB matrices - after the prepare - with one single matrix for Q-analysis, redistribution and encode, or when I simply forgot to select the desired matrices before running the prepare. It was just very convenient to make such changes without running a new prepare.
I was not aware that the HC matrices can be changed from the DVD-RB Options menu without running a prepare from scratch again. So my wish is surely less important, and maybe it's not recommended to tweak the rebuilder.ini for stability reasons.

[kumi]

I am in the same boat as Sharc: right now I often need to run a preliminary Prepare Phase, just to find out what matrices to use in the "real" Prepare Phase. What he requested would save me some time (~20 minutes... my CPU is slow.)

[jdobbs]

@robot1

Thanks for your continued work.

I'd keep the INI file as the user wanted it. I'd say matrix selection for HC would be a very useful feature, but since jdobbs is considering adding "intermediate" matrices (see here (http://forum.doom9.org/showthread.php?p=1058876#post1058876)), it might be less of a "requirement". Though for tweakers on the cell level, I suspect that it will still appeal greatly.

RegardsI've added the additional matrix selections (now it has HIGH, MED HIGH, MED, LOW, and VERY LOW) and they will be in the next release.

[blutach]

@jdobbs - thank you :)

I am in the same boat as Sharc: right now I often need to run a preliminary Prepare Phase, just to find out what matrices to use in the "real" Prepare Phase. What he requested would save me some time (~20 minutes... my CPU is slow.)Why not use a bitrate calculator to get into the ball park to begin with? I use Videocalc (http://www.videohelp.com/tools/VideoCalc).

Regards

[robot1]

I am in the same boat as Sharc: right now I often need to run a preliminary Prepare Phase, just to find out what matrices to use in the "real" Prepare Phase. What he requested would save me some time (~20 minutes... my CPU is slow.)
As I stated above, you don't need to run the prepare phase again if you use HC. Simply change the matrices selection in DVD-RB: it will use the new ones.
If you use CCE or AQE, you have to change the matrices in RB-Opt.

[kumi]

@blutach: thanks for the Videocalc recommendation.

@robot1: d'oh, sorry... sometimes it's hard to keep track of where DVD-RB stores all it's settings.

[robot1]

Download here (http://www.savefile.com/files/1159994)

Changelog:
- Fixed a bug with HC redistribution.
- Better control of values in Q prediction phase, as suggested by Boulder.
- New HC settings window, to tweak some of the HC parameters. Notice: the matrices selected in RB-Opt will be used for Q prediction and redistribution. DVD-RB will use the matrices selected in its menu.
- Added a new hidden value, to set the lower average bitrates:
with the default
min_bitrate=0
RB-Opt uses:
850 for HC
900 for ProCoder
1150 for CCE
The value 900 for ProCoder is the lowest accepted by the program.
The other are the lowest accettables, in many test (thanks to Sharc for testing).
If you want to override this behaviour, insert a custom min_bitrate value.
The minimum bitrate is set *after* saving and displaying the redistribution log, if you want to check, you can find the actual value in the tweak cell dialog.

[~bT~]

^ Ty Ty Ty!

[blutach]

Thanks robot1

Regards

[kumi]

Fabulous, thanks.

[robot1]

For a stupid mistake introduced while coding, the matrix selection in HC settings wasn't updated at all.
In previous versions, if you changed a matrix in CCE settings, in some circustamcies, the selection wasn't taken in account for redistribution (the program used the matrices selected in Rebuilder.ecl - you had to save before redistribution).

Download (http://www.savefile.com/files/1169343)

[HKT3020_1]

Probably a stupid question but is it possible to have an updated step by step guide with images.
I'm sure there are a few others like me who seem intimidated by working with a new program alongside DVD-RB. :rolleyes:

[rendez2k]

Probably a stupid question but is it possible to have an updated step by step guide with images.
I'm sure there are a few others like me who seem intimidated by working with a new program alongside DVD-RB. :rolleyes:

I'd like this too. Probably a stupid question but can't you now edit reduction %'s in the new segment viewer? What extra features am I missing by not using RB-Opt?

[mikenadia]

Trying to understand optimal Q, I noticed this.
I am going to redistribute bitrate between two VOB_ID (one significant cell each) but with very different individual optimal Q.
ID-1. optimal Q:50 original bitrate:1854 ; nb frames:3524
ID-2. optimal Q:82 original bitrate:1185 ; nb frames:6571
Optimal Q for the combination based on 100% opv_sample_size (computed by RB-opt):71.
I assume that is the optimum.
Then both VOB are encoded, new sizes are computed and new bitrates are assigned on a pro-rata basis (no loss of bits).
ID-1.encoded bitrate (Q=71):1310 reassigned birate:1352 (1310*1.032)
ID-2.encoded bitrate (Q=71):1409 reassigned birate:1454 (1409*1.032)
The reassignement factor (no loss of bits) is bigger than 1,therefore that the actual optimum Q is less than 71.
If we compute back the individual optimal Q with the new assigned bitrates, they should be equal or close.They are not because of the pro-rata basis reassignement.
May be a reassignement based on empirical data, I do not know...
The actual optimum Q (trial and error) is between 68 and 69.
ID-1. encoded bitrate (Q=69):1346 reassigned birate:1354
ID-2. encoded bitrate (Q=69):1445 reassigned birate:1453
I agree that it is not a big difference but room for thought.
The same issue exists (if it is an issue) if you reassign one VOB-ID after bitrate distribution (because it is also done on a pro-rata basis).:)

[robot1]

Probably a stupid question but is it possible to have an updated step by step guide with images.
I'm sure there are a few others like me who seem intimidated by working with a new program alongside DVD-RB. :rolleyes:
My english is not so good to write a comprehensible step by step guide. If there is a volunteer, I could help.

[robot1]

Trying to understand optimal Q, I noticed this.
I am going to redistribute bitrate between two VOB_ID (one significant cell each) but with very different individual optimal Q.
ID-1. optimal Q:50 original bitrate:1854 ; nb frames:3524
ID-2. optimal Q:82 original bitrate:1185 ; nb frames:6571
Optimal Q for the combination based on 100% opv_sample_size (computed by RB-opt):71.
I assume that is the optimum.
Then both VOB are encoded, new sizes are computed and new bitrates are assigned on a pro-rata basis (no loss of bits).
ID-1.encoded bitrate (Q=71):1310 reassigned birate:1352 (1310*1.032)
ID-2.encoded bitrate (Q=71):1409 reassigned birate:1454 (1409*1.032)
The reassignement factor (no loss of bits) is bigger than 1,therefore that the actual optimum Q is less than 71.
If we compute back the individual optimal Q with the new assigned bitrates, they should be equal or close.They are not because of the pro-rata basis reassignement.
May be a reassignement based on empirical data, I do not know...
The actual optimum Q (trial and error) is between 68 and 69.
ID-1. encoded bitrate (Q=69):1346 reassigned birate:1354
ID-2. encoded bitrate (Q=69):1445 reassigned birate:1453
I agree that it is not a big difference but room for thought.
The same issue exists (if it is an issue) if you reassign one VOB-ID after bitrate distribution (because it is also done on a pro-rata basis).:)
In the first step, as you have very different Q factors between the two VobID's, RB-Opt has done an estimate of the Optimal Q (on a linear basis). Obviously it cannot be exact - as Q relation with bitrate is not linear, and it has calculated the bitrate as 1352 and 1454.
For your trial and errors you have found the effective optimal Q as 68 or 69, and the optimal bitrates as 1354 and 1453.
As RB-Opt was wrong for only 1 or 2 kbps, I think the guesstimate was excellent.

[mikenadia]

You are right. Thanks for your program.:)

[mikenadia]

Robot1, we agree that the reassigned bitrate distribution is not too sensitive to optimal Q.
Therefore, may be it is possible to speed up the process when you redistribute bitrate among different VOB-ID (specially Extras).
If I am doing it for 10 VOB_ID , it computes optimal Q for each VOB_ID, going through reiterations (till the size is within 1%).For small VOB-ID, it may involve 6 iterations for each VOB_ID .
May be,compute size for each VOB_ID, use your algorithm to compute aggregate Q (and its corresponding size), and then go through a second iteration.That may require only 3 iterations (beacause the aggregate file is larger).
I know that I can keep the 1% for main movie and 5% for Extras, but my strategy is to compute optimal Q for all the VOB_ID (Main Movie and Extras with Half_D1,therefore not transferring unecessary bitrate to Extras).:)
End of discussion for me.
P.S. In Extras, I have the Main Movie in 4:3 split in 25 significant VOB-ID.

[robot1]

Therefore, may be it is possible to speed up the process when you redistribute bitrate among different VOB-ID (specially Extras).
If I am doing it for 10 VOB_ID , it computes optimal Q for each VOB_ID, ...
If different VobIds are in the same VTS, you can already speedup the process.
In the main dialog window, use the "Vob-Id link" option to join all the VobIDs. In this way RB-Opt will act as if there is just one larger VobID, and perform a single redistribution process.
If VobIDs are in different VTS it's impossible to have a single process.

[mikenadia]

I tried that before (and tried it now) but I could not make it work.
I am using DVD Rebuilder 98.2 (may be that's why?).
I am trying to link VTS1-VOB_ID1 (with only one cell inside) and VTS1-VOB_ID3 (with only one cell inside) .Same VTS.
I tried to select at the same time VTS1-VOB_ID1 and VTS1-VOB_ID3 using the CTRL or Shift Key but I am not lucky.
I select in the list VTS1-VOB_ID1 ,click on the "VOB-ID Link" button and I have the follwing warning :"This VOB-ID can't be linked .It is the only VOB_ID of the set.

Thanks for your help and patience.Newbie at work.:)

[robot1]

I am trying to link VTS1-VOB_ID1 (with only one cell inside) and VTS1-VOB_ID3 (with only one cell inside) .Same VTS.

Try unchecking the "Hide Vob-Ids of insignificant size". You should find also the VobID n.2, and link all in the VTS.

[ercofra]

I've found a bug with CCE SP2 and OPV, with 4:3 PAL movies:
the .m2v file created by RB-Opt 0.36 during OPV prediction has a black bar at the bottom; I've found that the problem is in the .ecl file created by RB-Opt, it's missing these settings:
ve_src_roi.x=0
ve_src_roi.y=0
ve_src_roi.w=720
ve_src_roi.h=576
ve_dst_roi.x=0
ve_dst_roi.y=0
ve_dst_roi.w=720
ve_dst_roi.h=576


These settings specifies the "region of interest" coordinates of input and output files; without them, CCE SP2 assumes a frame size of 720x480, and the original frame of 720x576 (for PAL) is cutted at the bottom.
You can check this by manual loading in CCE SP2 the ECL file created by RB-Opt during OPV prediction, go to "Encoder setting - Area setting... - Input/Output file", and look at the "region of interest" coordinates, they are 0x0, 720x480; after manual adding the above settings, try to load again the ECL file, now the "region of interest" coordinates are correct (0x0, 720x576); manual encoding with the fixed ECL produces a correct .m2v file with full frame size.
The consequence of this bug, is that the Q factor is always under estimated and the resulting DVD is oversized (5 GB!), because the REBUILDER.ECL has the correct settings, and the final .m2v is encoded correctly, but with a bad predicted Q.
Thanks for your great program.

[robot1]

I've found a bug with CCE SP2 and OPV, with 4:3 PAL movies
Thank you for your detailed bug report. I will try to solve tomorrow, or in the next few days.

[mikenadia]

=== Running prediction on VTS 2 - VobID 2
*** Warning: sample selected too small
*** Using 26.71% sample size.

--- Initial Q: 107
--- Pass 1. Testinq Q factor: 107
--- Desired sample size: 21172 KB
--- Waiting for encoder...
--- Obtained sample size: 1420 KB (-93.3% error)
--- Pass 2. Testinq Q factor: 1
--- Desired sample size: 21229 KB
--- Waiting for encoder...
--- Obtained sample size: 1420 KB (-93.3% error)
--- No change in Q for next iteration
*** Using Q factor 1

[robot1]

As you can see in your log, the encoded size of the segment with both q=107 and q=1 is 1420KB (expected size is 21.172KB).
As you can have q lower than 1, RB-Opt uses q=1.
Anyway I think you should check your input, as in normal conditions it's impossible to have the same output with q=107 and q=1.

[mikenadia]

Thanks;). Bad rip. Only black frames (284 Mg !) in that VOB. I should have checked.
P.S. I found that bad rip ,thanks to you , and because I was looking at the temporary log of optimal Q computation.It may be useful to have in the final log the optimal Q for each VOB and the aggregate one.Thanks again.

[robot1]

Here is the new build:
RB-Opt v 0.37 (http://www.savefile.com/files/1341148)

Changelog:
Bugfix: fixed wrong OPV prediction for CCE SP2 and Pal 4/3 movies, as reported by ercofra.

Added more info in the redist.txt file after redistribution (with actual bitrates stored).

Added a new parameter in the .ini file: redist_BIAS (values: 0 - default redistribution; 100 - no redistribution)
The "redistribution_bias" parameter limits the min_cell_bitrate for example to 55% of the DVD-RB standard value, and the max_cell_bitrate to 1/55% = 182%
More examples
bias min_cell_bitrate max_cell_bitrate
0 0 (infinite) i.e. full redistribution
50 50% 200%
60 60% 167%
75 75% 133%
100 100% 100% ie same as DVD-RB "original" means no redistribution.

Probably a BIAS between 50 and 65 would be a good choice.

Anyway, with RB-Opt you can always tweak the redistribuited bitrates, without losing the benefit of redistribution for other cells (I often tweak the end credits cells after redistribution)

[blutach]

Thanks robot1.

Regards

[Fishman0919]

Thank You robot1

[gurkan]

Hello. I've managed to create another one of these (http://forum.doom9.org/showthread.php?p=1011198#post1011198). Is there a way of not using q 1 as base for redistribution estimation in second pass?
Maybe using 2 or 3? The source is fullscreen and interlaced pal, so I'm pretty sure the end result is gonna be quite a high q.

[robot1]

What is the q value found in the first pass?

[gurkan]

=== Running prediction on VTS 1 - VobID 1
--- Initial Q: 39
--- Pass 1. Testinq Q factor: 39
--- Desired sample size: 3800602 KB
--- Waiting for encoder...
--- Obtained sample size: -371475 KB (-109.8% error)
--- Pass 2. Testinq Q factor: 1
--- Desired sample size: 3804214 KB
--- Waiting for encoder...

[robot1]

If in the first pass it finds 39, it's impossible to go down to 1.
I think the problem lies in CCE or in the source. Even if RB-Opt would not allow q=1 (and why, if it's a possible value? ... it's another problem of CCE), I don't think you would get a right final q.

[gurkan]

Ok. Thanks for the info and a great app. Added second pass info to my post if it's of any interest.
By the way, you don't think it could be because I used 100% sample? I'm going to try a smaller value and see if it makes any difference.

added:
Yep. This is what I get on the second pass with 25% sample. Looks like an improvement.

=== Running prediction on VTS 1 - VobID 1
--- Initial Q: 39
--- Pass 1. Testinq Q factor: 39
--- Desired sample size: 968990 KB
--- Waiting for encoder...
--- Obtained sample size: 991390 KB (2.3% error)
--- Pass 2. Testinq Q factor: 40
--- Desired sample size: 968966 KB
--- Waiting for encoder...

[Boulder]

Looks like CCE crashes in the example where it jumps from Q39 to Q1.

[gurkan]

@ Boulder

CCE does complete the first pass and no error message was seen before the one of the second pass. Maybe I should have a look at the filesize and see if it's playable. I'll try it when I get home from work.

[Boulder]

CCE simply exits during the encode and doesn't give any warnings or error messages. The problem has been discussed in this thread earlier.

[gurkan]

@ Boulder

Sorry, must have missed it.

[mikenadia]

I think I had related issues with HC.
http://dvd-rb.dvd2go.org/modules.php?name=Forums&file=viewtopic&t=1365

http://dvd-rb.dvd2go.org/modules.php?name=Forums&file=viewtopic&t=1363

Thx for the new version.

[~bT~]

Thanx!

[robot1]

=== Running prediction on VTS 1 - VobID 1
--- Initial Q: 39
--- Pass 1. Testinq Q factor: 39
--- Desired sample size: 3800602 KB
--- Waiting for encoder...
--- Obtained sample size: -371475 KB (-109.8% error)
--- Pass 2. Testinq Q factor: 1
--- Desired sample size: 3804214 KB
--- Waiting for encoder...
I missed your second pass info.
The result you find (negative) is very strange.

Ok. Thanks for the info and a great app. Added second pass info to my post if it's of any interest.
By the way, you don't think it could be because I used 100% sample? I'm going to try a smaller value and see if it makes any difference.

Are you using 100% sample in REDISTRIBUTION or in Q PREDICTION?
Q Prediction is a multi-pass algorithm to find the Q value which gives, with only 1 effective pass, a final size similiar to a multipass encoding. Having a 100% sample is a nonsense, as you would have at least two full pass - you have no benefit and could perform a multipass encoding.
In Q Prediction the sample should be not over 3-4%, to have sense.
Regards

[gurkan]

Thank you. I was not aware of this. I was doing a 100% sample q prediction.

[ercofra]

Here is the new build:
RB-Opt v 0.37 (http://www.savefile.com/files/1341148)


This download link don't work for me, I've tried several times, but with no luck..

Alternative links?

Thanks

[jdobbs]

Interesting. I just clicked on it in your post and it worked for me.

I just loaded it on my site. Try this link. (www.jdobbs.net/Freeware/RB-Optv0.37.zip)

[ercofra]

Interesting. I just clicked on it in your post and it worked for me.


Still don't work for me, Internet Explorer refuses to connect to the site, I don't know why..

Try this link. (www.jdobbs.net/Freeware/RB-Optv0.37.zip)

Your link is OK, thanks jdobbs!

[robot1]

Interesting. I just clicked on it in your post and it worked for me.

I just loaded it on my site. Try this link. (www.jdobbs.net/Freeware/RB-Optv0.37.zip)

Thank you.
I've updated the first post with your link.

[Rippraff]

By the way, you'll always find the latest version in the link at the bottom of the first post in this thread.

Even if you're not a german speaking person, I'm pretty sure you'll find the attachment. ;)

Cu Rippraff

[mikenadia]

Sometimes, in the same VTS, I have some VOB non interlaced, others interlaced.
Can I link them and if yes, on what criteria, should I use "ConvertToYV12()" or "ConvertToYV12(interlaced=true)" in the linked VOB-ID.
Thx

[robot1]

You should not link interlaced and non interlaced VobID's

[ercofra]

I've tried a backup with OPV and CCE SP2 and I've found there's still a little bug but I don't know if it affects prediction; in the ecl file created during prediction there's a little mistake in this line:

ve_dst_roi.h=720 (correct is 576 for PAL and 480 for NTSC)

This specifies the destination height for the "region of interest", 576 for PAL, and 480 for NTSC (720 is the width).

[Boulder]

robot1,

could you make Rb-Opt 100% compatible with the current HC release? It requires the *PROGRESSIVE statement in the ini file if the source is flagged as progressive. Otherwise it'll use the hybrid mode which is not optimal for progressive sources.

[robot1]

robot1,

could you make Rb-Opt 100% compatible with the current HC release? It requires the *PROGRESSIVE statement in the ini file if the source is flagged as progressive. Otherwise it'll use the hybrid mode which is not optimal for progressive sources.
Yes, I will do soon.
Should I also use the nosmp switch if multiple encoding is selected?

[Boulder]

Yes, the performance is optimal with SMP disabled and multiple simultaneous instances of the encoder.

[blutach]

Not always. For example, if the last segment is lengthy. This should be an **option** only, IMHO.

Regards

[Boulder]

Not always. For example, if the last segment is lengthy. This should be an **option** only, IMHO.In that case, true. What about always enabling SMP for the last 2-4 (depending on the number of detected CPUs) segments or so? Though that might be a bit too pedantic ;)

[blutach]

Can't do it on such a simple formula sad to say Boulder. Suppose it's the 2nd last segment that's the long one and the last is a little one (and 2 cores for simplicity). You want the CPU usage to jump up once it is free. The answer is enabling SMP. Also, if I am not mistaken, SMP possibly makes the redist'n pass quicker.

Regards

[Boulder]

But if you always enabled SMP for the last 2-4 segments, your case would be covered :)

Then again, the overall performance reduction shouldn't be big if SMP was always enabled. HC uses one thread for decoding and the other for MPEG2 encoding. If you have a simple script, most of the CPU time is spent in the MPEG2 encoding thread so running two instances with SMP enabled (and a simple script) means that two threads are utilized heavily and two threads are used very little. It should be close to running two instances with SMP disabled.

[blutach]

Yes. I've actually found very little gain with NOSMP (on DVDs where segments are "normal sized") and as discussed, some loss where there are largish segments near the end.

Regards

[mikenadia]

I have a DVD with a lot of small videos where only a small area of the frames is moving (the background is mostly static).
DVD_RB shows me a 55 % reduction level for DVD-5 and an avg bitrate of 3380 Kbs.
Because the background is mostly static, the optimal Q computed by Rb-opt is 18. I was wondering if the choice of the matrix should be based on optimal Q (and in this case, what about the fact that optimal Q is much higher for interlaced video : which is the case of this DVD ) instead of high-medium-low bitrate.
Thx for your advice.
P.S. May be the title of the thread should be changed (v.037).Thx,robot1 for the excellent program!

[Boulder]

I would use a high-bitrate matrix (such as the High-High from DVD-RB) myself. It looks like you might get encoder saturation with the current matrix selection.

[mikenadia]

Well, just MHO -- but I still think that if you have a CBR source the best you can do is a bitrate that is equal to the one used in CBR... otherwise you'd have to be getting the additional missing detail out of the cosmic ether. DVD-RB sets the max to the CBR rate because anything higher would probably only amplify the error (blockiness).

But, as I always say, too each his own.
Can we deduct from the quote that the new redist_BIAS should not be smaller than the reduction level computed by DVD-RB during the Prepare phase?
Thx

[jdobbs]

redist_BIAS?

[mikenadia]

Here is the new build:
RB-Opt v 0.37 (http://www.savefile.com/files/1341148)

Changelog:
Bugfix: fixed wrong OPV prediction for CCE SP2 and Pal 4/3 movies, as reported by ercofra.

Added more info in the redist.txt file after redistribution (with actual bitrates stored).

Added a new parameter in the .ini file: redist_BIAS (values: 0 - default redistribution; 100 - no redistribution)
The "redistribution_bias" parameter limits the min_cell_bitrate for example to 55% of the DVD-RB standard value, and the max_cell_bitrate to 1/55% = 182%
More examples
bias min_cell_bitrate max_cell_bitrate
0 0 (infinite) i.e. full redistribution
50 50% 200%
60 60% 167%
75 75% 133%
100 100% 100% ie same as DVD-RB "original" means no redistribution.

Probably a BIAS between 50 and 65 would be a good choice.

Anyway, with RB-Opt you can always tweak the redistribuited bitrates, without losing the benefit of redistribution for other cells (I often tweak the end credits cells after redistribution)
Redist_BIAS added in Rb-opt.037 ( divided by 100) compared to
- Reduction Level for DVD-5: in DVD-RB

[Sharc]

You can do the redistribution either with DVD-RB, or you may use RB-Opt for the same purpose. Both have a parameter in their respective .ini files which controls the swing of the redistribution.
In DVD-RB this is a hidden option, and the parameter is called "REDIST_LOW_THRESHOLD=" It's default value is 0.5 (means 50%).
RB-Opt uses a similar parameter "redist_BIAS=". The value there has to be given as a percentage number, for example "redist_BIAS=50" in the RBOpt.ini will basically have the same effect as "REDIST_LOW_THRESHOLD=0.5" in the rebuilder.ini.

Leaving the default value for DVD-RB (actually you don't have to set anything there) or set "redist_BIAS=50" in RB-Opt is recommended from many tests.

[mikenadia]

Thx, but I wanted to know if redist_BIAS should not be at least equal to the reduction level.
I have a DVD authored with a CBR (reduction level to fit DVD5 equal to 66 %). After running Rb-opt (with redistr_BIAS equal to 50), I have some bitrates (biased in redist.txt) that are higher than the actual (bitrate without redistribution in the compressed DVD5) by more than 51 %(1/0.66=1.51) and therefore are higher than the one in the uncompressed DVD9. (That is my understanding).
Thx again.

[mikenadia]

I have a VTS-VobID with the first cell (only 39 frames ) flagged as interlaced (according to the avs file of that cell ) and all the others ( for a total of more than 80 000 frames ) flagged as progressive.
It seems that during optimal Q computation, rb-opt is using HC with interlaced flag (because of the first cell).
Will it have an impact of optimal Q and if yes what can I do (including using DGindex)?
Can I assume ( probably not ) that the redistribution profile within that VTS-VobID will be the same wthether it is flagged interlaced or not (I mean the biased bitrate for each cell within that VobID)?

BTW, I would like to compute optimal Q with DC prec=8 (if that is what I will use for the encoding).
Will it have an impact on optimal Q and how do I change it (probably should put HC_AutoDC=0 in rb-opt.ini but what else?)
Thx.
P.S. I have the interlaced flag during optimal Q computation (in HC encoder settings) even for VTS-VobID that have all cells progressive for the same DVD.
Is it what Boulder described in post 801 or not related at all?

[jdobbs]

Don't put too much weight on that Q value. It's nice to get close, but the distribution really doesn't drift that much unless you have dramatic changes in Q.

[Dashiell]

Hello, all!

Is there any line I can add/alter on the .ini file that will turn the "Natural Filter" in CCE Basic ON for all encodes?

Yes, yes I know this can be done with RB-Opt but I'd like to be able to switch it on for 1-click mode as well.


Thanks, all!

[Sharc]

Thx, but I wanted to know if redist_BIAS should not be at least equal to the reduction level.
I have a DVD authored with a CBR (reduction level to fit DVD5 equal to 66 %). After running Rb-opt (with redistr_BIAS equal to 50), I have some bitrates (biased in redist.txt) that are higher than the actual (bitrate without redistribution in the compressed DVD5) by more than 51 %(1/0.66=1.51) and therefore are higher than the one in the uncompressed DVD9. (That is my understanding).
Thx again.
The redist_BIAS does not depend on the reduction level. It only sets the lowest and highest acceptable cell bitrate. One can leave the redist_BIAS at 50 - irrespective of the reduction level.
For example when the CBR of your original disc is say 6000 kbps it will become 66% of 6000 = 3960 kbps (CBR) to fit onto a DVD5.
Setting redist_Bias=50 means that after redistribution the lowest redistributed cell bitrate will never become less than 50% of 3960 kbps = 1980 kbps (low limit), and the highest cell bitrate will not exceed 1/0.5 = 2 x 3960 kbps = 7920 kbps (upper limit).
If redistribution would actually lift a cell to the said 7920 kbps, it will - in a final step of the redistribution process - be reduced to the original 6000 kbps, following the rule that the redistributed cell bitrate must not become higher than the bitrate of the original uncompressed DVD.

[mikenadia]

Thx a lot for your explanation. I was not aware of the "final step". It is possible that when you have more than 1 cell that needs that final step, some are rounded, due to "Autosize". In one example, I have 3 cells with Reduction set to 99.4% 99.6% and 100%.
May be the cells above 99% should be forced to 100% and avoid reencoding.

[jdobbs]

Hello, all!

Is there any line I can add/alter on the .ini file that will turn the "Natural Filter" in CCE Basic ON for all encodes?

Yes, yes I know this can be done with RB-Opt but I'd like to be able to switch it on for 1-click mode as well.


Thanks, all!I'll add it to the menus.

[robot1]

Download here (http://www.savefile.com/files/1400505) or here: RB-Opt v0.38 beta (http://forum.gleitz.info/attachment.php?attachmentid=91918&d=1203877329) (mirror by Doom9.de)


Changelog:
- Bugfix: fixed a wrong parameter in OPV prediction for CCE SP2 (thanks to ercofra for pointing it out)
- Added *PROGRESSIVE statement in HC.ini for progressive sources (HC 0.22 compatible)
- Added *NOSMP statement in HC.ini if multiple processes used (the last segments are econded in multiprocess mode)
- Set to 15% the maximum Sample Size for prediction (1-3% suggested)

If you use multiple processes, SMP mode in HC is used when
frames_current_segment > all_frames_to_encode/(nr_process-1)

Usually the last 2-4 segments (according to the number of threads used) are encoded in SMP mode, but this should cover also strange cases (as a very long segment followed by many small segments)
Regards

[Boulder]

Thanks, will fire up a new project right away :)

[Dashiell]

I'll add it to the menus.

Thanks, J! Fantastic program, btw!

[blutach]

Just a feature request (for a lazy old man).

How about the ability to drag and drop the Rebuilder.inf file onto the RBOpt GUI to open it?

Regards

[mikenadia]

Just a concept. I found out that on some DVDs the Q for the Extras (using a low bitrate matrix) was similar or smaller than the one for the main movie (using MPEG standard).
Therefore the idea of setting a minimum Q for the Extras, compute bitrate of Extras for that Q and that low bitrate matrix and if the result is smaller than the "Autosized" one, reallocate automatically bitrate to the main movie.( A maximum Q could suggest a lower bitrate matrix).
Similarly, a minimum bitrate for the main movie could indicate a higher bitrate matrix if necessary.

[Sharc]

Interesting proposal - basically what you are suggesting is a compressability test for the Extras in order to determine the minimum acceptable bitrate/file size automatically. The problem I see is the selection of the "minimum Q", as it depends on the selected matrix itself and the source (sort of chicken and egg situation). For example a "high Q/high bitrate matrix" combo often produce visually better results than a "low Q/low bitrate" combo for the same file size, or in other words a low bitrate matrix for the extras will normally require a low Q at the same time for acceptable visual results. Your proposal may work best for encoders which follow a "constant quality" strategy rather than a "constant quantization" strategy though. Interlaced/progressive material in the Extras may be another difficulty for selecting the appropriate Q. Just some thoughts. Did you already do some verification tests?

[mikenadia]

I have very bad visual judgment (and only a 26" TV) so I cannot make the difference between HighQ-High bitrate combo and the LowQ-Low bitrate one. I have made the previous comment because I am choosing the bitrates and the matrixes on a random basis and I rely on the forum members to set up a methodology ( as you say, may be different matrixes for interlaced and progressive or having a multiplier to make a relationship between constant quality and constant quantizer: optimalQ=average( Q for progressive and alpha x Q for interlaced) alpha determined by visual tests on an average of different sources and users).
Also (and I do not know how) take into consideration encoder saturation, blocking .
If you think it may have some traction, may be start a new thread.
Thx.

Edit: on a unrelated subject, because I am always preprocessing the rip with VobBlanker, I split (for fun) every non-negligible cell in 2. Got a smoother (smaller difference in bitrate between 2 consecutive segments) distribution . If there is any negative consequence of doing it , please let me know (other than the risk of preprocessing, which I am assuming).
Before splitting:6674 frames. bitrate 2926
Same cell after splitting: part1:2975 frames . bitrate 2362
part2:3699 frames . bitrate 2942
The missing bitrates were transferred to another area of the movie ( distribution made over 36 segments instead of 18).

[Sharc]

As I said, I personally find your proposal interesting. Today, the settings for Extras are based on file size (0%,10%,25%,33%,50% steal space from extras -- what is the right choice for acceptable quality?). Your approach is Q (quant or quality) based. I have often seen that the titles in the extras are inconsistent regarding quality and bitrate. That's why I sometimes do a special redistribution pass using RB-Opt for the Extras, just for equalizing their quality. Your approach would also help in this respect.
At the end, such feature needs to be implemented -- by probably robot1 and/or jdobbs. If they are convinced that it is worth to be followed up their motivation may also - to some extent - depend on donations ....... ;)

[jdobbs]

You can always set "Apply Distribution to all VTSs" and then the entire disc (including extras) is adjusted to a single Q.

[Sharc]

Yes, clear. But this has sometimes the tendency to 'steal bits from the feature' rather than to accept a minimum Quality (set by the Q) for the Extras and give the saved space to the feature.
But I agree that this may had helped in mikenadia's case where he/she found equal or lower Q's for the Extras - although I am not sure because the bitrate distribution for the Extras would have been done with the default matrix (DVD-RB).

[jdobbs]

You've underscored exactly the problem with selecting a Q for extras. If yoiu set it you have to live with it -- even if it steals from the feature. The problem is that you don't know which way it is going until after you've set it...

[mikenadia]

I was not thinking of any change neither in DVD-RB nor Rb-opt, but notwithstanding the valid issues raised by Sharc in post 827 (cf proposed solution in post #837), a process similar to:
- compute optimal Q for Extras and save.
- If optimal Q below arbitrary minimum Q, make an educated guess for Extras bitrates that will make optimal Q close to minimum Q.
- Input those new bitrates in Extras and compute optimal Q for Main movie.

[Sharc]

Well, without modifying RB-Opt or DVD-RB you can do this manually today.
- After the Prepare you run a separate redistribution pass with RB-Opt on the Extras only, using your selected matrix.
- If you find the calculated Q for the Extras to be too low (means you assume (!) you could have reduced the Extras more and still get acceptable quality), you can reallocate bitrates manually between the Extras and the feature (using RB-Opt and Save or using the DVD-RB Editor and Save)
- or you could rerun the standard Prepare (few minutes) selecting a higher value for "steal space from Extras" and repeat the process .........

When I want to keep some Extras, I normally select Steal Space from Extras 25% or 33%@Half D1 for the Prepare. This reduction for the Extras will in very most cases not lead to unexpected low Q's - even with low bitrate matrices selected.
After the Prepare I inspect the bitrates of the extras and then I decide if I want to run a separate redistribution pass on the Extras only (with RB-Opt) in order to "balance" their quality.

[mikenadia]

1) Talking about decreasing bitrate in endcredits cell. If I do it before redistribution, I have to do it after redistribution (there may be a conceptual reason but do not know why) and the autosize function modifies the optimal distribution (did the following test. Optimal Q of the main movie with an ABR of 3800.Save.Take some bits from the extras so the ABR of the main movie is 4000. Take a note of the bitrate distribution of the main movie. Do optimal Q. The new distribution is different ( for some cells , by more than 2 %).
2) by splitting the cells of the main movie in 2, I got a very different (and supposedly more efficient if the concept of OPV is working) bitrate distribution.
At least, on a conceptual basis, splitting the avs script in N scripts using Trim functions and then join the sub-cells M2v into a cell M2v (in a non-transparent process) may be closer to constant quality (if the OPV concept is working).

P.S. Will be nice to have a SSIM for the main movie so we can measure the gains of the OPV concept.

[Sharc]

1) When going for redistribution, the tweaking of cell bitrates before the redistribution pass does not make sense as the cell bitrates will be overwritten by the redistribution process. So if you want to reduce the end credits, do it after the redistribution pass.
Don't worry about a 2% discrepancy. You won't notice a difference in viewing.
2) Your new cells are different from the original ones (half the number of frames per cell) so the redistribution will produce different results based on your new cell structure. If for example the frames in cell 1 of your split cell contains a lot of details or action and cell 2 is a black screen, cell 1 will get all the bits allocated. Good luck with your cell granularity tests.

[Boulder]

Hi robot1,

are you planning on adding support for the new AQ feature of HC023? Or possibly add support for overriding the ini file to cover any later changes/additional features in HC023?

[robot1]

Yes, I will add support for AQ feature, and will have an ini option for custom changes for HC.

[Dashiell]

Hello, all!

Is there any line I can add/alter on the .ini file that will turn the "Natural Filter" in CCE Basic ON for all encodes?

Yes, yes I know this can be done with RB-Opt but I'd like to be able to switch it on for 1-click mode as well.


Thanks, all!

I'll add it to the menus.

Not to be a pain, but was this ever implemented?


Thanks in advance!:thanks:

[J-Wo]

How important is the sample size during redistribution? I notice that DVD-RB defaults to 10%, but RB-Opt does 20%

[blutach]

Given faster machines these days, doing 20% still only takes a short time. I use that.

Regards

[Boulder]

I use 100% - the difference in time needed to go through the phase is very small compared to the total time of the encode/rebuild process on my E6750.

[Devilman1]

Can somebody upload the latest version?
Is not available anymore.

TIA

[manolito]

No problem...

https://www.sendspace.com/file/u3ao2o

Cheers
manolito

[Devilman1]

Thank you