Talk:Bit rate

From Wikipedia, the free encyclopedia
Jump to: navigation, search



could someone add bitrate info for MPEG? and explain that same bitrates dont have to mean same quality - cd has bitrate of 174kbytes/s, encoded to MusePack or OggVorbis could have almost the same quality in 1/10 size. Similar with mpeg vs divx.

could someone explain what bitrate means in terms of audio recordings? -- Tarquin 13:18, 12 Aug 2003 (UTC)

Could someone explain the meaning of the phrase "The bitrate shows how large the quantity of the stored bits per second of music is." Talk about obtuse phrasing! Dostal 21:11, 8 Jul 2004 (UTC)

Ogg Vorbis and other formats[edit]

Could someone expand the page to include information on the bitrates of ogg vorbis and other formats? --Funnykidrian 02:58, 3 August 2006 (UTC)


This section could do with some work. Most, other than marketers, don't consider 128k to provide CD quality, irrespective of codec. Ok, there is the language 'minimum possible'; but then on the other hand, it gives 8Mbit/s as the 'minimum possible' for DVD quality, when this is more like the _maximum_ possible DVD bitrate (and 'DVD quality' can arguably be had for far less with a more efficient codec such as MPEG-4). Blorg 16:37, 16 Nov 2004 (UTC)

A lot of the figures, especially in the Video section, were intended to be ballpark values. If you know of more accurate lower bounds, feel free to change them. I really don't want this article get involved in silly "CD quality" flamewars, so how about specifying that "Foo quality" means "more than 50% of casual listeners do not consider the quality to be inferior to Foo". Obviously if you're an expert with brilliant equipment and you know precisely what to listen for, you will be able to tell a difference whatever the bitrate, but that's really not the point. [[User:Smyth|– Smyth]] 19:24, 16 Nov 2004 (UTC)
Why not simply change the CD quality to 320? Since that is the de facto quality of most CDs recorded nowadays (methinks...). (--HJV)
What do you base that number on? I think you're missing my point: the idea behind keeping it at 128 is that it is a number that most casual listeners would not notice to be inferior to the original, unless they were actively searching for differences. This page is supposed to be an indication of what's possible with the state of the art, which is no longer MP3. – Smyth\talk 1 July 2005 08:38 (UTC)
Just to get this clear. Is the article trying to tell what the quality of the audio on the CD actually is? In that case it should be 320. If it's trying to say what the human ear distinguishes as "CD quality", then leave it 128... Just to give an example, you can't refer to a 262 144 colour screen as a 65 536 colour screen despite the fact that the human eye will most likely not see any difference between the two. :)--HJV 2 July 2005 01:42 (UTC)
"In that case it should be 320."
How do you figure? 44100 Hz * 16 bit * 2 channels = 1.4 Mbps
(But don't try that on google calculator!) - Omegatron July 2, 2005 04:05 (UTC)
CD is 14 bit, so divide by 4 Jabberwoch (talk) 00:34, 23 February 2012 (UTC)
It's what the human ear distinguishes. There are explanations in the article itself, in a comment in the article, and a few paragraphs up on this talk page; I think it should be pretty clear. – Smyth\talk 2 July 2005 11:52 (UTC)
I don't see any of these explanations. Do you mean "that is the de facto quality of most CDs recorded nowadays (methinks...)"? That's hardly an explanation. - Omegatron July 2, 2005 14:13 (UTC)
Are you mistaking me for HJV? :) – Smyth\talk 2 July 2005 17:04 (UTC)
No. I'm asking where the explanations are. - Omegatron July 2, 2005 19:34 (UTC)
Maybe I'm misunderstanding you. The explanations I was referring to are, on this page, 'how about specifying that "Foo quality" means "more than 50% of casual listeners do not consider the quality to be inferior to Foo"', and on the article page, 'The bit rates in this section are approximately the minimum that the average listener (when using state-of-the-art compression) would consider not significantly worse than the reference standard'. Both of those sentences were written by me, so whether they're a good idea or not is obviously up for debate, but I think HJV is missing the point. Or perhaps he's under the delusion that since 320kbps is the maximum bitrate of MP3, that it is in some way equivalent to a CD. – Smyth\talk 2 July 2005 20:07 (UTC)
Ahhh... But that's pretty much opinion, no? That's not the actual bitrate at all. It's just the information degradation that an "average human" can't distinguish. Hmmm... - Omegatron July 2, 2005 20:56 (UTC)
Yes, of course it's subjective, but subjectivity is what lossy encoding is all about. Now technically this article doesn't have to mention lossy encoding at all, but audio and video bitrates, and their corresponding subjective qualities, are things that the average user will have a fair amount of experience with, so I think it's a good way of explaining what would otherwise be a fairly abstract concept. – Smyth\talk 2 July 2005 21:35 (UTC)
well, I don't know if anyone else cares, but i removed the most people can't tell between 192 and above, which is bogus, you can easily tell the difference between 320 and 256 or 192 or w/e you happen to be listening to. It's not like it's all flac or something. ANYWAY I also believe that the first poster (in this section) makes a point about 128 being cd quality or something? that may have been what the page used to say? Anyway, I remember using musicmatch years ago and when i used to rip stuff it would say 128 was cd quality and nothing higher was needed blah blah and now I'm baffled at how I could have believed that because I can simply HEAR the difference...have standards changed or what? can someone shed some light on this if possible? - Seth —Preceding unsigned comment added by (talk) 21:58, 22 April 2009 (UTC)

