RBOpt cell tweaking bug?

[raddygast]

Hello all. I have a title I'm experimenting with. Using DVD-RB 0.74 and RB Opt 0.17beta.

I have either discovered a bug or a deficiency in my own understanding of RBOpt. Here is the scenario. I've

run the prepare phase on a movie title (no extras). Then I open RBOpt and open the rebuilder.inf.

VTS 2 (the only title) has vobids 1 through 13. Vobid 13 contains the credits. It seems like each vobid contains more than one cell: vobid 13 has two cells. The last cell (cell 31) is the credits.

My question is regarding the interaction of tweaked cells and all the other autosized components. So here are some concrete figures




vobid 2 avg 4653
vobid 13 avg 3586

inside 13, first cell 4597, second cell 3323
if I set second cell to 1200 manually, and leave first cell auto, it goes to 6892 (preserving avg 3586 for this vobid, or so it says). That's strange to me, as I thought autosize would resize the first cell, but also all the other cells in the VTS. This seems like the first cell in the same vobid is scooping up all the space freed by lowering the last cell.

Anyway, when I apply, and go back to the list, it looks like the vobid has an avg of 2378 now (down from 3586). So I really don't understand why the first cell would jump to 6892. But going back into tweak shows the first cell still as 6892, second cell 1200 (manual).

So the first bug is the vobid avg bitrate isn't updating correctly when you tweak a cell, because one of the two averages must be wrong since the program is still showing 6892 for (auto) first cell, and 1200 (manual tweak) for the last cell.

Second bug (maybe?), the first cell in the vobid should not instantly jump to 6892 because I lower the second cell. Shouldn't it scale with all the rest of the cells in all the rest of the vobids?

Final weirdness. As I said I tweaked the second cell in the last vobid: the first cell was still set to auto, and all other vobids were left untouched (auto) at the vob level. However, I noticed that they all increased slightly after the tweak, for example vobid 2 avg now goes from 4653 to 4726, which is what you'd expect, except that the tweak seemed (initially) to have only affected the other cells in that specific vobid (in this case only one other cell).

But now, thinking about it (and the fact that the last vobid is listed in the main window as avg bitrate of 2378 now), my guess is that the program is behaving correctly: the first cell in the last vobid is probably scaling appropriately, explaining the change in the avg bitrate of the last vobid and consequently bumping up all other vobids too -- but for some reason there is a display bug on the bitrate of
that first (non-tweaked) cell in the last vobid. It definitely shouldn't be 6892.

Is the best way just to link all the vobids in VTS2 (the movie) and then just go ahead and tweak the cells individually? That would seem simpler, but I just wanted to understand the default behaviour. If each vobid is separate, you wouldn't expect their avg bitrates to change when you tweak a cell in another vobid (in the same title of course).

Does that make any sense to anyone? I know it's a mouthful, but I'm hoping to have the situation clarified.

Have I discovered bugs here, or am I being an idiot?

[robot1]

Originally posted by raddygast
So the first bug is the vobid avg bitrate isn't updating correctly when you tweak a cell, because one of the two averages must be wrong since the program is still showing 6892 for (auto) first cell, and 1200 (manual tweak) for the last cell.

Second bug (maybe?), the first cell in the vobid should not instantly jump to 6892 because I lower the second cell. Shouldn't it scale with all the rest of the cells in all the rest of the vobids?

Final weirdness. As I said I tweaked the second cell in the last vobid: the first cell was still set to auto, and all other vobids were left untouched (auto) at the vob level. However, I noticed that they all increased slightly after the tweak, which is what you'd expect, except that the tweak seemed (initially) to have only affected the other cells in that specific vobid (in this case only one other cell).
Please, send me the rebuilder.inf and rebuilder.ecl so I check them. You can find my email in the readme.txt.

Anyway, it's possible it's not a bug.
If the first cell is much smaller than the second one, as you lower the second you free much space, and the first soon reach that bitrate. Probably 6892 is the bitrate in the original disk, and it will not go higher than that.
If this is the case, you will have the VobID not using the full space used before, so the bitrate is given to the other VobIDs (the program try to use always the full size of the DVD)


Is the best way just to link all the vobids in VTS2 (the movie) and then just go ahead and tweak the cells individually? That would seem simpler, but I just wanted to understand the default behaviour. If each vobid is separate, you wouldn't expect their avg bitrates to change when you tweak a cell in another vobid (in the same title of course).

