1 kilobit = 1000/1024 bit ?

[virus]

[EDIT: splitted from the "VP6.2 release" thread]

oh my god! after a couple of clips, looks like the 1024 thingie has made it to the final release...! :(
well, ok, let's add a suggestion for everyone:

WARNING: this version of VP6 assumes 1 kilobit/sec = 1024 bit/sec! (and not 1000) Divide your bitrate accordingly or you'll end up with a 2.4% oversize bias in every video you encode.

hope this helps :)
virus

[SeeMoreDigital]

Originally posted by On2Tech
Still is 1024. Maybe the next version.. :) Thanks for all the beta testing. Why bother.... Just make the selection use 'kbps' instead ;)

Very nice build

Cheers

[Maximus_G]

Originally posted by virus
oh my god! after a couple of clips, looks like the 1024 thingie has made it to the final release...! :(
So what? Isn's that just RIGHT?
For what reason 1 kbit should be equal to 1000 bits??

[virus]

Originally posted by Maximus_G
So what? Isn's that just RIGHT?
For what reason 1 kbit should be equal to 1000 bits??
Because it's quite standard.
Because AFAIK every codec out there uses 1000, and not 1024.
Because it's nonsense tu use a power of two in this situations, we're not talking about a binary value in a register, where powers of two are very useful.
Because 'k' lowercase is recognized world wide as 'x1000', while 'K' uppercase means 'x1024'.
So I think 1 kilobit = 1000 bits. Try a search with Google on this topic.

[m0rtal]

Originally posted by virus
So I think 1 kilobit = 1000 bits.
then it's not "kilobits" anymore! don't mess with it!

EDIT: I think that there is enough mess bith "kilos" is made by HDD manufacturers, so let's stay with INITIAL measuring system, and don't corrupt it.

[vinouz]

Well, if you're talking about the initial measure system, then it's the metric one. Here kilo = x1000. In this situation harddrive manufacturers are the only right people, as that's what they use. (This way they gain for 7.4 % more Gigabytes advertised than they would if they counted in computer K.)
BTW, it's pure respect to the standards. I wonder why everybody whines about these 7% considering the bad guys (HD manufacturers) are these that bring you 1000x the size you had 10 years ago, for half the price, at ten times the speed. Even CDs/DVDs start to suffer the competition to HD in terms of cost per megabyte.

[m0rtal]

vinouz
ok, I was talking about initial binary measuring system :)

BTW, only HDD manufacturers "gains" extra bytes, not consumers :(

[vinouz]

EDIT: I think that there is enough mess bith "kilos" is made by HDD manufacturers, so let's stay with INITIAL measuring system, and don't corrupt it.

What do you prefer :
A corrupt drive with correct binary metrics or a correct drive with corrupt binary metrics ?

True for HD manufacturers, but sometime they even sacrifice size to gain a little access time, and don't fill the plates to their entire capacity, so...

[m0rtal]

Originally posted by vinouz
What do you prefer :
A corrupt drive with correct binary metrics or a correct drive with corrupt binary metrics?
huh?
I'll prefer correct drive with correct binary metrics, because file systems still counts bytes by powers of 2...

[virus]

Originally posted by m0rtal
huh?
I'll prefer correct drive with correct binary metrics, because file systems still counts bytes by powers of 2...

you said it right. Bytes and not bits.
Anyway I stick with my idea. XviD, DivX and probably even WMV and RV use 1kbps = 1000 bits. VirtualDub(Mod) use kbps in the File Information dialog, and that's 1000 bits. So I'd prefer to stick with the "common" value.
BTW 56k and 33.6k modems transmit at 56000 (ideally, usually a bit less) and 33600 (real) bits... so I guess we're all wrong ;)
The guys at On2 can change this in a minute, as far as I understand Win32 GUI programming, this is a one-liner fix for the selection dialog (as SeeMoreDigital already pointed out)

[SeeMoreDigital]

Personally I like the new bitrate setting.

However, it may be less confusing to present the abbreviation 'kbps' instead of 'kilobits per sec'

That said, the guys over at XviD have managed to keep everybody happy by including a little button that can flick between 'kbps' and 'kbytes per sec'..... A very novel solution me thinks!

Cheers

[Maximus_G]

Originally posted by virus
Because it's quite standard.
Because AFAIK every codec out there uses 1000, and not 1024.

Oh, no. As far as i remember, "1kbit=1000bits" was fistly introduced by Divx in version 4 (in ver.3 it was 1024), and at release time they made a special note about that. Since then, it became a "standard" for Divx. And for Xvid as an offspring of Divx.

Because it's nonsense tu use a power of two in this situations, we're not talking about a binary value in a register, where powers of two are very useful.
Well, when someone calculates the future filesize in Mbytes using curent bitrate, THIS has much more sense for him:

size of videostream = kbps * 8 * 1024 * length;

and NOT that:

size of videostream = kbps / 1000 * 1024 * 8 * 1024 * length.

The only things that bitrate concerns are quality and size. And the first thing here that is to be calculated is the size.

As you know, filesize is the quantity of bytes.

And 1 Mbyte = 1024 kilobytes = 1024 * 1024 bytes = 1024 * 1024 * 8 bits.

Do we have to complicate that?

[m0rtal]

Well, I tend to agree with Maximus_G rather than virus
in computer world, we are all using binary MS (measuring system), not decimal... so 1 kbps still equals 1024 bps in computer terms, never mind what HDD manufacturers or software makers says :)