bandwidth vs. datarate[edit]

I think there is a quite bad mixup here. These bandwidth conversion links only offer datarate conversions! the bandwith - datarate relationship depends on the modulation ... Unfortunately this inaccuracy of definitions is all over these articles here!

Mathematically, for a given bandwidth; sampling at 2-times that bandwidth is the maximum sample-rate needed, beyond that no extra information is being recorded. In order to understand why this is you have to understand the mathematics of working in the frequency domain(rather than time domain), but essentially, a 22khz bandwidth signal (such as a sound signal which is human-hearable, humans can only hear between about 20Hz and 22Khz, which is why CDs are sampled at 44.1Khz) sampling beyond 44Khz is useless. Of course, this is given that the sampling being done is 'ideal' mathematically.(In addition, any particular individual might be able to hear beyond 22Khz. However, this begs the question; what musician is intentionally producing sounds above 22Khz??) The extra .1Khz(100Hz) is more than enough to account for the non-idealities of current digital sampler technology.

  • sampling beyond 44Khz is useless
  • what musician is intentionally producing sounds above 22Khz
    • All of them. Harmonics extend to infinite frequency, though the amplitudes become negligible.
  • The extra .1Khz(100Hz) is more than enough to account for the non-idealities of current digital sampler technology.
    • I'm not sure about that. — Omegatron 05:20, 13 March 2006 (UTC)

Merging the little bit rate articles?[edit]

Bit rates
Name Symbol Multiple
bit per second bit/s 1 1
Decimal prefixes (SI)
kilobit per second kbit/s 103 10001
megabit per second Mbit/s 106 10002
gigabit per second Gbit/s 109 10003
terabit per second Tbit/s 1012 10004
Binary prefixes (IEC 80000-13)
kibibit per second Kibit/s 210 10241
mebibit per second Mibit/s 220 10242
gibibit per second Gibit/s 230 10243
tebibit per second Tibit/s 240 10244

The (currently six) bit rate articles need work. The bit and byte rates, for instance:

are currently clumped into the same kilobit per second article, which is suboptimal (though they aren't really worthy splitting into two articles I don't think). Maybe rename to Kilo- bit rates or something? Nah. That sounds even worse...

Also, none of the articles are consistent in formatting or information presented anyway. Maybe these should all be merged into bit rate? It was already decided to keep kilobit, etc. separate, but maybe the rates will never be big enough for their own articles. — Omegatron 05:25, 13 March 2006 (UTC)

Transcoding questions[edit]

If one is playing music (or speech for that matter) at any given bitrate, is there any point in recording it at a higher rate? Also, if the playing bitrate varies, should one record using a constant bitrate setting or a variable one? 19:43, 19 November 2005 (UTC)Eileen Caister

If it's lossy audio that's being played back, any non-lossless recording will result in objectively worse quality. Whether this is noticable with your ears is another problem altogether. --KJ 18:10, 25 January 2006 (UTC)

