Talk:Binary prefix/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

→

Archive 10

Comment in the article

Warning: These values are wrong, SI uses 10-based counting, not 2-based. SEC (below) is 2-based. This also seems formatted quite messily (spaces everywhere).

Comments to the article like that belong here. Or fix the article if you think its wrong. --kudz75 06:26, 30 May 2005 (UTC)

Added again by User:66.231.16.111 as a HTML comment - Omegatron 19:28, May 30, 2005 (UTC)

non standard usage? i noted a warning about this being incorrect, and i commented on the spaces used for formatting, but i mreant around the table headings (" Symbol " or " Value ") ... not the numerical seperator used for reading clarity. the original author says SI kilo for bytes is 2^10 = 1024, that's the SEC KiB (noted below). SI kB or KB is 10^3 = 1000 ... hard disk manufactorers say "1 GB = 1 000 000 000 bytes" because they use SI numbering ... or 10 based counting, which is what SI is for, not base 2 counting, which SEC does. I added this as a comment this time so that i don't pollute the document, but I didn't know who to take this to

Various references

Binary measurements (kilo- = 1024)

CDs

• Data capacity of CDs - Data capacity in Mb for a CD-ROM
  • 74 min

  = 333,000 sectors * 2048 bytes / sector

  = 681984000 bytes

  = 650.4 Mb

  • 80 min

  = 360,000 sectors * 2048 bytes / sector

  = 737280000 bytes

  = 703.1 Mb

• For 74 minute CD-Rs, the capacity is 74*60*44100*2*2*2048/2352 = 681984000 bytes, or 650.390625 binary MiB (exactly, no roundoff error).
• For 80 minute CD-Rs, the capacity is 80*60*44100*2*2*2048/2352 = 737280000 bytes, or 703.125 binary MiB (again, this figure is exact, not rounded off). [1]

(please note that they meant Megabytes (MB) int his article when they said Mb) Cavebear42 23:36, 31 May 2005 (UTC)

