Why don't numbers work properly?

[S. Campbell]

I have an SD card for my RK2020 retro handheld, onto which I want to burn a pre-made image of emulators.

SOUNDS SIMPLE, RIGHT?

- the micro SD card (a Toshiba bought from a legit UK online source) is ostensibly a 128GB one.

- the IMG file I've downloaded is 119GB according to Windows.



- except the image-writer app (BalenaEtcher) thinks the IMG is 128GB and that the card capacity is only 125GB, so refuses to write it.





- and if I try to format the card, Windows says its actual capacity is only 116GB.



WHY ARE NONE OF THESE NUMBERS THE SAME AND HOW DO I FIX IT?

[jotd]

Balena Etcher is bloated crap. I'm using win32 disk imager. It's small, free and it works.

[S. Campbell]

Originally Posted by jotd

Balena Etcher is bloated crap. I'm using win32 disk imager. It's small, free and it works.

Win32 Disk Imager also complains that it doesn't have enough sectors (it claims to need something like 249,000 but only has 245,000). It's currently trying to write it anyway but I'm not hopeful.

("119GB" is actually 128,000Mb, so if I could get the card to format to 119 rather than 116 I think I'd be fine.)

[Titler]

I'm afraid your drive is reading it's true, correct size. But it's because there's a loophole in the law in how "Giga" is defined.

In normal mathematics, which uses a base 10 system, a Byte is 1000.
But in computer Bytes, which is counting in 8s, it's 1024.

It wasn't a too noticeable difference back when the values of computer storage were smaller, but the larger storage has gotten that 24 number difference has added up, so a card now with 128GB only has 115GB or so in computer terms on it... and vendors are allowed to sell under the mathematical label, as long as they say somewhere in small print what the real value the computer will read is.

I did a quick google, and found someone else who lists that a Toshiba 128gb does indeed come out at 115.2gb in computer terms.

But the important thing is, a file that is 119gb is never going to fit, so the way forward is either to buy a larger sized SD card... or look at the file and see if you can shrink it further, and read it with the emulator in a compressed/zipped state.

[amiman99]

I had the issue with few image files, always too small.

Most of the time the files in the image don't fill out the whole space on disk, so you could write it into bigger card, plug in Linux, resize the partition, image it again.

[S. Campbell]

Originally Posted by Titler

But the important thing is, a file that is 119gb is never going to fit, so the way forward is either to buy a larger sized SD card... or look at the file and see if you can shrink it further, and read it with the emulator in a compressed/zipped state.

In fact Win32 Disk Imager does indeed seem to have written it, despite its own "not enough sectors" warning. Everything works so far.

[rare_j]

It'll work until it tries to read the data for the files that were at the end of the image, if there were any. It might have been empty space at the end.
Dude you need to sort out that misbehaving caps lock key.

[Foebane]

Originally Posted by Titler

In normal mathematics, which uses a base 10 system, a Byte is 1000.
But in computer Bytes, which is counting in 8s, it's 1024.

This is EXACTLY the problem, and the cause of so much f-ing confusion.

A digital computer is base 2, binary, ALWAYS, and so the correct term, or the one I used back then was ALWAYS 1024, it was simplicity itself.

But then ignorant people came along, years later, whined about WHY does it have to have the extra 24, because they cannot possibly fathom counting systems that use more or less than the fingers and thumbs on their hands (probably mathematically illiterate too) and yet counting systems are in use that are base 8 and base 16 as well. The base used doesn't matter (you could use base 27 if you wanted to) as long as the value is correct, and it is NOT for the first example quoted above for a digital base 2 system.

This is the reason for the confusion, I believe. They even have two different names for the bases quoted, but I will stick with what I know from the past.

[Jope]

Originally Posted by amiman99

I had the issue with few image files, always too small.

Most of the time the files in the image don't fill out the whole space on disk, so you could write it into bigger card, plug in Linux, resize the partition, image it again.

If you're using linux, why not just mount the image via a loop device and copy the files out to a new card instead of wasting time writing it and reading it back in..

[britelite]

Originally Posted by Foebane

A digital computer is base 2, binary, ALWAYS, and so the correct term, or the one I used back then was ALWAYS 1024, it was simplicity itself.

Then you shouldn't use previously defined prefixes like kilo, mega and so on

But then ignorant people came along, years later

And by ignorant you mean people who tried to redefine well established prefixes?

[Daedalus]

Indeed, instead of being a legal loophole, computer size definitions have always been the anomaly when compared to SI prefixes in use for centuries. When this started to become a significant problem (around the time when hard drive sizes moved into the GB range), a new standard was established based on binary for use with computer storage sizes. This is KiB, MiB, GiB, TiB etc. system (Kibibyte, Mebibyte, Gibibyte, Tebibyte), and has been around for over two decades IIRC, enough time that people should be used to it by now

But old habits die hard, and most people (including myself) still use the old system in casual settings. But whenever there is scope for confusion, it's a good idea to be clear about the intended meaning.

[Foebane]

Originally Posted by britelite

Then you shouldn't use previously defined prefixes like kilo, mega and so on

And by ignorant you mean people who tried to redefine well established prefixes?

Well, yes.

[jotd]

as I said don't use balena etcher crap glad you sorted that out.

I'm using Win32 disk imager (also: open source) for years successfully, to read & write back SD cards for Raspberry Pi (that have a tendency to rot just before I need them urgently for my retrogaming events!!) and also for CF cards.

there aren't that much tools like that actually, and that WORK. A bit like .cue image burners. Only ImgBurn works.

[jPV]

Originally Posted by Foebane

But then ignorant people came along

Wasn't it more like money hungry harddisk manufacturers who invented that they can sell disks better if they seem to be bigger than they really are? At old times they used real values, but then at some point when we went to gigabyte sizes they started to divide values by 1000...

[britelite]

Originally Posted by Foebane

Well, yes.

Doesn't really sound like it

[S. Campbell]

Originally Posted by Jope

If you're using linux, why not just mount the image via a loop device and copy the files out to a new card instead of wasting time writing it and reading it back in..

What I heard: ARGLE FLARGLE WARGLE BARGLE SNARGLE.

[-Acid-]

The size problem is manufacturers sell drive capacities in decimal units so 1 gigabyte = 1000 megabytes but Windows is displaying the sizes in binary so 1 GiB = 1024 MiB. Hence 128 gigabytes as sold is roughly 119.21 GiB (gibibyte) in Windows.

[roondar]

Originally Posted by Daedalus

...and has been around for over two decades IIRC, enough time that people should be used to it by now

But old habits die hard, and most people (including myself) still use the old system in casual settings. But whenever there is scope for confusion, it's a good idea to be clear about the intended meaning.

In fact, I actually think it's a spread a bit deeper than that. Most operating systems and hardware vendors still label pretty much all relevant numbers in terms of one KB=1024 bytes, one MB=1024*1024 bytes (etc).

It doesn't seem to merely be a habit that takes a while to die, but rather a de-facto standard that has never really changed. The only exceptions to the old style of doing things seem to be Apple (OSX Finder labels 1000 bytes as 1KB) and harddisk/storage manufacturers (where the confusion is compounded by most users being unaware storage capacity is always measured before any filesystem is put on there).

Anyway, I do fully agree it's silly to use a well-defined prefix and have it mean something else, but I don't see it ending on the short term. And even if it does change in a more widespread fashion, we'd still have literally millions of programs, pieces of hardware, books, etc that do not use the new definition so the confusion will likely stick around for quite a while.