Academia and Science vs. Marketing, Nonsense and Slang[edit]

IEEE provides a definite guide on IEEE units and SI prefixes: Wikipedia should refer to the correct usage of units. Due to marketing purposes, people tend to write and talk about "kbit/s", "kbps" etc. That's all wrong. To avoid confustion and to provide a solid, profund and reliable system of units that is based on international conventions and scientific relevance, Wikipedia should use "b" for bit as on page A1 in and "b/s" for "bit per second", "kb/s" for "1000 bit per second" etc.

Within Wikipedia there should be a clear and precise reference to the academic world and its well developed units. Additional explanations may explain why marketing language may use different abbreviations. —Preceding unsigned comment added by (talk) 23:22, August 24, 2007 (UTC)

Note there is no SI unit for "bit per second".[edit]

Baud can be used, but from the Baud page, it only applies to acoustic modems, LAN standards APPARENTLY expressing the data rate rather than the gross bit rate. But I, or they (on that page), could be wrong.Jabberwoch (talk) 00:54, 23 February 2012 (UTC)

No binary meaning for SI prefixes[edit]

The entry currently states:

however, most Internet Service Providers, and software companies,
such as Microsoft use base 2 ...

I don't believe this is true and request any references to support the claim. I did some research, appended below, and found that a preponderance of evidence is contrary to this assertion, So I am removing this section. I assert that binary prefixes—both the new forms and the misused SI forms—are not conventional units when discussing bit rates.

The references cited below are an ad-hoc sampling of Google results using terms like "ISP service" mbps mbit/s megabit.

References regarding Microsoft usage of decimal and binary meanings for SI prefixes kilo, mega, and giga in the context of bit rates[edit][edit]

320Kbps (320000 bps)
148Kbps (148000 bps)
66Kbps (66000 bps)

These obviously use the decimal meanings.[edit]

Produces near FM-radio quality with 28.8 Kbps modems and near
CD-quality at 64 Kbps.

"28.8Kbps" is a decimal usage refering to the V.34 standard modem speed. The other uses in the document presumably use the same convention.[edit]

Connection Bandwidth
Dial-up 28.8 to 56 Kbps
ISDN    64 to 128 Kbps
DSL or Cable    128 to 768 Kbps
T-1     1.5 megabits per second (Mbps)
T-3     45 Mbps
DS-3    45 Mbps

These are all decimal usages refering to standard bit rates, and this usage is consistent throughout this document when refering to fixed bit rates, e.g. for standard link protocols. Yet, the document also includes clear instructions for epsressing the bit rate of streaming media as Kbps of 1024 bits and Mbps of 1024 Kbps:

Samples per second * bit depth per sample * number of channels = total bits per second (bps).
Total bits per second / 1024 bits per kilobit =
total Kbps

Maybe the distinction in the author's mind (if any) is that fixed link speeds use decimal prefixes while content encoding bit rates use binary prefixes?[edit]

The bit rate of high-resolution, full-frame, broadcast video is
about 128  megabits per second (Mbps). To download one second of
broadcast video over a 28.8 kilobit per second (Kbps) connection
using a modem would take one hour and 14 minutes.

At least the 28.8 Kbps reference is decimal usage. Other uses in this document are ambiguous.[edit]

The server is connected to the Internet through a DS1/T1 line,
which can transmit data at 1.536 megabits per second.

Decimal usage.

Connection Type    Connection Speed
Dedicated PPP/SLIP via modem    28.8 kilobits per second (Kbps)
Frame Relay or fast modem       56 Kbps
Integrated Services Digital Network (ISDN)      128 Kbps
Typical DSL     640 Kbps
DS1/T1  1.536 megabits per second (Mbps)
10-megabit Ethernet     8 Mbps (best case)
DS3/T3  44.736 Mbps
OC1     51.844 Mbps
100-megabit Ethernet    80 Mbps (best case)
OC3     155.532 Mbps
OC12    622.128 Mbps
1-gigabit/sec Ethernet  800 Mbps (best case)

