I'm using the default dvd-a templates for compression and yet my project that is 1hour and 40mins won't fit on a standard dvd.. it's sitting at like 118%. Great! Why doesn't 2 hours fit on there like it should!?

Because the default template is set up for about 90 minutes. When rendering the MPEG2 file, you need to lower the bitrate to the proper level for 100 minutes. There are several bitrate calculators available and I have a bitrate chart in Vol 1 #7 of my newsletters (http://www.jetdv.com).

Unlinke audio CDs which have a fixed bit rate, most DVDs are produced with a variable bit rate. The more action or movement you have the more bits per second you need so your videos must be shorter. I would suggest the 120 minutes you may see on a DVD label is a very rough guide.

Ian

The DVDs should also say 4.37 Gig but they all say 4.7. I haven't particularly noticed that they say 120 minute since you can also put more or less than that. 120 minutes is NOT a max - you can do more if you lower the bitrate farther!

Kevin, the bottom line in all of this is that, over the years and versions, Sony keeps changing the default MPEG-2 encoding rates.
Therefore, It's always a good idea to check and see what the default rate currently is and tweak it if necessary.
I personally never use the default settings and have created a number of custom templates for various program lengths and styles.
FOr example, a 2 hr. talking head has a different setting than a 2 hr. stage play.

I got it... I just assumed it was set up to try and ball park a 2 hour program that is where my confusion arose. I didn't feel like crunching the numbers and rerendering everything again for half a day so I just let dvd-a do it. Not the best but it's done.

I just wanted to understand why the template created a file larger than I expected (not the technical part as I understand variable bitrates, but the rationale... the why).

I guess that is the issue that was out of hand here... I understood WHAT was happening I was just asking WHY was it that way.

*Thanks Chris for cleaning up this mess, it needed it!

I just wanted to understand why the template created a file larger than I expected ...

Did it actually create a file larger than expected or did DVDA tell you that the file was going to be a certain size?
If it's the latter, DVDA has a well-known problem (since it's inception!!) for incorrectly calculating file sizes.
If I've done a render from Vegas and I know that my MPEG-2 and AC-3 files do not exceed the 4.3 GB. limit, I ignore the warning.
DVDA then goes ahead and creates the DVD without any furrther problems.

Hmm, I'll have to double check.

What I meant was that I assumed 100 mins was going to fit without a problem using the template (I never checked the bitrate or did the math).

I want to say dvd-a was saying it was 5.3gigs in the corner... not exactly sure of the file sizes... I'll have to check when I get back home... I think it was 4.7 if I'm not mistaken and I just assumed with menu's and what not dvd-a wasn't far off but it was still over.

I just wanted to understand why the template created a file larger than I expected (not the technical part as I understand variable bitrates, but the rationale... the why).

I guess that is the issue that was out of hand here... I understood WHAT was happening I was just asking WHY was it that way.

As far as the templates are concerned, Sony couldn't just leave the bitrate blank, so they had to plug in some arbitrary numbers.

Calculating bitrates and authoring DVDs isn't rocket science, but it is computer science. You claim that you understand bitrates, but you clearly didn't in this case. You're blaming Sony for not defaulting to bitrates that conformed to your specific requirements for this particular project. You didn't check the bitrate or do the math and you started this thread to complain about it? Like I said earlier, your problem was 100% operator error. I custom calculate the bitrates for every project that I do to maximize the quality for a given program length and disc size, you should, too.

As far as the templates are concerned, Sony couldn't just leave the bitrate blank, so they had to plug in some arbitrary numbers.

Calculating bitrates and authoring DVDs isn't rocket science, but it is computer science. You claim that you understand bitrates, but you clearly didn't in this case. You're blaming Sony for not defaulting to bitrates that conformed to your specific requirements for this particular project. You didn't check the bitrate or do the math and you started this thread to complain about it? Like I said earlier, your problem was 100% operator error. I custom calculate the bitrates for every project that I do to maximize the quality for a given program length and disc size, you should, too.

