Home > Archive > Compression > January 2007 > MB, MeB, MaB
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| cr88192 2007-01-09, 9:56 pm |
| you know, for so long there has been this issue:
some people declare 1MB=2^20 bytes, others 10^6 bytes.
and so, someone or another in some distant land declares:
there will be the MebiByte (or MeB), and it will be 2^20, but the MB will be
10^6.
and almost no one has gone with this, KB, MB, GB, ... have always been
either one or another, and are almost interchangable...
so, what if we declare a new system, the MAvgByte (or MaB), which most of
the time will still be written MB anyways...
where the bases are:
10.039841058207732536621969066082^x (log-10 like)
and:
1.9976437978627585378029466959595^y (log-2 like)
and so:
1KaB=1012
1MaB=1024144
1GaB=1036433728
....
and then this system is silently used by those who adhere, still writing the
fammiliar kB, MB, GB, ...
and the average person fails to notice that anything is different...
ok, so, yeah, this is hardly serious...
me just noticing earlier that the 1-prefixed rice codes tend to cause
problems for the JPEG style 0xFF -> 0xFF 0x00 scheme (and my past 0x7F
escape scheme is slower).
a simple hack is making an alternate version of rice codes, where the prefix
is inverted (a run of 0s followed by a 1), which all in all generates less
inflation with this escape scheme.
this was noticed initially because the quantizer tables were comming out
unreasonably large (notably worse than just storing the values raw).
actually, rice codes don't seem particularly efficient for quantizer values
anyways, will probably come up with a different fixed VLC scheme for these
cases (alternatively, one can use linear prediction or similar, or at least
last-value prediction, but this may well be overkill).
or such...
| |
| Christian 2007-01-10, 3:56 am |
| Hi cr88192,
> you know, for so long there has been this issue:
> some people declare 1MB=2^20 bytes, others 10^6 bytes.
This issue has been resolved in 1999, see e.g.:
http://en.wikipedia.org/wiki/Binary_prefix
> and so, someone or another in some distant land declares:
> there will be the MebiByte (or MeB), and it will be 2^20,
> but the MB will be 10^6.
well, "mebibyte" is abbreviated with "MiB"
> and almost no one has gone with this, KB, MB, GB, ... have always been
> either one or another, and are almost interchangable...
This has often other reasons: laziness, ignorance, marketing, ...
> so, what if we declare a new system, the MAvgByte (or MaB), which most of
> the time will still be written MB anyways...
I don't think that this is a good idea. The people (you are targeting
at) could simply use the correct and standardized prefix...
Christian
| |
| cr88192 2007-01-10, 7:56 am |
|
"Christian" <iBBiS@gmx.de> wrote in message
news:1168421383.113389.27460@k58g2000hse.googlegroups.com...
> Hi cr88192,
>
>
> This issue has been resolved in 1999, see e.g.:
> http://en.wikipedia.org/wiki/Binary_prefix
>
yes, I know of this already.
as noted below, I was hardly being serious...
> well, "mebibyte" is abbreviated with "MiB"
>
I wasn't sure, couldn't remember exactly.
> This has often other reasons: laziness, ignorance, marketing, ...
>
yes.
>
> I don't think that this is a good idea. The people (you are targeting
> at) could simply use the correct and standardized prefix...
>
the joke here being, with the lack of standardization, pretty much no one
would notice anyways...
in fact, we have actually seen things along the lines of this already.
note, for example, that a 3.5 floppy was rated as 1.44MB, yet it stored 2880
sectors (80*2*18, CHS), each of which being 512 bytes.
1440 x 1024 bytes.
so: 1474560 bytes.
now, 1.44MaB = 1474767.36 bytes.
my scheme is thus off by only 207.36 bytes, and thus far more closely
matches the actual size of a floppy than EITHER of the traditional
measurements...
so, yes, it was a joke, but ironically enough, not all that far from many
existing practices.
then again, maybe manufacturers could go over to using GiB (or gib). so,
next time a drive dies, you can say "it blew 250 gibs", or maybe "1 g0t
pl0wn3d 5up3r h4rdz y0"...
> Christian
>
|
|
|
|
|