These are all clear decimal uses except for the Ethernet ones which are ambiguous (we don't know what "best case" means).[edit]

The maximum bit rate for IEEE 802.11b is 11 Mbps (using DSSS).
The maximum bit rate for IEEE 802.11a is 54 Mbps ...

Decimal usage.[edit]

A T1 circuit (also called a T1 line) is formed from a combination
of 24 DS-0 (Digital Signal Zero) channels, each having a bandwidth
of 64 kilobits per second (Kbps), for a total bandwidth of 1.544
megabits per second (Mbps).
T1 = 193 bits/frame x 8000 frames/sec
   = 1544000 bits/sec 
   = 1.544 Mbps

Decimal usage.

References for ISP usage of decimal and binary meanings for SI prefixes kilo, mega, and giga in the context of bit rates[edit]

Comcast (US Cable TV and ISP)[edit]

 Mbps: Megabits, or millions of Bits, per second.

Decimal usage explicitly stated.

Speed comparisons are for downloads only and are compared to 768Kbps
DSL and 56Kbps dial-up.  Maximum download speed of 4Mbps (or 6 Mbps)
and upload speeds of 384Kbps (or 768Kbps) depending on the product
that is selected.

The DSL and dialup rates are obviously decimal usage. The other uses in the document presumably use the same convention. (US ISP)[edit]

T1 speeds up to 1.544Mb/sec

Decimal usage throughout the document.

Optic Fibre & Wireless (Australian ISP)[edit]

This company's usage is almost entirely based on decimal usage of SI prefixes for bit rates, even though they define the terms kilobit and megabit with the binary usage.

What is E1?
E1 is a European Telco Standard that carries data at 2.048
Mbps over copper wire.
Optic Fibre & Wireless (OFW) can connect your organisation
together at speeds up to 2 Gbps (2,000 Mbps) or 20 x faster
than your LAN!
1.5 Mbps (1,500 kbps) - the bandwidth of business ADSL

So far they are using standard decimal prefixes. But then they go and define kbps in a glossary of terms:

(kilobits per second) A measurement of the transmission speed
of data measured in 1,024 bits per second.

This is using the SI prefix with binary meaning. Presumably, though, this entry is an error (or an actual misunderstanding of the term by the person who wrote this entry) since all of the actual uses of kbps on this page and elsewhere on the company's site use the decimal meaning (e.g. "56 kbps - the bandwidth of your dial-up modem").

Later, in the same glossary:

(gigabits per second) This is a measure of throughput in
gigabits per second — 1 billion bits per second. (1,000 Mbps)

Which asserts the decimal meanings at least for Mbps and Gbps.

Internode (Australian ISP)[edit]

  * MB is Megabyte
  * GB is Gigabyte, 1 Gigabyte is equal to 1,000 Megabytes

This is a bit ambiguous but hints at standard (decimal) usage.

Maximum Possible Modem Speeds:

    * ADSL2+ Modem - 24000k/1000k
    * ADSL2 Modem - 12000k/1000k

This is using the decimal meanings for these standard DSL speeds.

ISWest (US ISP)[edit]

Wide variety of DSL speeds; 144 - 768 kilobits per second

This is using the decimal meanings for these standard DSL speeds.

usage notes table[edit]

congratulations, that is a well-used and clean table.

"Bitrates in multimedia" discrepancy[edit]

The article says:

For technical reasons (hardware/software protocols, overheads, encoding schemes, etc.) the actual bitrates used by some of the compared-to devices may be significantly higher than what is listed above.

It then goes on to list CD audio as 1.4 Mbit/s, implying that this is the physical-layer bit rate. However this is actually the audio bit rate (44100 * 2 * 16 = 1.411200e6). Can we clarify what this section is talking about? Oli Filth 11:19, 29 August 2006 (UTC)

Conversion tables[edit]

IMO this page (or the appropriate subpage) should have conversion tables for common bitrates to byterates as most endusers aren't too familiar about the difference. - G3, 15:24, 28 October 2006 (UTC)

Bandwidth and Latency[edit]

I wonder if it would to mention early on that the difference between bitrate and propagation speed is often talked about in terms of Bandwidth and Latency_(engineering). You can find these articles by following links, but direct linking and description might help. I would recommend only referring to "transmission rate" and not "transmission speed" for the rest of this article.

It is important to remember that transmission speeds cannot increase indefinitely. A server in California and one in India can exchange about 9 round trip communications per second, due to the speed of light. As soon as you start thinking about interplanetary information exchange, you realize that Moore's law isn't going to solve everything. Even seasoned engineers sometimes forget to take simple economic implications of this into account, so it might be worth mentioning.

I agree with Omegatron that sampling frequencies and mathematical limits are relevant. Perhaps link directly to Nyquist-Shannon_sampling_theorem.

Posted 2006-11-02, Dominic Widdows.

Merge of bit/s articles[edit]

I've proposed that all the articles like megabit per second be merged into this article. There is nothing about these units that they deserve their own articles.

However, we should provide a list of each unit on this page, with definitions and anchor links, so the redirects can link directly to the unit's definition and the units can be linked in articles. — Omegatron 00:14, 19 May 2007 (UTC)

If we do merge them, we need to do all of them, merge any unique content like unit definitions and examples into this article, and leave the redirect as an anchor tag to the definition of the unit to maintain links. — Omegatron 01:37, 2 June 2007 (UTC)

  • I concur with the merge; the articles are very redundant as they stand. I think a redirect would fix the lot since the relevant information is already here, but if you want to do something more complex go for it. >Radiant< 13:16, 4 June 2007 (UTC)
I'm going to redirect, but also include anything that's not in this article, and maintain the links with anchor tags. Since this has been up almost a month with no complaints, I'm going to do it. — Omegatron 23:04, 9 June 2007 (UTC)
Ok, now I'm looking at this, and it's not as straightforward as I thought.  :-) The best way to present the different units would be a table, but that doesn't lend itself to individual anchor tags. I guess a Definitions section with a table and redirecting the little articles to that section would work. I'll build the table here first. — Omegatron 00:29, 10 June 2007 (UTC)
Bit rates Byte rates
Decimal prefixes (SI)
Multiple Name Symbol Name Symbol
103 kilobit per second kbit/s kilobyte per second kB/s
106 megabit per second Mbit/s megabyte per second MB/s
109 gigabit per second Gbit/s gigabit per second GB/s
1012 terabit per second Tbit/s terabyte per second TB/s
Binary prefixes
(IEC 60027-2)
210 kibibit per second Kibit/s kibibyte per second KiB/s
220 mebibit per second Mibit/s mebibyte per second MiB/s
230 gibibit per second Gibit/s gibibyte per second GiB/s
240 tebibit per second Tibit/s tebibyte per second TiB/s
Merge Seems like a good idea to me. ⒺⓋⒾⓁⒼⓄⒽⒶⓃ talk 21:06, 22 September 2007 (UTC)
I vote yes on merging all the "---bit_per_second" articles with this one and redirecting them all here. I also like Omegatron's proposed table. -- CWesling 02:03, 3 November 2007 (UTC)
I also support this. All the *bit/s article are redundant, since the conversions are obvious, especially with the Bit rate infobox (which should be kept). Superm401 - Talk 13:16, 20 November 2007 (UTC)

