Worked example of wrong estimated size

Rain Mooder wrote on 5/21/2004, 7:30 PM
There has been some discussion about the rendered size being wildly off,
so here's an example using DVDA1. I've had the same problem with all
of the patches of DVDA1 and I suspect the same problem is in DVDA2
based on what I've heard.

This is also a tutorial on how to get DVDs all the way full by experiment.
I'm going to define the "integer megabyte" (iMB) as one million bytes.
It helps to keep everything straight as it seems like all the programs have
different ways of doing things. I usually write click on the file in explorer
and read off the size from the "bytes long" line.

Using this terminology, the average DVD-5 DVD-R will hold 4,700 imb maximum.

First off, the source material is 2:18:07 long and I'm encoding to an
elementary stream using Cinemacraft basic using 2-pass encoding
and some noise surpression.

1. I render out my audio to AC-3 and discover that it is 237 iMB.
I write this down (237 iMB).

2. I make an educated guess that I should have an elementary stream
of length 4,162 iMB.

3. I render 2-pass with the goal of making a 4162 iMB file, this takes two days.

4. The resulting file is actually 4,158 iMB. I write down (-4 iMB) on a sheet
of paper. This is what I asked for minus what I got.

5. Now I multiplex the elementary stream using TMPGenc, the resulting video
file is 4,213 iMB. I note (+55) on my paper as this is how much the file
has inflated.

6. I then open up DVDA and work up my DVD using the video and .ac3 file.
I scrupulously ignore the Optimize window as I know it's wrong.

7. I render out my DVD to a directory and I see that the total size is
4,579 iMB. I write down on a sheet this size minus the .ac3 size and
the program stream video size. This number is (+129 iMB) and it represents
minus the menu video, ifo files and other data necessary to let the DVD play.

8. Now I will calculate a new optimal size for the elementary stream:
this is the size of a DVD-5 minus everything in () and minus a safety
factor. Thus, 4700 - (129 + 55 - 4 +237) - 10 = 4,273 iMB.

9. I do my two pass render asking Cinema Craft to make a file of the size
4273 iMB. Wait a few days.

10. When I compile my DVD next the resulting size just kisses 4,700 iMB at
4,692 iMB or so.


So that's how I get my DVDs filled. I bet you were wondering what
DVDA said in the Optimize window after I said ignore it. Well, it said
cryptically, " estimate 4,803MB 100% of 4.7GB media".
I don't know how to interprete this but 4,579 iMB is certainly not
of 100% of a DVD. It's actually 97.4% which is close but I still just lost
121 iMB...

Comments

pb wrote on 5/21/2004, 10:05 PM
"3. I render 2-pass with the goal of making a 4162 iMB file, this takes two days."

Holy moley, you must have one well maintained and venerable PC, mate. I get a 2 pass in Main Concept 1.4 at about 1.7:1 = much less than two days!

The new version o Vegas is pretty good for encoding but Main Concept's offering is still faster. Maybe you should try that out to reduce your render times?

Peter
farss wrote on 5/22/2004, 5:29 AM
Could I ask why the obsession with getting the DVD 99.99% full?
I usually aim for around 95% just to have a little leeway, that way if I need to add an extra menu or whatever I don't need to re-encode.
As far as I'm aware the minor difference in bitrate that having the DVD 100% or 95% full is unnoticeble.
johnmeyer wrote on 5/22/2004, 3:07 PM
Could I ask why the obsession with getting the DVD 99.99% full?

Yes, I can tell you why. I once again, yesterday, built three different DVDs where DVD Architect 2.0's HORRIBLE estimates really hurt.

I transferred portions of twelve different videotapes into fifteen separate AVI files which I then encoded into fifteen separate MPEG2/AC-3 pairs. I wanted to put these on three DVDs, and knew from the raw file sizes that they should fit. However, as I tried various combinations, DVD Architect kept telling me that my project was 100%, 105% or 110% full. To find out if a particular combination was going to fit, I actually had to spend the time to do several trial prepares (which took about fifteen minutes each). In three cases, I stil had about 400 Mbytes free space, and in one case (where DVDA 2.0 estimated 110%) it was in fact slightly too big, but only slightly.

Let me repeat: DVDA 2.0 told me the project was too big, and in fact it was almost 10% below the maximum size.