[temporance]

Bitrate has been measured in kbit/s = 1000 bit/s ever since the first time bits were sent over a piece of wire. A 56k modem does 56000 bit/s. A 1Mbit/s ADSL link can handle 1000000 bit/s.

It's industry convention and to argue for something different is a bit like saying, "I think there should be 1024 metres in a kilometre".

btw, the abbreviation "kbps" is also non standard. In SI notation, you should really write "kbit/s".

[vinouz]

Well, when someone calculates the future filesize in Mbytes using curent bitrate, THIS has much more sense for him:

size of videostream = kbps * 8 * 1024 * length;

and NOT that:

size of videostream = kbps / 1000 * 1024 * 8 * 1024 * length.

[EDIT] : it's not * 8, but / 8. Sorry for the first version of this post, it was wrong.

There are two solutions for calculating size (in MB) :

He takes his calc :
with kbits : size = kbps * 131 * length
(or to be precise kbps * 131.072 * length)

with Kbits : size = Kbps * 128 * length

Whow, is the first sooooo much harder ?

Then if he does is by head, what's the difference ? He's complicating himself both ways.
(the difference between 131 and 131.072 is an underestimate of 0.06%. On a CD the difference amounts to less than 400Kb, which is less than the file encapsulation overhead, about the best codec's estimation imprecision (XVID's). And usually I would prefer to overestimate in this case, putting directly 132 here. You're safer.)

Then when calculating bitrate from a size, which is usually what people need, by calc you first have to take the size, store it, then calc the number of seconds from minutes and second (This is often in fact the most annoying fact - our time system is far more intriguing in this calc) and then divide it to get the amount.
For kbits :
Size(MB) * 8389 = . Store it : MS touch on your calc
Hours, * 60, + Minutes, *60, + seconds (you can add 1 to be safe) = .
You have the duration in seconds that you have to reverse (1/X on your calc), then multiply by size (* MR =)
You got your bitrate in kbit/s
For Kbits do the same but change 8389 by 8192. Over.
(here the difference between 8389 and 8388.608, the exact value, is < 0.005%. On a CD that's < 35KB overestimate. Personnally I'd use 8400 : simpler, safer)

Man, where do you see the difference. You should go complaint about our Hour:Minutes:Second system here !


[EDIT] : @m0rt : You're right. I stop trolling.

[m0rtal]

guys, lets stop this discussion now!
or transfer it to the another thread...

[Kurosu]

Even more when you consider the problem was solved 5 years ago:
http://physics.nist.gov/cuu/Units/binary.html
Now, I agree it's hard to figure whether an OS, a particular software, or any people writing kB (notice the small k, the only SI official) follows the official rule, or is still refering to the past terminlology.

k<->K

[Maximus_G]

Damn, i've got a big temptation to continue our "kbit" talk :)
OK, i've nearly managed it, and since there are some words addressing me personally, i'll take a liberty of answering them on this offtopic (sorry, moderator).

vinouz:
it's not * 8, but / 8.
Yep, thank you, that was a mistake in my post.

Whow, is the first sooooo much harder ?

I can't tell ya, but if you show me a post here stating anything about hardness of the question, i'll try to figure it out. Or maybe i just missed your smilie? ;)

---

And finally:
Not having any power to argue IEEE, i've to admit (thanks to Kurosu)that 1 kilobit is 1000 bit...

Kibibi, guyz! SI! :D

[m0rtal]

