I rendered an MPG2 in Vegas, the video file legnth is about 2hr 30...I set the bit rate at about 3.7 or so in Vegas..I used the video bit rate calculator..
After going into Architect the size of the dvd says 9.8 gig
but when I look at the actual file size through windows properties it says its about 4.5 gb..
why is it saying this larger number? will optimizing work?
I have never had this problem in Arc 3..im in 4.5a and Vegas 8
any help would be appreciated.

Peter

ignore what architect will tell you, if you know that the file you have rendered will fit, just go with it.

It is coming up with some ridiculous amount of time for the DVD to render..like 5 hours..something has to be wrong I just can't figure out what.

Peter

That just happened to me today (not the first time over the years).
remove the video (highlight the button press GULP, DELETE) then bring the mpeg back in. It won't have to rebuild the audio peaks so it'll be quick (hopefully you didn't build all the menus first) but that takes care of it, at least for me.
DVDA will usually say the file is about 10 to 20% larger than it actually is so I agree don't look at that but when it's 2X the size of the actual file when you go to prepare it it will want to re-recompress the file. Uh, NO!
You might be able to fix it by saving and closing the project then reopening it but I tried that today and it didn't work so I simply deleted the file and brought it in again and that took care of it.
Sometimes you eat the bear and sometimes the bear eats you.
Don

Yeah it didn't work. What I am trying now is to break it up into two parts and burn them on seperate DVDs..possibly I am thinking it might be the length or size that DVDA can't handle..I have no idea..but I have even re-rendered the video in Vegas and continue to get the error each time I render it..I have no idea what this is..

Peter,
so what you're saying is that even though you can see the file size in Explorer is less than...AHHHHH, wait, I think I see the probelm. I missed this before. In your first post you said that after the inital render in VEgas the file size is 4.5 gigs according to the information in the Explorer. Soory but that still too big. A 4.7 gig DVD will actually only hold 4.34 gigs of compressed video and audio-something to do with formating of the disc. So when DVDA sees the files as being that large, 4.5 gigs, regardless of the fact it says 9.whatever it's too large and DVDA is going to render the already rendered footage to make it fit on the disc. Of course a lot of waiting time and frankly the quality is going to take a big hit.
You need to render the project in Vegas to a properly small size and remember that DVDA preferred audio format is AC3 which is considerably smaller than PCM. So render the audio to that. I just did a 133 minute project at an average VBR of 4269 with AC3 audio and burned the DVDs last night-it worked fine.
So in recap, render to a smaller bitrate to fit a 4.34 gig DVD-remember the audio (AC3) OR bring it all into DVDA and let it render for you.

Don

Don is right about the size issue.
For example, I took a look at a recent project. The Status bar at the bottom of the folder says it's 3.90 GB., the Detailed view says it's 4,090,746 KB. and the Properties info (right-click - Properties) says 3.90 GB (4,188,923,904 bytes).
It's this last one that I always check for size info.
As far as a bitrate, the calculator I use says (for 2 1/2 hr. video & assuming AC-3 audio) a CBR of 3,264,000 or a VBR of 6,344,000 / 3,624,000 / 2,179,000.
There's a 5% safety margin factored into all my calculations.

Last night I tried to render it at 3000 constant bit rate, the file size says right click properties says 3.9 in vegas pops up as 9.8..

It's really a confusing issue.

Earlier in the day I had done a smaller legnth DVD about 1 hr 20 min using a video bit rate calcultor, burned fine with no issues...

I wonder if there is something I am doing correctly when rendering in Vegas 8, possibly something has been checked that shouldnt which is confusing DVDA...

What if I just render all the video footage I have in Vegas as one constant .avi and bring it in to DVDA and have it optimize, would that work?

The odd thing is it's worked the other way for every single DVD project I've done. Maybe because I was up till 5:30am rendering, over and over I burnt myself out with the issue...I need to get a fresh look today..

Peter

Just a quick note about reported file sizes:

You can get weird differences in the way space is described depending on what the purpose of the application is. For example, Hard disk drives tend to be marketed as 1 gig = 1000 megs, which makes them appear larger than they actually are. They always report unformatted sizes, which makes sense as the format of the disk is a hardware independent variable.

Also, sometimes a computer will describe how much space the file takes up on disk rather than the actual size of a file. When you save a file to a hard disk, the minimum chunk of space you can use is called a cluster. I think the default for a NTFS partition is 16k or something. That means if your file only uses 2k of the last 16k chunk it occupies on disk, the whole 16k will be unusable. On a fragmented drive this can add up if there are a lot of half used chunks. However, I strongly recommend against defragmenting, as in most circumstances in digital video, a fragmented disk as originally is probably more desirable than straight lien files.

Anyway, this related to DVD capacities as in reality I believe the actual file size is close to about 3.9 to 4.3 gig when you take into account file system overheads.

Peter,...
Are you rendering out to standard mpeg2 or or you using the DVD ARCH video stream template and a seperate ac3 audio stream? Don't know if its a bug or what that magical Architect video stream template holds, but a standard DVD mpeg 2 compliant file will always screw with architect and will always want to force a re render. At least in my experience. Use the Architect video stream template and a guarantee your problems will be gone.

This recently happen to me where the file size in explorer was 3 gig and dvda said it was 7 gig. I basically ignored it and it burned just fine. This seems to be bug in dvda if you ask me.

I render all my projects to .avi and if they are too big for a dvd when I come to DVDA, use 'fit to disk'. It chooses the bit rate and does it all for me.

When I render to mpeg2 with no audio it works fine. I simply render the audio separately as AC3. This produces files sizes more accurate to what I see in windows explorer.

I render all my projects to .avi and if they are too big for a dvd when I come to DVDA, use 'fit to disk'. It chooses the bit rate and does it all for me.

Renton, in case you didn't know, you're adding another level of codec transformation by doing this and therefore dropping your image quality, particularly on all stills and generated media (like text).
DV-AVI has a 4:1:1 colour space, stills and generated media are 4:4:4 and MPEG-2 is 4:2:0.
See Adam Wilt's site here (http://adamwilt.com/DV-FAQ-tech.html#colorSampling) and here (http://adamwilt.com/pix-sampling.html) for a good explanation of these numbers.
When you render to AVI and then to MPEG-2, you're going from 4:4:4 to 4:1:1 and then to 4:2:0.
By rendering directly to MPEG-2, you're going from directly from 4:4:4 to 4:2:0 and bypassing the intermediate codec transformation loss.

A 4.7 gig DVD will actually only hold 4.34 gigs of compressed video and audio-something to do with formating of the disc.

This is because operating systems calculate file sizes based on a binary system (powers of 2) where as storage manufacturers (hard drives, DVDs, etc) base their sizes on a power of 10 system.

So when a HD says it has 1GB of stuff, it means a number that is based on a power of 10 so that 1GB = 1,000MB = 1,000,000KB = 1,000,000,000B = 8,000,000,000bits (a bit is an individual one or zero).

But the operating system calculates numbers based on a base 2 (binary) system which is correctly indicated by "GiB." The problem was that no one in the storage industry wanted to change and no one in the OS industry wanted to change. Both industries thinking it would just confuse people. So neither changes, they both continue to use different measurement systems and both continue to call it the same thing.

I'll explain exactly how this difference matters. 1GiB = 1,024MiB = 1,048,576KiB = 1,073,741,824Bytes = 8,589,934,592bits. The difference between one GiB according to the operating system and 1GB according to a HD or DVD is 589,934,592bits aka ~70MiB or 73MB.

So if the DVD says it holds 4.7GB your operating system will actually see it as 4.377GiB, even though the operating system will say GB and not GiB.

I'll explain exactly how this difference matters.

Thanks Jason. Great (and simple) explanation!!
This one gets added to my archives for the next time someone asks "why doesn't my DVD fit?"
:-)

