File size increment Make DVD

SteveH13 wrote on 8/16/2013, 4:05 PM
Hi everyone. This is my first time posting. I am trying to find an answer to this curious problem.

I am using DVD Architect to Make a DVD. The source is a 4,28Gb MPEG2 File rendered from Vegas (DVD normal parameters), with a time length of 1:32 hour. The Menu includes 14 icons made by Insert Scene Selection. When Preparing to Burn file size increases up to 4,80Gb.

My question is: Would it be increased in 300Mb because a menu? I wouldn't believe it.
Thank you everyone in advance.

Comments

PeterDuke wrote on 8/16/2013, 7:03 PM
Have you allowed for the audio? A single static menu should not use much space.

Have you tried creating the folder without burning, and checked its size? DVDA is notorious for complaining that the project is too large when it isn't.

I just checked an old DVD I made some time ago, and the misc. files totalled 1.3 MB

Did you give DVDA compliant video and audio files such that no recompression was needed?
musicvid10 wrote on 8/16/2013, 8:46 PM
"MPEG2 File rendered from Vegas (DVD normal parameters),"
Nope. You will need a DVD Architect compliant video template and DVD Architect compliant AC3 audio template. That's separate files. DVD Architect will always re-render the audio otherwise, and the file size estimate will be meaningless.
SteveH13 wrote on 8/16/2013, 11:24 PM
Thank you very much to you, PeterDuke and musicvid10 for your answer.

It was really a great experience. Finally I did what PeterDuke ask me in the last question and musicvid10 suggest, no problem, although I had to reduce the bit rate average to fit 4,7Gb disk.

You're right Peter, I have suffered the "file is too large" complaints from DVDA, but creating a new folder elsewhere, works ok, at least for me.

But it is still curious. When I render using DVDA templates, the files on folder (mpg and ac3 separated), they were almost the same size compared with render using DVD PAL, but DVDA doesn't increase file size in the first case. Interesting, isn't it?

Thank you. It was great to enter this forum.
PeterDuke wrote on 8/17/2013, 7:54 AM
Software such as DVDA is the master, you are the servant. You do what makes the software happy, or it will make you unhappy.
musicvid10 wrote on 8/17/2013, 8:33 AM
The problem is, when DVDA gets files it can't smart render, it reports the unpacked size because it has no meaningful way of predicting the finished size in advance. It would have to do a full scan in order to do that, wasting even more time.

The other problem, as Peter Duke described, is that DVDA has a habit of overestimating file sizes anyway, thus preparing the folder first and re-opening the project often reveals a folder it can burn.

BTW, a 4.7 GB disk will hold 4.35 GB (GiB) of material, no more. I use this on every project, it's not let me down yet. Requires Java.

http://www.videohelp.com/calc.htm


SteveH13 wrote on 8/18/2013, 6:48 AM
You're right Peter, but it shouldn't be this way. Softwares were made to help our projects to come true, not no transform us into techno-psychologists trying to find their problems or to subjugate them. Of course, softwares are made by humans, so errors, fixes and evolutions are understandood. But their philosophy shouldn't be this way. As you see, in musicvid10 well detailed comments, the sentences start with: The problem is or The other problem...., so in my opinion, companies have to create a closer communication with their users in order to find their problems and expectations. Thank to people like you guys, who participate and share your experiences in forums, it is possible to find solutions, that in such cases were not clarified by manufacturers.

In my case I have used DVDA and Vegas for a long time, and I consider both a very intuitive a good softwares to do the video job, but sometimes curious cases or behaviours make us unhappy as Peter said.

musicvid10 described a process of overestimation in DVDA, and then describe a solution, which is great, but my question here is: How much time do I spent looking for an answer?

The other issue about maximum capacity on disks. As musicvid10 well said 4,7Gb is actually 4,35Gb, the difference supposed to be what disk store as additional information to identify formats, but if this happen all the time, why disk manufacturers doesn't change data to 4,30Gb?

Thank you musicvid10 for your link, its a a very usefull tool, I knew it, but had some issues with my browsers (may be my Java, I don't know) and then I downloaded and installed the Mark's DVD Bitrate Calculator, I am sure you both know it. It works great for me... so far.

Thank you very much for your replies.
musicvid10 wrote on 8/18/2013, 10:05 AM
Steve,

I'm sorry to have to say this, because I believe you are sincere, but your last questions sound a bit innocent.

-- but my question here is: How much time do I spent looking for an answer?
An estimate is an estimate. A more accurate estimate would entail at the minimum a preemptive full scan pass, which could take an hour or perhaps 'way more. Most people wouldn't want that.
A less conservative "quick" estimate would result in failed burns. The severity of the complaints from even a few of those would be a nightmare for Sony. Thus the estimate is padded, or simply not calculated completely if Architect does not see compliant source it expects. A bitrate calculator and the "Prepare first" workaround are the best we have for now, unless you're one monster of a coder!

--[i]but if this happen all the time, why disk manufacturers doesn't change data to 4,30Gb?[i]
Let me answer your question with a question: Why do television manufacturers deliberately mislead by advertising larger screens than their actual horizontal measurement?
Fact: Drive/Storage manufacturers use 1GB = 10^9 Bytes, while most of the rest of the world (including Apple), use 1GB (GiB) = 2^30 Bytes, which is a smaller number. It's a sales trick.

Best of luck with your project.