arrrrrr....... can anybody tell me how many bytes have 128MB of DRAM? :)

[Didée]

Originally posted by vinouz
What do you prefer :
A corrupt drive with correct binary metrics or a correct drive with corrupt binary metrics ?
Quite OT, but I just cannot hold back here:

In the past two years, I've come across WAY TOO MUCH corrupt drives with corrupt binary metrics:
Originally posted by vinouz
... considering the bad guys (HD manufacturers) are these that bring you 1000x the size you had 10 years ago, for half the price, at ten times the speed ...
... and at 1/10th of expectable lifetime as well!

- Didée

[SeeMoreDigital]

Maybe before everybody here starts upsetting everybody else, we should get some 100% definite answers from other codec makers!

So come on all you official types at XviD, DivX, 3viX, RealMedia, Nero, Microsoft, QuickTime, etc ... do you use 1000 or 1024 in your calculations?

But here's a thought, why don't we use MegaBytes per minute instead? :p


Cheers

[virus]

:(

this splitting of threads really disappoints me.
I've just sent a word of advice for everyone used to Xvid/DivX if they want to try VP6, because it's not good to have your movie encoding run for 10 hours just to discover that your 700 MB encoding turned up to be 717 MB in size, just because the codecs use different 'kilobit' meanings... [EDIT: removed last words, my warning is still in the VP62 thread, thx bond for keeping it in]

Next time I will keep my mouth shut. And who cares if someone complaints about the oversizes.

BTW imho there's way too much confusion here on two totally different things.
Bytes in a HDD/RAM (=measure of size) and kbit/s over a wire (=rate, measure of speed) are two totally different concepts, and, yes, there are different "standard" values for them.
So what are we talking about? HDD & RAM sizes (in bytes) mean nothing in this thread.
I'm speaking from a 'telecommunications' point of view. That is, bits per second. Measure system used: SI decimal, for the last 40 years, and probably even for the next 40 (and a codec aimed to streaming over a network should follow the standard used by the telecommunications engineers, I think)

I think this thread can safely be closed.

virus

[SeeMoreDigital]

Actually I'm glad this issue has been raised

I don't know about some of you guys but I'm fed up with DVD~R/RW manufacturers being able to get away with stating that there media is 4.7GB when in fact it's only 4470MB (4.36GB)

It's the same with unformatted hard disc drives too!

We already have to put up with this misleading crap over CRT screen sizes, but it managed to get resolved with LCD and Plasma screens. How the hell did it manage to creep in with media?

Cheers

[bond]

Originally posted by virus
Next time I will keep my mouth shut. And who cares if someone complaints about the oversizes...
my warning is still in the VP62 thread, thx bond for keeping it inof course its still there, its an important info
dunno why you are thinking that noone cares about these problems?

this splitting of threads really disappoints me... I think this thread can safely be closed.well i can mux the thread back if people want it, but imo this issue is not only related to vp6, but to all codecs (i also thought about moving it to "generell discussion" because of the relevance for HDs aso..)

[virus]

Originally posted by bond
of course its still there, its an important info
dunno why you are thinking that noone cares about these problems?

I'm sorry I was just assuming that my post was moved away from that thread... I edited my last post above to reflect this. I've already complained about that 1024 issue privately with On2Tech when testing the betas, so there was no need to post about it at all. Instead I chose to warn everyone because I felt it was important.
I'm a bit disappointed to see how my warning generated such a discussion... I'm just trying to help ppl, and I don't like to be taken as a troll ;)

well i can mux the thread back if people want it, but imo this issue is not only related to vp6, but to all codecs (i also thought about moving it to "generell discussion" because of the relevance for HDs aso..)

I feel we're off-topic (here and on "General discussion" too). Since the thread goes by my name, I'm not happy with that. I even thought that a moderator (other than you, obviously) can come here and strike me for posting twice in a new thread... so I edited the first post to clarify that. Sorry but my 5 months long experience here as a lurker/poster makes me fear for my login (usually "low post count+no contribution to the community=less forgiveness for mistakes", sorry for saying that but I feel this is the truth, not only for forum.doom9.org).

IMHO we don't need such discussion (AFAIK it's only VP6-related, and RAM/HDD discussions are off-topic in every forum at doom9.org), so having an off-topic, useless (IMHO) springoff with my nick on top is something that I really don't like that much.

cheers :)
virus

[bond]

Originally posted by virus
Since the thread goes by my name, I'm not happy with that.dont worry, the ban only lasts for a month :D