Wow, dude, seeing your comments deleted by the admin wasn't enough huh?

You CLEARLY didn't understand the question and purpose of my post so why would you continue to keep flaming?

Hmm, I'll have to double check.
What I meant was that I assumed 100 mins was going to fit without a problem using the template (I never checked the bitrate or did the math).
I want to say dvd-a was saying it was 5.3gigs in the corner... not exactly sure of the file sizes... I'll have to check when I get back home... I think it was 4.7 if I'm not mistaken and I just assumed with menu's and what not dvd-a wasn't far off but it was still over.

This is the classic but little understood problem of 4.7GB vs 4.3GiB. Storage manufacturers (hard drives, optical discs, and tapes) all use a system of calculations based on base 10 math. That means 1GB is 1000MB, 1MB is 1000KB, 1KB is 1000B, and 1B = Byte is 8 bits (or individual ones or zeros).

So 4.7GB is "worth" 37,600,000,000 individual ones and zeros.

The problem is that operating systems, programs, RAM memory, graphics cards, & CPUs all function in the binary base 2 math world. This means that 1GB is 1024MB, 1MB is 1024KB, 1KB is 1024B, and 1B is 8 bits.

If the DVD was actually based on GiB and base two math, it would be able to store 41,341,637,204,378 individual ones and zeros. That means that 4.7GiB is much bigger than 4.7GB.

The storage makers and the operating system people have been fighting over what the term "GB" should refer to. Does it mean the binary base 2 math version or base 10 version? Storage makers want to pretend their drives are bigger by using the base 10 version. Unfortunately, the term is most often used and remembered when talking about storage space and so they won the PR war and now GB refers to the base 10 math version. So GiB is the correct term for the binary version.

So that 37,600,000,000 bit DVD disc (4.7GB) will store 4.377GiB of data (divide the base 10 number by 8 to get bits, divide by 1024 to get KiB, by 1024 to get MiB, and by 1024 again to get GiB).

The binary version (the one ending in "iB") is the one Sony DVDA will refer to when it says the bit rate is X, or when your bit rate calculator says the file size will be Y .... BUT the optical disc that says it is 4.7GB is actually only 4.3 GiB to your encoder and bitrate calculator.

Program length - 2 hr. 8 min.
Render format:
AC-3 audio: (192 Kbps, 48,000 Hz, Stereo)
MPEG-2 video: (4:3) customized DVD Architect NTSC video stream.

All renders were single-pass VBR.

The bitrate calculator used was Mark's DVD Bitrate Calculator (http://www.johncline.com/bitcalc110.zip) (note: this links to a zipped file) version 1.10 with the Safety Margin at 1%, 3% and 5%.
Fixed menus was set to 1.
1 kilobit = 1024 bits was selected.

All render numbers were rounded down (for example, 2,680,000 becomes 2,600,000).

Here are the VBR settings (Max, Avg, Min) and resulting file sizes (according to the "Detailed View" in My Computer - more on this in a moment):

AC-3: 179,063 KB

MPEG-2 (1%): 4,195,478 KB
VBR:
7,800,000
4,400,000
2,600,000

MPEG-2 (3%): 4,101,242 KB
VBR:
7,600,000
4,300,000
2,600,000

MPEG-2 (5%): 4,006,802 KB
VBR:
7,500,000
4,200,000
2,500,000

According to these numbers, a 1% safety margin would put it over the allowable 4.3 GB limit but you think you'd be OK with the 3% and 5% margins.