Renton, in case you didn't know, you're adding another level of codec transformation by doing this and therefore dropping your image quality, particularly on all stills and generated media (like text).
DV-AVI has a 4:1:1 colour space, stills and generated media are 4:4:4 and MPEG-2 is 4:2:0.
See Adam Wilt's site here (http://adamwilt.com/DV-FAQ-tech.html#colorSampling) and here (http://adamwilt.com/pix-sampling.html) for a good explanation of these numbers.
When you render to AVI and then to MPEG-2, you're going from 4:4:4 to 4:1:1 and then to 4:2:0.
By rendering directly to MPEG-2, you're going from directly from 4:4:4 to 4:2:0 and bypassing the intermediate codec transformation loss.

Now that I didn't know! I always believed that rendering to avi meant rendering uncompressed - I don't think I'm alone here. But your colour space explanation makes great sense and could explain some unexplained quality loss - especially in text. Many thanks.

Ian . . .

Thanks Jason. Great (and simple) explanation!!
This one gets added to my archives for the next time someone asks "why doesn't my DVD fit?"
:-)

I knew those CS sources would eventually come in handy. :-)

But seriously, this becomes a headache the larger storage systems get. Users need to look at a storage device and then automatically throw out 7% because of the battle in nomenclature. THEN you need to throw out another 2-5% because that will be used by the partition table to store & organize all that data. Then you throw out some more due to the unused sector issue that another poster mentioned above (though this is less of an issue with large files and more a problem for drives containing lots of files below 16KiB in size).

Pretty soon, that 300GB hard disk is actually only giving you the ability to use 270GB worth.

I always believed that rendering to avi meant rendering uncompressed - I don't think I'm alone here. But your colour space explanation makes great sense and could explain some unexplained quality loss - especially in text. Many thanks.

Glad to have been of help Ian.
DV-AVI (and HDV footage too, for that matter) is approx. 13.5 GB/hr. while uncompressed AVI is approx. 90 GB/hr.
When you think about it, a (single layer) DVD only holds 4. 3 GB so there's a whole lot of compression going on to shrink files down that much and colour information loss is one area where that happens.
Now you know why a DVD can never look as good as the original source footage.
I personally find it amazing that a DVD looks as good as it does, considering the huge amount of compression it has to go through to get there.
Life was so much easier back in the "old days" of videotape when you went from source tape(s) tape to edited master tape.
No codecs to confuse you at every step of the process :-(
BTW, it's nice to see someone else who knows how to spell "colour" correctly :-)

Pretty soon, that 300GB hard disk is actually only giving you the ability to use 270GB worth.

Windows says my 500GB. hard drives are only 465.76 GB. so you're not too far off.

Windows says my 500GB. hard drives are only 465.76 GB. so you're not too far off.

That was rough estimation after the 7% drop due to number confusion. But isn't it amazing how that starts to be a substantial drop in storage. I mean, that is almost an entire project's worth of material from a single camera wedding for me. Let alone the 11hrs of footage from my most recent wedding.