nah, no mod will strike you for a thread i created ;)

[Stux]

3ivx uses KiloBytes/Second (KBytes/s, KB/s)

There are a 1024 bytes in a kilobyte.

We are considering adding 'kbps' or kbit/s, and if we do, there will be 1000 bits in a kbit.

[vinouz]

@Didée : I also had many problems with harddrives. Especially IBM ones...
And I prefer 10 times less space with ten times more robustness. Having a box @ work losing its HD, with all the work on it, after 15 days use, and no way to recover it, was a real pain.
@Maximus_G : for all these I forgot : ;) ;) ;).
@m0rtal : mem makers count in kibi & mebi bytes. So 128Mb = 134217728 bytes
@others. Thread over for me too . So we'll stick to the standards maybe now. kibi, mebi, gibi, pebi or kilo, mega...
Finally that's a good point, since now it should be clear for everyone !
Thanks Kurosu.

[Xavin]

Originally posted by m0rtal
arrrrrr....... can anybody tell me how many bytes have 128MB of DRAM? :)
RAM still uses multiples of 1024 at every level, so 134,217,728 bytes. This whole aregument about what is technically proper is pretty useless. There are conventions for which kilo to use (1000 or 1024) for each piece of computer technology and nothing is likely to change that, so everyone should just use what is accepted for that area.

[m0rtal]

Xavin, vinouz: my point was that if "kilo" is used with "bits/bytes", it means that we are using binary measurement, so if we encounter KB/MB/GB, they are obviously binary bytes - because bytes cannot be other than binary, isn't it? using decimal measurement for bytes is nonsence :( it's IMHO, of course, but you get my point, right?

[vinouz]

[edit : corrected as indicated just after, thanks temporance !]

Yes.
But in fact none of the two options makes more sense than any other one. There are simply reasons why people use them.

First memory makers count in 2 exponents because memories are structured in rows and columns, and that to access a row or a column you give its address in binary. So to make it simple to limit memory usage (out of bounds access) it was easier to test the most significant bytes : of example 128Mb makes 64Mdwords (often in 16bit architecture memory is adressed 16bit at a time so in inherited architectures the basic unit is 16 bit) which code in 26 address bits. Is one of the bits >= 26 (the 27th) is set to 1 then it's out-of-bounds. That's mostly why memory sizes are in 2 exponents. And 1024, 1024^2 etc. are 2 exponents.

These kinds of savings (easier to test bits than to compare numbers at the physical level) also happens in filesystems structures. Usually here the unit is a sector, 512 bytes (2048 in mode 1 CD-ROM, but here again CD-ROMs are inherited from audio CD which were first thought in 75th seconds so it's not very relevant...). Sectors are then grouped by 2 exponents in clusters (1, 2, 4, 8, 16kb...) So we continued, making KB, MB, GB in 1024 fashion. That way the whole measure system is coherent.

But the bandwith notations were first used by telecom engineer, when building the digital switched telecom networks. Engineers having more of a physicist background than programmers, they counted in bit (not bytes) per second, and used the international convention, which used our decimal system, using 1000 as the basis for kilo, mega, giga, tera, peta, exa and so on...
That's one of the many points that account for the big cultural difference and approach distinctions between network (computer world) and telecom (engineering) world, whose merging in the last years highlights these incompatibilities. (this one being only one of them.).

So each sector has its conventions, and for bitrates in videotransmission, it belongs historically to the telecom world, having invented/planned videoconferencing for long. So we count in kilobit per second, and these kilo are 1000 based.
But for size in video backups, you better use 1024 kilo (called "kibi") and count in bytes. Then you are specifying the total size of the file (and should account for the overhead of the container and everything else it contains). I continue translating in 1000 based at least once myself to account for the file overhead.
Then as I'm a little more prudent, I count 5MB(ytes) more, for good measure. And if I'm going multisession, I add 10MB for each session, for lead-in/lead-out.


Note that below that there are well defined conventions that you should use (some of which I just discovered, thanks to Kurosu again !) :

b stands for bit [not standardized, but used]
B stands for byte, which is 8bit [standard]
there are W and D and Q for respectively 2 (Word), 4 (Doubleword) and 8 (Quadword) bytes. [not standardized, but used in computer technical language]

kilo, mega, giga, tera and peta are 1000 based and their 1024 based counterparts are called
kibi, mebi, gibi, tebi, pebi [standardized]

k, M stands for kilo (1 000, 10^3), mega (1 000 000, 10^6) [standardized]

in computer language usually it is :
K, M, G, P stands for kibi (1024, 2^10), mebi (1 048 576, 2^20), gibi (2^30), tebi (2^40) ...[not standard]

[Conventions :]
memory and filesizes are in B, KB, MB, GB

bitrates are in b/s (bits per second), kb/s, mb/s, gb/s

Isn't it kewl ?

If I am wrong, correct me [done !]. Else you can make it a sticky.
vincent.

[temporance]

Originally posted by vinouz
b stands for bit
B stands for byte, which is 8bit
there are W and D and Q for respectively 2 (Word), 4 (Doubleword) and 8 (Quadword) bytes.AFAIK, the only one of these that is recognized by all of science and industry is 'B' for byte. 'b' is becoming more popular for 'bit', but to keep all the pedants happy it should probably be written in full as 'bit'.

Btw, you are wrong about the case of the prefixes:

k means x1000
M means x1000000

[K means Kelvin - a measurement of temperature]
[m means either x0.001 or metre - a length measurement]

IMHO, kbps sounds pretty unsophisticated. The only other time a 'p' is used instead of a '/' is on a car's spedometer: mph or kmph. The proper scientific measurement for speed is m/s. IMHO, the proper notation for bitrate units is 'kbit/s' or 'Mbit/s'.

[m0rtal]

vinouz huh... quite an explanation! good work! of course, I can complain about some points, but the most important question about all this stuff is "what are we gonna do with all this crap?"
should we (five or more men - very few) use "kibi" to emphasize the binary origination of the number? what about other users (lamers too) - wouldn't they be confused? and so on and so forth...
i can't answer :(

[vinouz]

Yeeeaaah ! Let's evangelize the world ! ;)

More seriously, for myself, I'll use it from now on.

Vincent.

[m0rtal]

vinouz, me too :)
step by step we'll force others to use normal SI :)

