Incorrect VTS filesize

[Camino]

I've recently notice, that when I reopen a project with; DRM (Pro 3.1.3)displays a wrong filesize value for some VTS files. And to be precies; only those VTS files where I did removed or disable some audiotracks. It seems that DRM shows back the sizevalue of the original VTS. So... checking the audiotracks of that VTS title give me the confirmation that they are removed/disable. Only DRM doesn't show the correct size anymore. Strange as it may sound, DRM displays the correct value after exporting this project. Any chance to correct this ?

[toaddub]

Not the same scenario, but another situation also causes incorrect file size. This happens after doing some splits and substitute blocks. I'm expecting the size to reduce for these successive operations, and the PGC 1 size is the same as Program Chains size in this case. Also, note that the sum of Program Chains size and Menus size is not exactly the same as VTS 1 size, but close enough.

[DimadSoft]

@camino, toaddub: Can you make a small sample disks that expose described problem (just by deleting non relevant parts of the disk where you see the problem)? It will help us a lot if we will have a sample to look at.

[toaddub]

Files are on your way. Check your email.

[Camino]

You're wish is my command... Check your mailbox.

[DimadSoft]

Thanks for files guys. @camino: It is not really a bug. Reported size difference is due to the fact that streams sizes are not exactly known when disk is imported. They are not known either when you import previously edited and exported disk, but in this case there are less streams and DRM can make a better estimate of the streams size. If you do "find exact stream sizes" you should see right sizes in DVD tree (for the VTS where you search for streams). DvdTree is not updated on "search ...", so don't forget to edit something and undo to see new size. @toaddub: Yeap, it is a bug. Reused cells are counted more then once. Will be fixed in next release.

[toaddub]

Glad to hear. I'll be confirming with the fix.

[pak2]

OK, I’ll toss in another situation where it gives weird size estimates. If you have not done a “find exact stream sizes”, either of the following sequences can produce large errors in estimated sizes if multiple audio tracks are disabled. 1) Perform “cut to here” operations that chop off 10 or more VOBUs from the front of blocks –-> as expected, the block sizes decrease by the amount cut. But this operation causes the audio stream size(s) to set to zero without subtracting from the block size. After that, disabling those audio tracks doesn’t reduce estimated block sizes (subtracting zeros). The net result is the block size estimates are too large because disabled audio is not subtracted from the estimates. 2) Different sequence, same result. Disable audio tracks first, and the block size estimates will reduce accordingly. Then, if you chop 10 or more VOBUs from blocks with “cut to here”, the estimated block sizes will increase (the size of disabled audio for the entire block is added back into the estimate when you chop off the first 10 VOBU), Performing a “find exact stream sizes” after either of the above sequences doesn’t correct the estimates. (Note that performing a “find exact stream sizes” before anything else will give correct size estimates during editing.) Paul

[CDR-Zone.COM]