Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Counting gigs ...

M

Mark L. Pederson

REDuser Sponsor
Joined
Dec 28, 2006
Messages
7,145
Reaction score
1
Points
0
Age
59
Website
www.offhollywoodny.com
Just an FYI here - we had a red flag this week when our on set data reports on one of our feature films did not matching up to our lab reports with respect to file sizes.

Pliny, who runs our post, sent me the following explanation - I thought I would would share it just in case anyone else here encounters the discrepancy.

Very briefly, every computer system since the dawn of time has counted a "kilobyte" as being 1,024 bytes, not 1,000 bytes. It's a powers-of-two thing. Consequently a megabyte is 1,024 squared, and a gigabyte is 1,024 cubed.

Along comes Apple's latest OS, OSX Snow Leopard, and decides to start counting kilobytes as 1,000 bytes, megabytes as 1,000 squared, and so on.

Hence the counting discrepancies between Eric's laptop (running Snow Leopard) and our lab (not running Snow Leopard). These discrepancies get bigger as you go from kilo- to mega- to giga. It's close to a 7% difference when counting gigs.

Blame this on Steve Jobs.

Regards,
Pliny
 
I also noticed this when we did a side by side M vs. MX test and sync rolled the camera's. The M-X seemed to be recording less data than the M sensor.

Strange....


David
 
David Battistella said:
I also noticed this when we did a side by side M vs. MX test and sync rolled the camera's. The M-X seemed to be recording less data than the M sensor.

Strange....
Click to expand...

Not that strange. There is compression in redcode. All other things being equal, a cleaner image will yield a smaller data stream.
 
Yeah, I came across this months ago when I was doing some LTO back ups after upgrading one of our systems to Snow Leopard. It's an absolute PIA, it's just one of the reasons I have not upgraded our database and Final Cut Server host computer to Snow Leopard.
 
Ouch:
Known issues: QuickLook does not work at all, pressing space does nothing. QuickTime and file previews in Tree View have issues, a thumbnail will be displayed but you must try scrolling in order to get the play button to appear. Even though the Finder works correctly in 64-bit kernel mode, Leopard's Finder is still 32-bit and is shown in Activity Monitor as such. There may be a way to use Leopard's QuickLook in Snow Leopard to workaround this problem but I have not attempted this yet myself. Any Mac OS X updates with changes to the Finder will overwrite this modification or possibly crash your system. Let's hope when Apple updates the Finder, they fix it to properly use base 2 or give us an option.
* A new issue has been reported, Spotlight will crash the Finder if used in a Finder window. It may still be used by clicking the Spotlight icon in the top menu bar. I do not know of a workaround at this time but I still think it is worth it to have base 2.
Click to expand...
 
Hey, didn't say it was perfect ;-)
 
Martin Weiss said:
It's one of those things where Apple is right in principle, but in real life it just makes everyone's life harder. (Like when they disbanded the disk drives and one had to burn a CD to just to move a 50kb file around.)
Click to expand...

I don't know if I'd agree that Apple is totally right about this. And they are not consistent across the entire OS, which also causes issues. Apple has only implemented the change in relation to attached storage values. Memory sizes / RAM, and certain other capacity values remain as binary 2^X values.

It would be nice if we could set our systems to display capacities as we see fit. All this mainly stemmed from hard drive makers over the years using even base-10 value representation for their HDD capacities, thus causing confusion in the market. So the movement over the past several years has been to get the computer industry to adopt "proper" nomenclature for capacities. Thus meaning that "kilobytes" (KB) should be 1000 bytes and not 1024, for example. And for representing a binary base value of 1024 bytes, to use the "kibibyte" or KiB. It was proposed by the IEC back in '98, approved in '99. And adopted by ANSI and the IEEE in either 2000 or 2001. So the naming has been a recognized standard for like a decade now.

The problem I have with all this, is not the change in the standard, but that hardly anyone is adopting it and we are now seeing an annoying mixture within the industry. this new nomenclature is just that, new. And now on our Mac systems our KB's are no longer 1024 bytes, MB are no longer 1048576 bytes, etc.. Which is fine, but it's annoying in mixed environments. At least on the Linux boxes it's easy to adopt whichever standard we want...

IMO, Apple should have changed the labeling across the entire OS to "ibi" standard so when I look at a 1TB HDD, I see 931.6GiB instead of "999.86GB". Because 999.86 for a 1TB HDD makes my brain slip a gear and I feel more at home with the 931.6, even if it says GiB after it.
 
You must log in or register to reply here.
Back
Top