View Full Version : MPV + AC3 to DVD: file size too big!
wiseant
18th May 2007, 23:35
Hi everyone - this is my first post - so please let me know if I made any errors in protocol.
I have a DVD compliant .mpv file 720x480 NTSC 29.970 fps
file size is 3785 MB (approx 105 minutes at 5000 kbps)
and .ac3 48 kHz audio file: file size is 290 MB
Combined file size = 4075 MB
So I figured no problem putting this onto a DVD, so I tried
DVDAuthorGUI, then Muxman, then IFOEdit and all of them increased the file size to approx 4749 MB (4.63 GB) which obviously is too big. Where does this extra 674 MB come from?
My guess is that something is happening in the muxing process that "artificially" increased the bitrate for the video to somewhere around 10,000 kbps. I say "virtual increase" because if this was an actual increase in bit rate the video file size would be in excess of 7570 MB
So, is there anyway that I can tell any of these applications to keep the real bitrate setting so my file size is correct?
Or is there another application I should use (I prefer to use open-source or freeware)
Thank you
Welcome, wiseant!
The extra file size is probably due to the nav packs, which are necessary. You cannot remove them. Anyway, the bitrate of the video stream is not modified by the muxers.
I suggest you use DVDShrink on the muxed DVD to shrink the video a little bit. Since 674MB is not much, you will certainly not notice the quality loss.
wiseant
19th May 2007, 00:51
Hi rOIZ
As they say "Great minds think alike and fools seldom differ"
Just before I read your reply I downloaded DVDShrink - it's running right now on my other computer . . .
However my biggest concern is how I can change the "target rate specified" to a lower value in the hopes that 4075 MB of files do not increase to more than the max DVD size? Nero indicates that the DVD capacity is 4483 MB
You mean with the encoder, or with DVDShrink?
In DVDShrink, you should leave the DVD capacity as it is. It's a reasonable default.
For an encoder, I don't know hot to evaluate the size occupied by the nav packs, but I suppose that your current DVD is a good example, and that you can subtract approximately the same size the next time, plus some MBs by security. Anyway, it is not a good idea to write near the outer edge of the DVD.
wiseant
19th May 2007, 02:24
Thanks rOIZ
I meant with the encoder - as you suggested I will have to reduce the bitrate because of the space taken by the nav packs - And, is it not a good idea to write near the outer edge of the DVD because this is mostly where damage would occur?
blutach
19th May 2007, 03:06
Consider using DVD Rebuilder (http://dvd-rb.dvd2go.org/) to re-encode. HCEnc on best mode is a wonderful choice which does not take much time to re-encode (it will be slower than DVD Shrink, however).
Regards
And, is it not a good idea to write near the outer edge of the DVD because this is mostly where damage would occur?Yes, and even without damage, the outer edge is usually less good.
Also, if you use DVD-R/RWs, you cannot be sure that the capacity of the media is always the same. (No problem with +Rs)
wiseant
19th May 2007, 20:46
Thanks blutach - I will take a look at DVD Rebuilder
Thanks r0lZ - I have been using DVD RWs for testing - I'll have to try some DVD+Rs . . .
wiseant
20th May 2007, 19:44
I didn't want to start a new thread - but I did want to add the following:
After doing some tests I realized that the large overhead (over 16%) that DVDAuthorGUI, Muxman and IFOEdit added to the final file size was because the mpeg2 (.mpv) clip I had was all I frames. When I did another capture with I, P and B frames the overhead was about 1.2% - which definitely makes a difference in terms of maximizing the bitrate for captures up to two hours in duration.
Only I frames! Obviously, it's not the best way to compress the video! I suppose that a nav pack is added before each I frame. Since each nav pack consumes 2KB, it's a lot of wasted space.
Thanks for the info.
mpucoder
21st May 2007, 06:28
There will not be a significant difference in the number of NAV packs, the minimum VOBU duration (400ms) will be maintained. But each GOP, which, in this case, contains just one frame, must start in a new pack with a PES header. So there will be a lot of padding (average 1K per frame) and PES headers
Thanks for the precision, mpucoder!
wiseant
21st May 2007, 20:14
Thanks mpucoder and r0lZ - I appreciate the feedback
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.