To clarify this: CD capacity is measured in minutes, based on the original "Red Book" standard for audio CD's. Audio CD's play at 75 blocks per second (most people say "sectors" but this is arguably incorrect because CD's use a spiral track). For audio, the usable amount of data per block is 2352 bytes (usually referred to as "raw bytes"); for CD-ROM ("Yellow Book") the usable amount of data is reduced to 2048 "cooked" bytes per block because of added error detection and error correction bytes.

So, in slightly different formulas (with the same results):

• 74 minutes * 60 seconds * 75 blocks = 333000 blocks

  333000 blocks * 2048 bytes = 681984000 bytes = 666000 KiB = 650.390625 MiB.

• 80 minutes * 60 seconds * 75 blocks = 360000 blocks

  360000 blocks * 2048 bytes = 737280000 bytes = 720000 KiB = 703.125 MiB.

The longest CD that can possibly be recorded (but violates some Red-Book specifications) is 99 minutes, 59 seconds and 74 blocks, because of the BCD-based encoding of timing information:

• 99m59s74b = 449999 blocks

  449999 blocks * 2048 bytes = 921597952 bytes = 899998 KiB = 878.904296875 MiB

Jac goudsmit 23:05, 26 September 2007 (UTC)

Memory

• "As an example, 64 MB of RAM memory always means 64 times 1,048,576 bytes, never 64,000,000." [2]

Decimal measurements (kilo- = 1000)

DVDs

• Understanding DVD - Data capacity in GB for a DVD-R
  • 2,294,922 sectors * 2048 bytes / sector

  = 4,700,000,000 bytes

  = 4.7 GB

• For DVD+/-R[W] media, the exact capacity is 4697620480 bytes, or just shy of 4.7 decimal GB. The capacity of a DVD-R is certainly nowhere near 4.7 binary GB. [3]

Data rates

• "Lending confusion to this mess though, in some areas only decimal values are used such as when the term, "56K modem" works at a maximum speed of 56,000 bits per second, not 57,344." [4]
• "Just to avoid confusion, 33.6 Kbps = 33600 bps, 28.8 Kbps = 28800 bps (where bps means bits per second), and so on." [5]
• "Traditionally, Ethernet networks operate at 10 Mega-Bits per Second (10,000,000 Bits per second)" [6]
• 1.4.48 bit rate (BR): The total number of bits per second transferred to or from the Media Access Control (MAC). For example, 100BASE-T has a bit rate of one hundred million bits per second (10⁸ b/s). IEEE 802.3 standard Cavebear42 23:36, 31 May 2005 (UTC)

Is this true? Why would you have a power of 2 with a decimal unit? Does 128 kb/s really mean 128000 b/s? 128 is 2^7, which implies we're using binary. Can you provide a link to convince me otherwise? Tango 19:31, 24 December 2005 (UTC)

I don't know why the strange combination was chosen, but try it for yourself with your favorite constant bit-rate MP3:

Bitrate: "192 kbps"
Length: 262.3 s
Expected size if "k" = 1000: 192 * 1000 * 262.3 / 8 = 6295200 bytes
Expected size if "k" = 1024: 192 * 1024 * 262.3 / 8 = 6446284 bytes
Actual size:                                          6296347 bytes

– Smyth\^talk 13:23, 25 December 2005 (UTC)

128 is a power of two, but the other available rates (32, 40, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256 and 320) are not. I'm sure it has to do with frame sizes or something. — Omegatron 03:58, 19 June 2006 (UTC)

Well, ignoring the fact that some of those rates are powers of 2, what you'll actually find is that all of those rates are multiples of 8, as in 8 bits per byte/octet.

So the BYTE rates would be 4 KB/s, 5 KB/s, 6 KB/s, 7 KB/s, 8 KB/s, 12 KB/s, 14 KB/s, 20 KB/s, 24 KB/s, 28 KB/s, 32 KB/s, and 40 KB/s. You can see a more-rational progression in those MP3 encoding rates, right?

Atlant 16:44, 19 June 2006 (UTC)

I think we've simply forgotten (over many years) that the "bit" is the base measurement of storage on a computer, not the "byte." A "byte" is a collection of bits, and a bit is not a division of bytes. Encoding rates for MP3s are expressed properly (128kb is 128,000 bits). This entire discussion is idiocy, to be perfectly frank, and the usage of "-bi" prefixes is only 'widespread' in that it is laughed out of facilities world-wide.

The improper use of "byte" as a base unit is akin to using the kilometer as a base unit of distance, then referring to "kilokilometers," "megakilometers," and "gigakilometers." The fact that "bits" are most often grouped into octets (or powers-of-two) is irrelevant, since this is not always so (witness 7-bit character encoding). Confusing the issue even more is the fact that hexadecimal is just behind binary in computing base-usage. (This began as a response to the MP3 rate listing, but if someone feels that it would be better relocated to another part of the discussion page, be my guest. I'm not even sure myself, at this point.) 68.166.26.220 09:42, 16 February 2007 (UTC)

Hard drives

• "Drive manufacturers, including Hitachi Global Storage Technologies, market their drive capacities in terms of decimal capacity. In decimal 1 kilobyte (KB) is equal to 1,000 bytes, 1 megabyte (MB) is equal to 1,000,000 bytes, and 1 gigabyte (GB) is equal to 1,000,000,000 bytes. Operating systems and some software programs (fdisk, partitioning utilities, system BIOS, etc…) all view the drive capacity in terms of a binary capacity. In binary, 1KB is equal to 1,024 bytes, 1MB is equal to 1,048,576 bytes, and 1GB is equal to 1,073,741,824 bytes." Why does my hard drive report a lower capacity than what is on the drive’s label? (Hitachi)
• "Note that the Maximum Capacity shows only 3099 MB instead of 3240 MB. This is because some system BIOSs recognize a Megabyte as 1,048,576 bytes (binary). Drive manufacturers recognize a Megabyte as 1,000,000 bytes (decimal)." Hitachi
• "This has to do with the way nearly every harddrive manufacturer in existance calculates hard drive size. They all define 1 gigabyte = 1,000,000,000 bytes instead of the 1 gigabyte = 1,073,741,824 bytes which it *really* is ... This is standard industry practice" [7]
• "Hard drive size is given in Gigabytes (GB). A Gigabyte is one billion bytes or one billion characters." [8]
• "Hard drive manufacturers define 1 gigabyte as exactly 1,000,000,000 bytes. By their definition, a 45BG hard drive is exactly 45,000,000,000 bytes. The true definition of 1 gigabyte is actually 1,073,741,824 bytes" [9]
• Wow, what an eccentric usage of the words real and actually. Anyway, it's not that simple. According to #Hard disk sizes above, Hitachi and Maxtor seem to use the hybrid 1 GB = 1000*1000*1024 B, and Quantum (out of business now) used 1 GB = 1024*1024*1024 B.

Organization recommendations

• IEC
  • Standard: IEC 60027‐2, Second edition, 2000‐11, Letter symbols to be used in electrical technology — Part 2: Telecommunications and electronics
  • "These prefixes for binary multiples, which were developed by IEC Technical Committee (TC) 25, Quantities and units, and their letter symbols, with the strong support of the International Committee for Weights and Measures (CIPM) and the Institute of Electrical and Electronics Engineers (IEEE), were adopted by the IEC as Amendment 2 to IEC International Standard IEC 60027-2: Letter symbols to be used in electrical technology — Part 2: Telecommunications and electronics. The full content of Amendment 2, which has a publication date of 1999–01, is reflected in the tables below and the suggestion regarding pronunciation." [10]
• IEEE
  • Standard: IEEE 1541–2002, IEEE Standard for Prefixes for Binary Multiples
    • "1541-2002 (SCC14) IEEE Trial-Use Standard for Prefixes for Binary Multiples [No negative comments received during trial-use period, which is now complete; Sponsor requests elevation of status to full-use.] Recommendation: Elevate status of standard from trial-use to full-use. Editorial staff will be notified to implement the necessary changes. The standard will be due for a maintenance action in 2007." IEEE-SA STANDARDS BOARD STANDARDS REVIEW COMMITTEE (RevCom) MEETING AGENDA 19 March 2005
    • "1541-2002 IEEE Standard for Prefixes for Binary Multiples (Upgraded to full use from trial use)" [11]
  • Information for authors — "Information for IEEE Transactions, Journals, and Letters Authors"
    • TABLE OF UNITS AND QUANTITY SYMBOLS
    • "mega-: SI prefix for 10⁶. The prefix mega shall not be used to mean 2²⁰ (that is, 1 048 576)."
    • "kilo-: SI prefix for 10³. The prefix kilo shall not be used to mean 2¹⁰ (that is, 1024)."
  • "Faced with this reality, the IEEE Standards Board decided that IEEE standards will use the conventional, internationally adopted, definitions of the SI prefixes. Mega will mean 1 000 000, except that the base-two definition may be used (if such usage is explicitly pointed out on a case-by-case basis) until such time that prefixes for binary multiples are adopted by an appropriate standards body." [12] (the IEC standard has been published since this note was released and later published by IEEE itself)
• NIST
  • "The IEC has adopted prefixes for binary multiples in International Standard IEC 60027-2, Second edition, 2000–11, Letter symbols to be used in electrical technology — Part 2: Telecommunications and electronics. ... Although these prefixes are not part of the SI, they should be used in the field of information technology to avoid the incorrect usage of the SI prefixes." NIST Special Publication 330 2001 Edition The International System of Units (SI)
  • "Because the SI prefixes strictly represent powers of 10, they should not be used to represent powers of 2. Thus, one kilobit, or 1 kbit, is 1000 bit and not 2¹⁰ bit = 1024 bit. To alleviate this ambiguity, prefixes for binary multiples have been adopted by the International Electrotechnical Commission (IEC) for use in information technology." nist.gov
  • "The new prefixes will eliminate the present confusion between powers of 1000 and powers of 1024 since in the field of information technology the SI prefix names and symbols for decimal multiples are now often used to represent binary multiples." News briefs Section 1.9
  • "With significant input from the National Institute of Standards and Technology, the IEC adopted kibi (Ki), mebi (Mi), gibi (Gi), tebi (Ti), pebi (Pi) and exbi (Ei) to represent exponentially increasing binary multiples. A kibibyte, therefore, equals 2 to the 10th power, or 1,024 bytes. Likewise a mebibyte equals 2 to the 20th power, or 1,048,576 bytes. The new prefixes for binary multiples, which parallel the metric prefixes, will increase precision in expressing electronic information." Representative's Report — April 1999
• SI/BIPM
  • "These SI prefixes refer strictly to powers of 10. They should not be used to indicate powers of 2 (for example, one kilobit represents 1000 bits and not 1024 bits)." [13]
  • "These SI prefixes refer strictly to powers of 10. They should not be used to indicate powers of 2 (for example, one kilobit represents 1000 bits and not 1024 bits). The IEC has adopted prefixes for binary powers in the international standard IEC 60027-2: 2005, third edition, Letter symbols to be used in electrical technology — Part 2: Telecommunications and electronics. The names and symbols for the prefixes corresponding to 2¹⁰, 2²⁰, 2³⁰, 2⁴⁰, 2⁵⁰, and 2⁶⁰ are, respectively: kibi, Ki; mebi, Mi; gibi, Gi; tebi, Ti; pebi, Pi; and exbi, Ei. Thus, for example, one kibibyte would be written: 1 KiB = 2¹⁰ B = 1024 B, where B denotes a byte. Although these prefixes are not part of the SI, they should be used in the field of information technology to avoid the incorrect usage of the SI prefixes." [14]
  • "A decision was made to include a marginal note discussing the binary multiples along the lines of that given on p.14 of the NIST Special Publication 330, 2001 edition". Report of the 15th meeting (17 –18 April 2003) to the International Committee for Weights and Measures
• ISO?
  • ISO/IEC 18025 EDCS units — Table 7.10 -- Unit Scale Dictionary for powers of 2¹⁰
• ANSI
  • Standard: BSR/IEEE 1541-200x, Prefixes for Binary Multiples
  • "kb (or “Kbit”) 1000 bits (kilobit)" 3. Abbreviations and Acronyms, ATIS Telecom Glossary 2000 American National Standards Institute, Inc.
• W3C
  • Units in MathML — Section 5.3.5 -- Prefix, and Appendix B — shows how to incorporate IEC prefixes into mathematical markup.
• SAE
  • "Thus 1 kbit = 103 bit = 1000 bit and not 210 = 1024 bit, where 1 kbit is one kilobit." [15]

new table

I think the new table "Approximate ratios between binary prefixes and their decimal equivalent" should be folded into the preexisting tables. ("> 10⁹ (7.4% error)" and so on) - Omegatron 14:22, Jun 6, 2005 (UTC)

Nominal 1.44 MB floppies and Windows XP

I've rewritten some text on the 1000*1024 hybrid "megabyte" used e.g. in floppies. This text was quite properly restored by User:Smyth after deletion by an anon. I just checked http://www.cdw.com and as of 2005 every vendor still refers to the standard floppy as nominally 1.44 MB.

Now, as for Windows XP, the situation is curioser and curioser. I was going to put something in the article but changed my mind pending any rational explanation of what Windows XP is doing.

As of the last time I tried, which was five minutes ago: when formatting a 3.5" floppy, Windows XP's formatting utility designates the diskette and the formatting operation as

3.5" 1.44MB 512 bytes/sector

That is, Windows XP still uses 1.44MB as the nominal capacity of a floppy.

But, after formatting, Properties reports the "capacity"

1457664 bytes 1.38 MB

(which is exactly 2847 sectors BTW... and only 1.4235 "hybrid" 1024000 megabytes, not 1.44, so obviously this is the usable capacity after the overhead of the FAT directory is deducted).

Now, 1457664 / 1024 / 1024 = 1.39014 MiB. That is, the second value is NOT consistent with MB meaning MiB, and cannot be explained as roundoff error since the fraction BOTH rounds AND truncates to 1.39 MiB, not 1.38 MiB.

Sounds like some kind of unaccountable sloppiness on Microsoft's part. I can come up with the following wild-ass guess. Suppose there was some point in the code's history in which the code computed 1457664 / 1024 / 1000 = 1.4235 hybrid "megabytes."

Now suppose that for some reason that was arbitrarily truncated to 1.42 MB for display.

Now suppose someone came along and decided that it should be displayed in 1024 * 1024-byte "MB."

Now suppose that instead of fixing the calculation they slapped on a correction.

Now suppose that for some reason they based the correction on 1.42 rather than 1.4235.

1.42 * 1000 / 1024 = 1.3867

Finally, suppose for some utterly unaccountable reason they decided to truncate rather than round... well, I guess you could get 1.38.

Given that all of the intermediate values in the appropriate calculations can be expressed EXACTLY in binary fractions OR decimals OR floating point with a very reasonable number of decimal places, this would seem to suggest sloppiness.

Yes, I remember the days when computers were still occasionally used for computing and programmers were expected to know the rudiments of mathematics and numerical analysis. Just hand me that slide rule, Sonny, and some carbon paper to put in my IBM Selectric. Dpbsmith (talk) 13:18, 21 Jun 2005 (UTC)

Oh, you must have missed the announcement. Computing isn't about math or accuracy anymore. It's now about obfuscation and elitism. - Omegatron 14:01, Jun 21, 2005 (UTC)

Every discipline or area of study suffers from this type of confusion when long standing traditions in a narrow area need to be standardized with other areas. For instance, in electrical engineering j is the unit for the imaginary number when everyone else uses i. Or "magnetic field strength" is not analgous to "electric field strength", the complementary term is "magnetic flux density" because someone else coined magnetic field strength for something else. Computer science is no different when it comes to SI prefixes and information measurement. --kudz75 00:46, 27 Jun 2005 (UTC)

It doesn't matter, but you're missing the point here. This is not a question of binary prefixes and which unit XP decided to use. The issue is that it is difficult to guess what Windows XP is doing because either it's calculating available space in MiB and getting the calculations wrong, or else it is accurately calculating something I don't understand. Which is very, very annoying as there is no good reason at all for the calculation to be inaccurate. Dpbsmith (talk) 01:21, 27 Jun 2005 (UTC)

They're probably calculating it by taking the number of bytes (1457664), dividing by 1024 (1423.5), truncating (1423), then dividing by 1024 (1,389648437) and rounding down... maybe. --Quadduc 01:52, 8 March 2006 (UTC)

POV discussion

There is a discussion going on at Talk:kilobyte about the POVness of kilo- = 1000, etc. - Omegatron 04:13, Jun 26, 2005 (UTC)

Which should we use in Wikipedia?

Discussion at Wikipedia:Village pump (policy)/Archive I#Unit Disagreement.2C MiB vs. MB. - Omegatron July 8, 2005 12:58 (UTC)

A vote has been started on whether Wikipedia should use these prefixes all the time, only in highly technical contexts, or never. - Omegatron 14:49, July 12, 2005 (UTC)

Popularity contest

User:Pmsyyz wrote (in bold): As of 2005 this naming convention [Kibi...] has not gained widespread use, but its use is growing. It is strongly supported by many standardization bodies, including IEEE and CIPM.

• Do we have a chart (google results over time maybe?) for this rate of change of usage of kibi-units?
  • Yes, it would be a good idea for someone to try to back this statement up. My guess is that it's true, but I wouldn't have put it in myself without some kind of source citation. Dpbsmith (talk) 12:26, 18 July 2005 (UTC)
• What would be the use of "many" standards bodies agreeing on something? Surely the whole idea of standards is that there's just one authorative standard for each thing that needs standardising?
  • Standards organizations frequently adopt each others' standards. In the computer field there are many examples of ANSI and ISO standards in which the text of the standard itself is identical. Of course, each organization follows its own rules and has its own committees to make the decision. When something like this does happen it's reasonably significant. Dpbsmith (talk) 12:26, 18 July 2005 (UTC)
• What does "supported by" mean in reference to standards? Does it mean they've each published a standard saying which style should be used?

Ojw 11:51, 18 July 2005 (UTC)

Have you read the #Organization recommendations section above you? - Omegatron 13:27, July 18, 2005 (UTC)

Why decimal bytes for HDD?

I think there is a non-neutral POV in this sentence, "Hard disk drive manufacturers state capacity in decimal units, so what is advertised as a "30 GB" hard drive will hold 30 × 10^9 bytes, roughly equal to 28×2^30 bytes (i.e. 28 GiB)."

It implies that HD manufacturers specifically use the decimal designation to inflate the capacity designation. While it may be true at this point in history, it almost certainly was not the original intent of the engineers who created the first hard drives. I propose something like, "Hard disk drive manufacturers state capacity in decimal units. Since most computer operating systems report drive usage and capacity in binary units, the difference causes an apparent loss between the advertised capacity and the formatted, usable capacity."

Second, since the article speculates on the tradition of using decimal units for HDD capacity, I don't think the immediate subsequent statement is accurate, "This usage has a long engineering tradition, and was probably not influenced by marketing. It arose because nothing about the physical structure of the disk drives makes power-of-two capacities natural: the number of platters, tracks and sectors per track are all continuously variable."

I propose, "The decimal unit capacity in hard disk drives follows the method used for serially accessed storage media which predated direct access storage media like hard disk drives. Paper punch cards could only be used in a serial fashion, like the magnetic tapes that followed. When a stream of data is stored, it's more logical to indicate how many thousands, millions, or billions of bytes have been stored versus how many 1024, 1,048,576, or 1,073,741,824 bytes have been. When the first hard disk drives were being developed, the decimal measurement was only natural since the hard disk drive served essentially the same function as punch cards and tapes. Thus today, any device that is addressed or seen as "storage" uses the decimal system to identify capacity."

JJLatWiki 18 July 2005 16:09 (UTC)

I agree it could be expanded or worded differently. It's a wiki, so be bold and change it to the way you like!

Also, can you sign your posts by typing ~~~~ after them? It will show your username and time of posting, like so - Omegatron 16:22, July 18, 2005 (UTC)

I couldn't find how to sign the edits, thanks.

I'm not yet comfortable with modifying an encyclopedia without a review and comment process. But, I'll take your advice...

JJLatWiki 17:19, 18 July 2005 (UTC)

If only vandals had your attitude...  :-)

Editing the article is the review and comment process. Other users (like me) have this article on their watchlist, and we see any changes made to it, and make any changes to your edits that we think are appropriate, then you change our edits, and so on. Read through some of the links on the welcome message on your talk page to find out more.

Asking on the talk page first if you are not sure about an edit is helpful, too, of course. Thanks. - Omegatron 18:27, July 18, 2005 (UTC)

For instance, I just made a few small changes to your addition, and others will come along and change them even more.

I assume you got this info from a website? Can you reference the pages by adding a link after each description? Just put the URL in [single brackets] and it will look like this: [16] - Omegatron 18:38, July 18, 2005 (UTC)

Is it correct to say "Since most computer operating systems report drive usage and capacity in binary units, ..."?

I happen to use Windows 2k which gives Properties of my C: drive as:

"Capacity 30,065,098,752 bytes 28.0 GB"

I think Microsoft would do the world a favor if they said 28.0 GiB but they certainly make it clear that this is a 30 billion byte drive. To support the "most computer operating systems" assertion I'd suggest we would have to review the various current utilities and properties on current OS's like XP, various LINUX, Apple X, etc. I suspect XP is not unlike Win2K so given XP has by far the largesst installed base, most will not hold up. BTW, my recollection is that MSDOS in all its flavors reported integer capacity with no prefixes or even commas :-). So most may also not be historically true. I'd like to see less definitive language which puts the source of the confusion at the inconsistent and/or unexplained usage of prefixes by the OS companies. I'm thinking about such language but I thought I'd post this talk before I edited the article. Yr thoughts?Tom94022 01:07, 18 May 2006 (UTC)