I merged them all to Data rate units for now. Now go clean it up.  :-) — Omegatron 02:35, 22 December 2007 (UTC)

Merge of several *rate articles[edit]

A merge of the bit rate article, the data transfer rate article and others is discussed in the talk page of the latter page. Mange01 00:09, 30 October 2007 (UTC)

I'm also in favor of this merger. Merge 'em all! 8-) -- CWesling 02:03, 3 November 2007 (UTC)

Bitrate vs. Size of File[edit]

I think that it's important that the bitrate vs. size of file comparison be added and which (whether larger bitrate, larger file size or larger bitrate, smaller file size) can be used to optimize performance. —The preceding unsigned comment was added by Jotsko (talkcontribs).

Bit rate is file size, more or less. Bit rate is file size divided by play time, so if play time is the same and the bit rate is the same, then by definition, the file size will be the same as well. --Kjoonlee 21:15, 9 June 2007 (UTC)


It's great that you're all trying to make wikipedia look nice but all those "it has been suggested that x be merged into this article" banners look atrocious. Either merge them or take the banners down, for goodness sake! —Preceding unsigned comment added by (talk) 00:45, 30 November 2007 (UTC)

Federal Standard 1037C[edit]

Does anyone know which statements in this article come from this standard? If not, can we remove the {{FS1037C MS188}} usage? This template is one of my least favourites on WP, because it seems to be just slapped on articles arbitrarily! Oli Filth(talk) 18:42, 25 December 2007 (UTC)

