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

DV Info Net (https://www.dvinfo.net/forum/)

- What Happens in Vegas... (https://www.dvinfo.net/forum/what-happens-vegas/)

- - dvd-a 1h40mins won't fit on dvd?! (https://www.dvinfo.net/forum/what-happens-vegas/129783-dvd-1h40mins-wont-fit-dvd.html)

Hi all,

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

Quote:

Originally Posted by Mike Gunter (Post 933839)

Hi all,

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

^^ That's the one! ;)

Quote:

Originally Posted by Mike Kujbida (Post 933820)

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.

Quote:

Originally Posted by Kevin Richard (Post 933840)

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

Quote:

Originally Posted by Kevin Richard (Post 933829)

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.

Quote:

Originally Posted by Jason Robinson (Post 933882)

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.

Quote:

Originally Posted by Kevin Richard (Post 933975)

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

Quote:

Originally Posted by Jason Robinson (Post 933993)

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