[vinouz]

Where did I put my horse and my crucifix ?
Must be somewhere there...

:D

[Atamido]

The Matroska tags avoid the whole issue by storing the "bits per second" of a data stream. Allows a quick comparison, regardless of what they codec wants to say and the container overhead.

[tiberious]

btw the standard notation for kibi, mebi, etc is:

KiB MiB GiB TiB

etc

just so you all know

also
kilobit = 1000 bits
Kibibit = 1024 bits

or so the standard monkeys say

[FlimsyFeet]

It would be great if everyone adopted the IEC approved notation for binary prefixes (KiB, MiB, etc.) as in the above post. In fact I have seen a very few programs that do use this (e.g Tom Zavodny's bitrate calculator (http://www.tomzavodny.cz/program/bitcalc/index_en.php)).

But unfortunately most computer programmers don't want to change, because they say it's a stupid name and that kibibytes sounds like a brand of cat food.

[unmei]

AFAIK you usually measure datarates ("flow") in 10^x Bits while you measure data amounts ("size") in 2^x Byte. That's at least what i see most in my school. The first seems to come from networking, telematics, and the second more from the programmer corner.
You can also avoid the bit/byte problem by referring to 8 bit as Octet (kiO, MiO, GiO).

[edit] ki, Mi, Gi to be more clear :)

[LigH]

I'd agree to vinouz' "Conventions" chapter:

Since ferrit memory, 1 KB equals to 1024 B, to keep dual powers.

But transfer speeds of modems used decimal values, since 300 / 1200 / 2400 bits per second.

The crux here is: No matter how usual a standard is, Microsoft may redefine it. They used KB/s instead of kbps in the VfW standard interface, they used Kbps insted of kbps in their MS MPEG4 codecs (and so did DivX 3)... and so the confusion continues.

But as long as XviD hits the expected final size in 2-pass mode good enough, I probably shall not care too much... ;)

[geoffwa]

Originally posted by SeeMoreDigital
I don't know about some of you guys but I'm fed up with DVD~R/RW manufacturers being able to get away with stating that there media is 4.7GB when in fact it's only 4470MB (4.36GB)


Agreed!

IT WILL BE A COLD DAY IN HELL BEFORE I RECOGNISE THE METRIC MEGABYTE!

[Gabriel_Bouvigne]

Lame is using kilobits per second (kbps), and is considering it to be 1000 bits per second.
As mp3 was made to be streamed over isdn lines, we are using the telco notation: 1kbps == 1000 bps