-
DVDA fial size much smaller than sum of .mpg files
-
Mike,
No where did OP say where he was taking his VOB file size measurements from!
Was it from the DVD preparation [Windows] folder, or from the actual burnt DVD? The OP did not specify.
If the OP would have said he was measuring from his actual burnt DVD, then it would have been a no-brainer why he was getting smaller file size measurements. I would have given the same answer Stephen gave.
Now if the OP had taken his file size measurements from the DVD preparation [Windows] folder, than the smaller less complex DVD file structure explanation would not apply here.
See? If I were to use your earlier objections about my replies, then it would apply here as well.
Just let the OP clarify what might be his problem and what might be the correct answer and solution for it.
Cheers!
-
Wow, and I thought there would a simple explanation. So, Mike is correct, I am just curious. Thanks John for the reply, and for the details Stephen, but I’m not sure I follow. I was a software engineer on PCs for about 20 years, so I understand what you are both saying, but I don’t think I agree.
It seems to me that the files generated by DVDA are placed into the VIDEO_TS folder, and that these exact files are then burned to the DVD itself. Just take a look at your VIDEO_TS folder on your PC and then compare it to what is placed on the VIDEO_TS folder on the disc. There is no magic going on here, it’s just a set of files that the DVD player know how to decipher and play.
So, when I add up all my .mpg files, they are much greater than the sum of these, and the sum of these also includes menus that DVD creates. My DVDA project settings are using the standard template, and I am using .ac3 files. Like I said, DVDA does NOT tell me it is going to need to recompress. Maybe it still is, but it doesn’t seem so since it completes much faster than when it tells me other times that it will recompress. If DVDA is doing some sort of compression when making mpegs into VOBs, then what is the point of using templates that say there will be no recompression? I had thought that VOBS were simply split up mpeg2 streams, since you can simply place a VOB on a timeline and Vegas will say its mpeg2.
The only problem is that this changes how I decide to make my .mpg renders. I want the highest bit-rate possible. I would rather know that my total of 4GB renders will be the most optimal, and not have DVDA create smaller images. This seems to make the bit-rate calculator useless, and the DVDA estimate has historically tended to also be useless.
-Jim.
-
Jim, I don’t like using the default templates (I find the bit rate is often too low for maximum quality) so my method for authoring standard definition DVDs is as follows.
Any program that is 70 min. or less gets rendered (encoded) as an 8,000,000 CBR MPEG-2 file. Note that you will need to go into the Custom settings and modify them to get this number. I have that setting saved as a preset.
Anything longer and I use the bitrate calculator found at https://www.johncline.com/bitcalc110.zip to create a 2 pass VBR setting.
The only changes I make to it are to set the Safety margin to 5% (default is 1%) and set 1 kilobit = 1,000 bits (this is found in the supplementary menu).
I use the AC-3 default setting of 192 k.
I’ve authored in excess of 1,000 DVDs over the years and this calculator has never failed me.
There are times that DVDA will throw up a warning that I’m over the limit but I’ve learned to ignore it as DVDA has a long history of incorrectly reporting file sizes. Ignore the warning and DVDA proceeds to Prepare as expected with no further warnings.
The other thing is to use good name brand media.
My personal preference is the Watershield Taiyo-Yuden brand (looks great when printed) or Verbatim if you can’t find the TY locally. -
Jim
You can pretty much ignore the ‘advice’ John Bean is providing. It’s annoying when that happens. He probably means well, but does not know when to admit his knowledge is incorrect.
Jim, If you think about it simplistically and logically, your source files are typically captured and compressed at a bit rate much higher than what they eventually get output to on DVD (avg 8 mbps) due to mpeg2 compression. Depending on the container used, it could be anywhere from 16~31 mbps for AVCHD, 24 mbps for HDV or 8 mbps for DV for the source footage. If you were expecting to see a 1:1 relationship between captured video and output video, we would be seeing DVD’s that would be only 30 minutes or less in duration. That’s where DVD mpeg-2 compression comes in.
Another point Stephen may be making is that Windows is quite wasteful when allocating space. Your disk comprises of clusters. If you format it using NTFS and a cluster size of 16kb, that means a 1kb file will consume 16kb on disk.
Lastly, your DVD output size can vary considerably if you use PCM or AC-3 audio in DVDA. The former results in larger DVD output files.
My system specs: Intel i7 970, 12GB RAM, ASUS P6T, Vegas Pro 10e (x32/x64), Windows 7 x64 Ultimate, Vegas Production Assistant 1.0, VASST Ultimate S Pro 4.1, Neat Video Pro 2.6
-
Actually, I’m not comparing the captured video against the output video, I’m comparing the mpeg2 rendered video Vegas creates against the VOBs DVDA creates. Seems simply that DVDA does some sort of compression anyway, even if it says it isn’t. I don’t remember seeing this in version 8.
-Jim.
-
[Jim Greene] “I don’t remember seeing this in version 8.”
It was the same.
I just looked at some DVDs that I did in V8, compared them to the original AC-3/MPEG-2 files and the DVD was smaller in size. -
Could it be that DVDA recompresses the audio, even if you use the DVDA templates in Vegas? My DVDA always seems to do that, and leaves the video alone.
My system specs: Intel i7 970, 12GB RAM, ASUS P6T, Vegas Pro 10e (x32/x64), Windows 7 x64 Ultimate, Vegas Production Assistant 1.0, VASST Ultimate S Pro 4.1, Neat Video Pro 2.6
-
Jim,
After you clarified your issue, I believe the answer has to do with the conversion from the Vegas timecode to DVD Architect’s timecode.
The default Vegas timecode is “Time and Frames”. DVDa uses “Non-drop Timecode”.
So during the creation of the VOBs, DVDa does a timecode conversion.
Non-drop timecode make no adjustment to the timecode to maintain real time syncronization for NTSC video. Video frames are just playback as is. Since only whole frames can be displayed, for NTSC non-drop timecode, the actual frame rate is just a constant 30 fps instead of the NTSC standard of 29.97 fps.
This of course results in the NTSC video stream being actually played faster than it should. Thus, your video has a shorter total time and will be out-of-sync with your audio.
In comparsion, NTSC “drop timecode” does make adjustments to the timecode to maintain real time syncronization. Drop timecode causes 2 frames to be dropped from the timecode every minute except when minutes modulo 10 equals 0 (ie. 0, 10, 20, 30, …).
No actual frames are removed from the video stream in “drop timecode”. It is just timecode manipulation that results in certain frames being *skipped* (“dropped”) during playback. Those *skipped* frames are still in the video stream.
Now it appears that to maintain real time synchronization for NTSC “non-drop” timecode, DVDa actually drops frames from your video stream so that it is effectively “drop-frame” timecode.
In other words, the frames that would have been *skipped* in a NTSC “drop-frame” timecode are actually *removed* (deleted/dropped) from your video stream by DVDa.
If this explanation is correct, then this would explain why your VOB video stream is smaller in size then the original video stream you got in your MPEG coming out of Vegas.
Cheers!
-
Incredible!
Windows 7 64-bit, ASUS P6X58D, i7 960 3.20GHz, 24.0GB DDR3, 12TB connected storage
-
[John Bean] “Drop timecode causes 2 frames to be dropped from the timecode every minute except when minutes modulo 10 equals 0 (ie. 0, 10, 20, 30, …).”
This is the only statement in your post that is correct.
DVDA doesn’t care what you give it, it will author it correctly.
If you don’t believe me, try it yourself and see.
It doesn’t make any difference if you give it 29.97 DF, 29.97 NDF or true 30 fps.[John Bean] “This of course results in the NTSC video stream being actually played faster than it should. Thus, your video has a shorter total time and will be out-of-sync with your audio.”
Are you serious?
Do you have any kind of television engineering background to back up this claim?Read the following PDF from Leitch (now Harris), a recognized leader in the broadcast test & measurement industry.
https://dl.dropbox.com/u/20488019/timecode.pdf
Reply to this Discussion! Login or Sign Up