If the film is spreaded around many vobids, you have to link them. It's the only way to get good results.

[raddygast]

Ah.... I see. So you are basically saying that if the vobids are NOT linked, then the program would NOT redistribute size between them unless it had to. As in this case, it had to because it couldn't raise the bitrate of the first cell high enough to maintain the same avg for the final vobid, so that leftover gets transferred to other vobids.

You are right in that the first (untweaked) cell is indeed very small. Ok, I think you explained things well enough for me to understand, but I sent you those files anyway to inspect them. Thanks for the swift response.

So should I make it an absolute habit to always link vobids within the same title?

For example say I have a main movie and extras. Should I make sure all the extras are linked together, and the main movie is linked together? But in that case if I reduce some cells in the extras, the extra space will be redistributed to the other extras (not the main movie), correct?

In that case maybe every single vobid should be linked. Is that what you had suggested? Or is it not possible to link vobids in different titlesets?

[robot1]

Originally posted by raddygast
Ah.... I see. So you are basically saying that if the vobids are NOT linked, then the program would NOT redistribute size between them unless it had to. As in this case, it had to because it couldn't raise the bitrate of the first cell high enough to maintain the same avg for the final vobid, so that leftover gets transferred to other vobids.

You are right in that the first (untweaked) cell is indeed very small. Ok, I think you explained things well enough for me to understand, but I sent you those files anyway to inspect them. Thanks for the swift response.
I've checked the files, and that's the scenario.

[quote]
So should I make it an absolute habit to always link vobids within the same title?
Yes, if you tweak cells you have to link vobids to get good results

[quote]
For example say I have a main movie and extras. Should I make sure all the extras are linked together, and the main movie is linked together? But in that case if I reduce some cells in the extras, the extra space will be redistributed to the other extras (not the main movie), correct?

In that case maybe every single vobid should be linked. Is that what you had suggested? Or is it not possible to link vobids in different titlesets? Usually you will not tweak a single cell in the extras (extras are not so long, so the gain would be small), but the entire vobid. So you don't need to link extras - but you could do it to reduce them in the same way.
If you have many extras, and you want to lower only one, giving the free space to the movie, these are the steps:
- Link the vobids of the movie
- Remove the check wo "autosized" for the extras you don't want to give the new space
- Resize the extra you want to lower the quality.
When you resize a vobid, the free space will be given to (or removed from if you're increasing) the vobid's set as "Autosized". Other will not be affected.

Hope i've explained in my bad english...

[raddygast]

Ok. Thank you very much for the explanation. Just to be sure I have it straight.

Basically, when you resize a VOBID, then the space gets redistributed among all other VOBIDs that are set to autosize. The program makes no distinction between the main (biggest) titleset and others -- I presume the DVD-RB "steal space" setting is only involved in the initial prepare phase and thus RB Opt's initial values shown for the extras.

But, when you resize a CELL within a vobid, the space gets redistributed only WITHIN that cell (unless the other cell cannot increase its bitrate enough, as you describe, then the leftover will get redistributed to other vobs). For this reason, it is best to link vobids when resizing cells.

Finally, it's best NOT to link vobids from the movie with vobids from extras, because you don't want them to affect each other. It's not important to link extra vobids because you usually don't need to do much tweaking in the extras, but if you did, and you want to keep the notion "extra" separate in your mind, then you should probably link the vobids of the extras if you want to tweak an extra cell (but only if you want the increased space to go to make the extras a bit better, not the movie).

I think I get it now.

[robot1]

Originally posted by raddygast
But, when you resize a CELL within a vobid, the space gets redistributed only WITHIN that cell
within taht vobid.
I think you have understood and that's a typo.


I think I get it now. Yes you do.

[raddygast]

Yes, it was a typo. :(

Just one more thing. You say in your method (of unchecking autosize on other extras, etc.) to link vobids of the main movie. But that's not strictly speaking necessary in that case if you don't plan to tweak cells for the main movie? It's only if you plan to tweak cells that you need to link the vobids, right? Otherwise RBOpt redistributes size evenly and in a democratic fashion to all vobids.

[robot1]

exactly, it's not striclty necessary, but it's a good practice.