Bug in DVD-RB 1.26

[proghack]

If bitrate redist is enabled and DVD has interleaved cells, DVD-RB outputs an error during prepare phase (run-time error 53), when it does the redist. In fact it searches for a file, VI0100001001.VOB, that doesn't exist during prepare phase since it is generated by DVD-RB during encode phase.

[jdobbs]

Hmm... yep, I should have thought of that. Thanks for the report. The fact is that ILVU segments shouldn't be redistributed anyway.

[FoXMuLD3R]

Ya, here i have this problem too! with 1.26 Pro
[run-time error 53] and then, DVD-RB close!

[gurkan]

@jdobbs
Does redistribution of ilvu-discs screw up the estimated sectors?
Is it a case of having them calculated after redistribution or are there other
aspects that need to be weighed in as well, like other bitrate max-values, etc?
I know I've asked about this before here (http://forum.doom9.org/showthread.php?p=992776#post992776), but there it felt a bit OT.
Feel free to just point me in the right direction, if you've got the time.

[jdobbs]

Yes, there are several other factors. I wouldn't recommend doing a redistribution on ILVU segments. The next version of DVD-RB will not include ILVU segents. in redistribution.

[Sharc]

There seems to a 3.6% difference between the bitrates that are displayed by the segment viewer/editor and the values that are logged in the redistribution.txt file, for both columns before and after redistribution. The vlaues in the log file are 3.6% lower. Could it be somehow related to the "no encode" of the redistributed peaks which exceed the original disk bitrate?

Added:
I just noticed that this difference (3.6%) is the same value as reported under "Movie improvement from extra reduction=". May be this is not considered in the redistribution.txt

Anyway, not so important at this time.

[jdobbs]

I'll have to look at the sequence of events...

[proghack]

Hmm... yep, I should have thought of that. Thanks for the report. The fact is that ILVU segments shouldn't be redistributed anyway.

Yes, that's right. But I think redistribution algorithm should be iterative. In fact if after redistribution some segments have a bitrate higher than original, DVD-RB doesn't compress them but extracts them from VOB. And it's right. But it results in undersizing because expected bitrate (the calculated final size was based on) should have been higher. So I suggest that after bitrates have been redistribuited, the process (only calculation, very fast) should repeat excluding segments with calculated bitrate higher than original ones, until there are no more segments over their original bitrate.
If force reencode option is used all that is not needed, of course.
Is it reasonable?

[Boulder]

@jdobbs: what happens if you force encoding, does it still extract the cells proghack mentions? If it does, the extracted cells could really stand out if you do any filtering to the encoded ones.

[proghack]

@Boulder: if force reencode is enabled segments are always encoded, not extracted. In that case no undersize happens due to what I wrote before. But I don't use filters...