The point is, if I had actually believed the STUPID estimates, I would have burned my project on four DVDs instead of three.

As you can tell by this post, and my previous posts on this topic, this problem really upsets me. Their lazy programming costs me real time every time I use DVDA 2.0.

I have read Sony's previous responses on this topic, but I refuse to accept their answer that such estimates cannot be done. The estimate can, in fact, be made perefectly before the burn is made, and doing so is extremely important (I can give numerous other examples of where the poor estimates are important, including making sure the encoding in Vegas is done at the maximum possible bitrate for a given video duration, in order to maximize quality).

Grrrr... Grumble, grumble ...

P.S. Sony also needs to do something about how DVDA "takes over" my computer. I am preparing a project right now as I type this message, and my 2.8 GHz computer can barely keep up with my typing. By contrast, yesterday I had three instances of Vegas running, two of which were rendering. I was able to edit and preview in the third instance with very good responsiveness. Something is terribly wrong with how DVDA uses Windows resources (DVDA 1.0c had the same problem).
farss wrote on 5/22/2004, 4:31 PM
John,
you're right, if it's out by 10% then that IS significant, I thought the issue was only a 1% error.
You're right about DVDA doing some wierd things. If I run two instances of DVDA things get very odd. Everytime one instance looses focus it would seem to go into a loop checking the source media which it may decide is offline. The instance which has focus is far from responsive as well. I do this a fair bit when making a series of DVDs that need to look the same. It's not as bad as your wrong size estimates but still frustraing. I'm certain it could be coded better.

Bob.
johnmeyer wrote on 5/22/2004, 10:08 PM
The responsiveness issue indicates a major flaw in coding, usually not adhering to basic Windows principles. Of the dozens of programs I use regularly, none exhibit this "hog the whole system" behavior.
mike_2004z wrote on 5/23/2004, 8:28 PM

I agreed !

Vegas is an excellent program - very robust and full of features.
Mean while, DVDA (1 & now 2) seem like just a quick and dirty add-on
for Vegas.

There are still many BIG BUGS and lack of need features in version 2.
Some of the bugs are in-excusable (like normal text dissappear from menu when burn to dvd).

I never, never trust DVDA (v1 & v2) file size estimate "feature" and normally just to make sure from experience how large my video file need to be + menus in order to fit on a DVD.

mike_2004z wrote on 5/23/2004, 8:29 PM
I agreed !

Vegas is an excellent program - very robust and full of features.
Mean while, DVDA (1 & now 2) seem like just a quick and dirty add-on
for Vegas.

There are still many BIG BUGS and lack of need features in version 2.
Some of the bugs are non-excusable (like normal text dissappear from menu when burn to dvd). How the hell can they missed this ???

I never, never trust DVDA (v1 & v2) file size estimate "feature" and normally just to make sure from experience how large my video file need to be + menus in order to fit on a DVD.

mike_2004z wrote on 5/23/2004, 8:34 PM

Hi,

Just want to add that if the final out put DVD is to big to fit on the disc then I just simply use DVD Shrink to shrink small percentage of the DVD. Beat the hell out of having to re-render the video and re-authoring.

Rain Mooder wrote on 5/23/2004, 10:16 PM
>>"3. I render 2-pass with the goal of making a 4162 iMB file, this takes two >>days."

>Holy moley, you must have one well maintained and venerable PC, mate. I >get a 2 pass in Main Concept 1.4 at about 1.7:1 = much less than two days!

Yeah, my noise reduction algorithm isn't easy on the processor...
I've sustained five power outages during the last render, total of
35 seconds off the grid. Thank god for the five UPSs I have running
around the house.
johnmeyer wrote on 5/24/2004, 10:40 AM
Just want to add that if the final out put DVD is to big to fit on the disc then I just simply use DVD Shrink to shrink small percentage of the DVD. Beat the hell out of having to re-render the video and re-authoring.

I have tried this, and while DVD Shrink does a remarkable job on film material, I found, even when it is only shrinking to 95% of original size, using the "deep analysis" (or whatever it is called), the artifacts on moving objects with hard diaganol edges (like fences) are really noticeable and, to me, objectionable. Perhaps the transcoding algorithm in DVD Shrink is optimized for progressive or for 24 fps.