It still use binary units rather than decimal units even in your example (so for a user unclear about what a "giga" the only two numbers he can compare will appear inconsistent) and if you look at disk from explorer with "show details", you will only get the binary unit in "size" without the number written in full. Thus, I see no reason to reformulate the text. --Per Abrahamsen 07:25, 18 May 2006 (UTC)

The text is completely correct. If 2k/XP measured in decimal units, it would say;

"Capacity 30,065,098,752 bytes 30.0 GB" — Omegatron 11:27, 18 May 2006 (UTC)

We agree, 30,065,098,752 is decimal units! Windows is inconsistant, using both decimal units to 11 places and decimal units with non-standard binary prefixes. So the current text is incorrect since Windows does provide capacity in decimal units! I don't know much about Apple and I'm told that some Linux have a flag -T for ds that displays capacity with decimal prefixes. So a more correct sentance might be something like:

"Since some operating systems continue to use non-standard prefixes without explanation ..."

BTW, I note someone else has changed the text but IMHO it is still incorrect.Tom94022 20:50, 26 May 2006 (UTC)

Legal disputes

I added the Legal Disputes section. The information I provided is publically available in many places on the web. Within each case is exactly the kinds of debates going on here.

In my opinion, the difference though is that these people are attempting to take advantage of the debate and claim that corporations are literally charging "per megabyte" and that the corporate megabyte is smaller than the "commonly understood" megabyte and so the consumer is being deceived and cheated. In my opinion, the plaintiffs are filing frivolous lawsuits without merit.