However, here's where my discrepancy comes in.
When you right-click on the files and select "Properties", you get 2 different set of numbers ("Size" and "Size on disk" as shown here:

AC-3:
Size: 174 MB (183,360,000 bytes)
Size on disk: 174 MB (183,361,536 bytes)

MPEG-2 (1%):
Size: 4.00 GB (4,296,169,472 bytes)
Size on disk: 4.00 GB (4,296,171,520 bytes)

MPEG-2 (3%):
Size: 4.08 GB (4,383,031,808 bytes)
Size on disk: 4.08 GB (4,383,035,392 bytes)

MPEG-2 (5%):
Size: 3.82 GB (4,102,965,248 bytes)
Size on disk: 3.82 GB (4,102,967,296 bytes)

And, so you don't have to do the math, here they are combined (what you need to figure out if it's OK for DVD Architect):

Combined AC-3 + MPEG-2 (1%):
Size: 4.17 GB (4,479,529,472 bytes)
Size on disk: 4.17 GB (4,479,533,056 bytes)

Combined AC-3 + MPEG-2 (3%):
Size: 4.17 GB (4,479,529,472 bytes)
Size on disk: 4.17 GB (4,479,533,056 bytes)

Combined AC-3 + MPEG-2 (5%):
Size: 3.99 GB (4,286,325,248 bytes)
Size on disk: 3.99 GB (4,286,328,832 bytes)

As you can see, only the 5% Safety margin would be OK for DVD Architect.

