dvd-a 1h40mins won't fit on dvd?!

[Mike Gunter]

Hi all,

FWIW, a good bit rate calculator is also available at Bitrate Calculator.

[Kevin Richard]

Originally Posted by Mike Gunter

Hi all,

FWIW, a good bit rate calculator is also available at Bitrate Calculator.

^^ That's the one! ;)

[Jason Robinson]

Originally Posted by Mike Kujbida

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.

[Jason Robinson]

Originally Posted by Kevin Richard

^^ 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).

[Jason Robinson]

Originally Posted by Kevin Richard

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.

[Kevin Richard]

Originally Posted by Jason Robinson

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.

[Jason Robinson]

Originally Posted by Kevin Richard

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).

[Kevin Richard]

Originally Posted by Jason Robinson

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.