Even though the capacity available to the user is (almost universally) less than the capacity designation, consumers do not pay a dollar amount per mega/gigabyte, therefore they are not paying something for nothing. Likewise, there are no hard drive or Flash drive manufacturers who designate capacity in the binary method and are therefore harmed by the other manufacturers' deception.

EVEN IF the capacity designation were accurate according to the binary method, and a 30GB drive had a formatted capacity of 32,212,254,720 bytes, it is a practical impossibility to store 32,212,254,720 bytes of user data on such a drive. Who is to be sued for THESE losses?

JJLatWiki 18:50, 18 July 2005 (UTC)

You make good points. But I would make a weak case for there being some kind of consumer issue here, however. The issue is this: can the consumer make a fair comparison? I don't think it's terribly farfetched to say that, left to themselves, companies will eventually engage in "specsmanship" in which they use deliberately confused, varying, and obfuscated measurements in order to make comparison difficult. It's no accident that supermarkets shelve all the General Foods cereals together, rather than putting all the different kinds of cornflakes together.

In the 1960s and 1970s stereo components makers were engaged in a kind of "horsepower race" and different companies used differing definitions of a "watt." There really was no easy way for the average consumer to know whether the a "20 watts per channel" system from one vendor was really comparable to a "20 watts per channel" system from another. In the case of stereo systems, where, all things being equal, a 20 watt system really costs quite a bit more than a 15 watt system, if a manufacturer could sell a 15 watt system and represent it as a 20 watt system by using a slightly different definition of "watt," the financial gains were meaningful.