My question for the computer gurus amongst you is "can we trust the first set of numbers or do we use the last set?"
Call me anal but I always use the latter set of numbers (right-click - Properties) as they're the largest.
Unless I completely mess up my authoring procedure (it's been known to happen!!) DVD Architect never tells me it has to re-render anything.

I hope this helps some folks and promotes further discussions on this issue.

My question for the computer gurus amongst you is "can we trust the first set of numbers or do we use the last set?"
Call me anal but I always use the latter set of numbers (right-click - Properties) as they're the largest.
Unless I completely mess up my authoring procedure (it's been known to happen!!) DVD Architect never tells me it has to re-render anything.

I hope this helps some folks and promotes further discussions on this issue.

Being a computer nerd by trade I can answer this... the latter number is how much it uses on the hard drive because of partion formatting. This will vary based on which partition you store the files on fat32, fat16, NTFS, EXT3, RiserFS and on and on. Basically a partition table allocates X sectors for a file to be stored in and if it uses X and .0001 to store the file then it uses 2X sectors and then it takes up the whole 2X "on disk" to store the file that was barely over 1X. Does that make sense?

So as to which number you can use, honestly the latter number is kind of irrelavant to a DVD as it stores files different also.

Did that help? If not let me know and I'll try a different approach to explaining this.

*to add a little more to it... this is another reason back in the day they partition drives smaller than just using the full drive... fat allocates it's clusters based on overall partition size... the smaller your partition the less "waste" you would have with small files. To futher make things fun, with Linux you can choose what you want your cluster size to be EXT3 is 4k by default for example... So even a single character file will take up 4k, ?luckily most of our files these days are large?

I recently came across an Adobe paper that suggested the formula 560/minutes to find video bitrate and it seems to work pretty well.

You might take the result and just round down a bit to be safe, for instance 560/120=4.666, just encode at 4500 CBR and use Dolby audio and you'll know it will fit, has not failed me.

Jeff Pulera
Safe Harbor Computers

I recently came across an Adobe paper that suggested the formula 560/minutes to find video bitrate and it seems to work pretty well.

You might take the result and just round down a bit to be safe, for instance 560/120=4.666, just encode at 4500 CBR and use Dolby audio and you'll know it will fit, has not failed me.

Jeff Pulera
Safe Harbor Computers

As mentioned there are a ton of bitrate calcs online to help you figure out the values... videohelp.com or something like that has some I think.... one of those sites that are mainly about divx encoding type of stuff but still the calcs are good.

Hi all,

FWIW, a good bit rate calculator is also available at Bitrate Calculator (http://www.videohelp.com/calc.htm).

Hi all,

FWIW, a good bit rate calculator is also available at Bitrate Calculator (http://www.videohelp.com/calc.htm).

^^ That's the one! ;)

As you can see, only the 5% Safety margin would be OK for DVD Architect.

My question for the computer gurus amongst you is "can we trust the first set of numbers or do we use the last set?"
Call me anal but I always use the latter set of numbers (right-click - Properties) as they're the largest.
Unless I completely mess up my authoring procedure (it's been known to happen!!) DVD Architect never tells me it has to re-render anything.

I hope this helps some folks and promotes further discussions on this issue.

The reason that is the only potentially safe option is because your bit rates are calculated in binary based math (powers of 2) which is "larger" than the file sizes available for storage (on disc) which uses base 10 math (powers of 10). There is a roughly 7% difference between the two number systems (6.8677%).

The other poster also brings up a good point regarding disc sectors. Think of it like a phone book that has a fixed number of possible pages and each page can reference "X" number of businesses depending on how much space they want to dedicate to each entry. So the book page can either have space for 10, 20, 30, etc entries per page. If you want to store 100 numbers (analogous to data bits) and the pages are set up to store 30 entries per page, then it will require 4 pages even though the last page will not be completely used.

There also is something called FAT (file allocation table) which all disc partitions & storage mechanisms (even DVDs & CDs) have. This is the lookup table that stores the actual location of all the data. The larger the storage device (like a 500GB disc) the more space is required to set aside for the FAT. This is true if using the NTFS, the old school FAT16 or FAT32, Reiser, or ext3 file systems. Different file systems have different requirements for hte size of the FAT because they address storage differently.

^^ That's the one! ;)

This one is very handy also because it allows the use of both binary math (Operating systems) and base 10 math (hard disc storage & DVD storage).

Being a computer nerd by trade I can answer this... the latter number is how much it uses on the hard drive because of partion formatting. This will vary based on which partition you store the files on fat32, fat16, NTFS, EXT3, RiserFS and on and on. Basically a partition table allocates X sectors for a file to be stored in and if it uses X and .0001 to store the file then it uses 2X sectors and then it takes up the whole 2X "on disk" to store the file that was barely over 1X. Does that make sense?

So as to which number you can use, honestly the latter number is kind of irrelavant to a DVD as it stores files different also.

Did that help? If not let me know and I'll try a different approach to explaining this.

*to add a little more to it... this is another reason back in the day they partition drives smaller than just using the full drive... fat allocates it's clusters based on overall partition size... the smaller your partition the less "waste" you would have with small files. To futher make things fun, with Linux you can choose what you want your cluster size to be EXT3 is 4k by default for example... So even a single character file will take up 4k, ?luckily most of our files these days are large?

I believe even NTFS allows custom block sizes for partitioning, but I may be thinking of my RAID controller which has custom block sizes.

I believe even NTFS allows custom block sizes for partitioning, but I may be thinking of my RAID controller which has custom block sizes.

You may very well be right... I just let NTFS do it's thing mostly... linux is where I get more hands on as it's usually when I'm setting up raids and doing servers and such where there are different needs for different server types.

You may very well be right... I just let NTFS do it's thing mostly... linux is where I get more hands on as it's usually when I'm setting up raids and doing servers and such where there are different needs for different server types.

I just checked and NTS does allow it (at least using WinXP Pro as the host OS) but it calls the block size "Allocation Unit Size."

And I agree that it usually isn't worth messing with. Very rarely does it make sense to change the default block size (unless you are dealign with lots and lots of tiny source code files, then it might be handy to bump the block size down a bit).

I just checked and NTS does allow it (at least using WinXP Pro as the host OS) but it calls the block size "Allocation Unit Size."

And I agree that it usually isn't worth messing with. Very rarely does it make sense to change the default block size (unless you are dealign with lots and lots of tiny source code files, then it might be handy to bump the block size down a bit).

Or if you deal with something that has a LOT of files that are EXACTLY X bytes long.