Hi there. Can't help you with 1037C I'm afraid, but would like to wish you a Merry Christmas anyway :-) Thunderbird2 (talk) 18:46, 25 December 2007 (UTC)

Suggestion for comparison table of baud rate, gross bit rate and net bit rate for common technologies[edit]

I suggest that the following comparison table is added to the article, after it has been extended with accurate figures. Please add more information to it. Mange01 (talk) 23:47, 12 April 2008 (UTC)

Technology Baud rate Gross bit rate Net bit rate
V.92 modem downlink 8000 baud 56.000 bps
One ISDN B-channel 64.000 bps
100Base-T Ethernet 100 Mbps
IEEE 802.11a WiFi 6 - 54 Mbps

Ethernet gross and net bitrate[edit]

The article uses Ethernet 100Base-TX as an example of a technology that has a same gross and net bitrate. But 100Base-TX is using 4B5B encoding; therefore, its gross bitrate is 125 Mbps. —Preceding unsigned comment added by (talk) 10:52, 21 August 2008 (UTC)

The issue is addressed. Mange01 (talk) 20:59, 23 September 2010 (UTC)

Why is 12 sources not enough?[edit]

A {{Refimprove}} template was added without motivation. Please be more specific and replace it by {{source needed}} templates wherever appropriate. Currently the article has 12 sources, and only one {{source needed}} template. Mange01 (talk) 20:59, 23 September 2010 (UTC)

No answer for 6 months. I added a few sources and removed the template. Please be more specific. Mange01 (talk) 17:18, 31 May 2011 (UTC)

Split? Separate list of Multimedia bit rates?[edit]

Can we move the multimedia part into a separate article? At least the list of bit rates. For example Bit rate in multimedia or Multimedia encoding bit rate, or list of multimedia format bit rates or something like that? This article still can sumarize the multimedia aspects but skip the details. See also Comparison of container formats. Mange01 (talk) 17:55, 30 June 2011 (UTC)

Agree Sounds like it would make the article more readable and still provide the details for those who want it. § Music Sorter § (talk) 15:12, 3 July 2011 (UTC)

Bitrate Crash Test[edit]

What is bitrate crash test (Crash test)?--- (talk) 08:36, 25 August 2011 (UTC)

1 Byte/s (Bps or B/s) corresponds to 8-bit/s (bps or b/s) - false or true?[edit]

I would like to comment the following statement:

  • 1 Byte/s (Bps or B/s) corresponds to 8-bit/s (bps or b/s)

Although at first sight this seems correct, in fact it is not. Let's take as an example the plain old RS-232 connection. A typical scenario for sending one byte over this kind of communication medium consists of one start bit, eight data bits and one stop bit, or a total of 10 bits. Although the start and stop bits are overhead and not useful data, they do participate in the communication process and do take time to transfer and process. So, a typical 8N1 9600 b/s communication does not transfer 1200 (=9600/8) bytes each second but only 960 (=9600/10). The difference of 240 bytes is not insignificant and grows when the rate grows (at rate 115200 b/s it is 2880 bytes).

To complicate matters, an RS-232 line may be configured to use as low as 5 data bits up to as high as 8 data bits, may use one, one and a half or two stop bits and may have or not have a parity bit. In the minimum case (5N1) this makes 7 bits per byte and in the maximum case (e.g. 8E2) - 12 bits per byte. — Preceding unsigned comment added by Gazibara (talkcontribs) 15:42, 15 February 2012 (UTC)

I think it's a clumsy way of stating that a byte is 8 bits. Extraneous in the first place, in my opinion. Radiodef (talk) 00:56, 9 November 2012 (UTC)


Throughput is ultimately the number of bits successfully delivered.

Fidelia215050517 (talk) 15:18, 7 March 2017 (UTC)