It was very, very difficult to shop for fuel-efficient cars until the EPA tests were introduced, and similarly for household appliances.

In the case of disk drives, however, I don't think that different disk vendors are using different definitions of a gigabyte. As far as I know, a nominal 80 gig Maxstor drive is perfectly comparable to a nominal 80 gig Seagate.

A very analogous case is the tradition of measuring screen sizes by the diagonal. This made perfect sense in the 1950s, when picture tubes were, in fact, circular. People might have been disappointed or confused when they bought a nominal 21 inch set and found that the picture on it was only 16 inches wide, but everybody's 21 inch set was the same size. However, in the 1990s there were quite meaningful differences in usable picture size between different vendor's nominal 15" computer monitors.

There are good reasons for customers to want vendors to use a common, well-defined way of specifying disk capacity. Dpbsmith (talk) 19:10, 18 July 2005 (UTC)

In my opinion, corporations should be left to their own devices UNTIL they use "specsmanship" with an intent to deceive. Back when the speed national speed limit was reduced to 55, I don't think consumers were harmed by Chrysler's "zero to fifty" (or was it 55) acceleration scores. Obviously in that case, the measurement system was built into the rating.

"There are good reasons for customers to want vendors to use a common, well-defined way of specifying disk capacity." I quite agree. In the case of the hard disk drives, I think it was a common and well-defined system. It just didn't agree with what the new consumers expected and worse were being told by their OS vendor. The major Flash drive manufacturers used the same common and well-defined system, but it again didn't jive with consumer expectations that resulted from their chosen OS.

The binary spec is meaningless to consumers with regards to RAM except for direct comparisons to other computers being considered for purchase. With regards to disk storage, the binary spec is only meaningful because the OS vendor arbitrarily chose it. Remember when people actually bought software to add "virtual" RAM. I don't think it was ever licensed per megabyte, but what a glorious time that would have been for a memory warehouse. They could just ship paper licenses for 64KiB, 128KiB, 256KiB, 512KiB, and 1MiB of v-RAM. JJLatWiki 19:33, 18 July 2005 (UTC)