📄 wave file format.mht
字号:
From: <Saved by Microsoft Internet Explorer 5>
Subject: WAVE File Format
Date: Mon, 5 Dec 2005 15:09:03 +0800
MIME-Version: 1.0
Content-Type: text/html;
charset="gb2312"
Content-Transfer-Encoding: quoted-printable
Content-Location: http://www.borg.com/~jglatt/tech/wave.htm
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>WAVE File Format</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<META content=3D"MSHTML 6.00.2900.2769" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 vLink=3Dpurple aLink=3Dpurple link=3Dblue =
bgColor=3D#ffffff>WAVE File=20
Format is a file format for storing digital audio (waveform) data. It =
supports a=20
variety of bit resolutions, sample rates, and channels of audio. This =
format is=20
very popular upon IBM PC (clone) platforms, and is widely used in =
professional=20
programs that process digital audio waveforms. It takes into account =
some=20
peculiarities of the Intel CPU such as little endian byte order.=20
<P>This format uses Microsoft's version of the Electronic Arts =
Interchange File=20
Format method for storing data in "chunks". You should read the article =
<A=20
href=3D"http://www.borg.com/~jglatt/tech/aboutiff.htm">About Interchange =
File=20
Format</A> before proceeding.</P>
<H3><FONT color=3D#ff8040>Data Types</FONT></H3>
<P>A C-like language will be used to describe the data structures in the =
file. A=20
few extra data types that are not part of standard C, but which will be =
used in=20
this document, are:</P>
<TABLE cellSpacing=3D20 NOBORDER>
<TBODY>
<TR>
<TD vAlign=3Dtop><B>pstring</B></TD>
<TD>Pascal-style string, a one-byte count followed by that many text =
bytes. The total number of bytes in this data type should be even. =
A pad=20
byte can be added to the end of the text to accomplish this. This =
pad byte=20
is not reflected in the count.</TD></TR>
<TR>
<TD vAlign=3Dtop><B>ID</B></TD>
<TD>A chunk ID (ie, 4 ASCII bytes) as described in <A=20
href=3D"http://www.borg.com/~jglatt/tech/aboutiff.htm">About =
Interchange=20
File Format</A>.</TD></TR></TBODY></TABLE>
<P>Also note that when you see an array with no size specification =
(e.g., char=20
ckData[];), this indicates a variable-sized array in our C-like =
language. This=20
differs from standard C arrays.</P>
<H3><FONT color=3D#ff8040>Constants</FONT></H3>Decimal values are =
referred to as a=20
string of digits, for example 123, 0, 100 are all decimal numbers. =
Hexadecimal=20
values are preceded by a 0x - e.g., 0x0A, 0x1, 0x64.=20
<H3><FONT color=3D#ff8040>Data Organization</FONT></H3>All data is =
stored in 8-bit=20
bytes, arranged in Intel 80x86 (ie, little endian) format. The bytes of=20
multiple-byte values are stored with the low-order (ie, least =
significant) bytes=20
first. Data bits are as follows (ie, shown with bit numbers on top, =
"lsb" stands=20
for "least significant byte" and "msb" stands for "most significant =
byte"): <PRE> 7 6 5 4 3 2 1 0
+-----------------------+
char: | lsb |
+-----------------------+
7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8
+-----------------------+-----------------------+
short: | lsb byte 0 | byte 1 msb |
+-----------------------+-----------------------+
7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 =
18 17 16 31 30 29 28 27 26 25 24
=
+-----------------------+-----------------------+-----------------------+=
-----------------------+
long: | lsb byte 0 | byte 1 | byte 2 =
| byte 3 msb |
=
+-----------------------+-----------------------+-----------------------+=
-----------------------+
</PRE>
<H3><FONT color=3D#ff8040>File Structure</FONT></H3>A WAVE file is a =
collection of=20
a number of different types of chunks. There is a required Format ("fmt =
") chunk=20
which contains important parameters describing the waveform, such as its =
sample=20
rate. The Data chunk, which contains the actual waveform data, is also =
required.=20
All other chunks are optional. Among the other optional chunks are ones =
which=20
define cue points, list instrument parameters, store =
application-specific=20
information, etc. All of these chunks are described in detail in the =
following=20
sections of this document.
<P></P>
<P>All applications that use WAVE must be able to read the 2 required =
chunks and=20
can choose to selectively ignore the optional chunks. A program that =
copies a=20
WAVE should copy all of the chunks in the WAVE, even those it chooses =
not to=20
interpret.</P>
<P>There are no restrictions upon the order of the chunks within a WAVE =
file,=20
with the exception that the Format chunk must precede the Data chunk. =
Some=20
inflexibly written programs expect the Format chunk as the first chunk =
(after=20
the RIFF header) although they shouldn't because the specification =
doesn't=20
require this.</P>
<P>Here is a graphical overview of an example, minimal WAVE file. It =
consists of=20
a single WAVE containing the 2 required chunks, a Format and a Data =
Chunk.</P><PRE> __________________________
| RIFF WAVE Chunk |
| groupID =3D 'RIFF' |
| riffType =3D 'WAVE' |
| __________________ |
| | Format Chunk | |
| | ckID =3D 'fmt ' | |
| |__________________| |
| __________________ |
| | Sound Data Chunk | |
| | ckID =3D 'data' | |
| |__________________| |
|__________________________|
</PRE>
<H4>A Bastardized Standard</H4>The WAVE format is sort of a bastardized =
standard=20
that was concocted by too many "cooks" who didn't properly coordinate =
the=20
addition of "ingredients" to the "soup". Unlike with the AIFF standard =
which was=20
mostly designed by a small, coordinated group, the WAVE format has had =
all=20
manner of much-too-independent, uncoordinated aberrations inflicted upon =
it. The=20
net result is that there are far too many chunks that may be found in a =
WAVE=20
file -- many of them duplicating the same information found in other =
chunks (but=20
in an unnecessarily different way) simply because there have been too =
many=20
programmers who took too many liberties with unilaterally adding their =
own=20
additions to the WAVE format without properly coming to a concensus of =
what=20
everyone else needed (and therefore it encouraged an "every man for =
himself"=20
attitude toward adding things to this "standard"). One example is the =
Instrument=20
chunk versus the Sampler chunk. Another example is the Note versus Label =
chunks=20
in an Associated Data List. I don't even want to get into the totally=20
irresponsible proliferation of compressed formats. (ie, It seems like =
everyone=20
and his pet Dachshound has come up with some compressed version of =
storing wave=20
data -- like we need 100 different ways to do that). Furthermore, there =
are lots=20
of inconsistencies, for example how 8-bit data is unsigned, but 16-bit =
data is=20
signed.=20
<P>I've attempted to document only those aspects that you're very likely =
to=20
encounter in a WAVE file. I suggest that you concentrate upon these and =
refuse=20
to support the work of programmers who feel the need to deviate from a =
standard=20
with inconsistent, proprietary, self-serving, unnecessary extensions. =
Please do=20
your part to rein in half-assed programming.</P>
<H3><FONT color=3D#ff8040>Sample Points and Sample Frames</FONT></H3>A =
large part=20
of interpreting WAVE files revolves around the two concepts of sample =
points and=20
sample frames.=20
<P>A sample point is a value representing a sample of a sound at a given =
moment=20
in time. For waveforms with greater than 8-bit resolution, each sample =
point is=20
stored as a linear, 2's-complement value which may be from 9 to 32 bits =
wide (as=20
determined by the wBitsPerSample field in the Format Chunk, assuming PCM =
format=20
-- an uncompressed format). For example, each sample point of a 16-bit =
waveform=20
would be a 16-bit word (ie, two 8-bit bytes) where 32767 (0x7FFF) is the =
highest=20
value and -32768 (0x8000) is the lowest value. For 8-bit (or less) =
waveforms,=20
each sample point is a linear, unsigned byte where 255 is the highest =
value and=20
0 is the lowest value. Obviously, this signed/unsigned sample point =
discrepancy=20
between 8-bit and larger resolution waveforms was one of those "oops" =
scenarios=20
where some Microsoft employee decided to change the sign sometime after =
8-bit=20
wave files were common but 16-bit wave files hadn't yet appeared.</P>
<P>Because most CPU's read and write operations deal with 8-bit bytes, =
it was=20
decided that a sample point should be rounded up to a size which is a =
multiple=20
of 8 when stored in a WAVE. This makes the WAVE easier to read into =
memory. If=20
your ADC produces a sample point from 1 to 8 bits wide, a sample point =
should be=20
stored in a WAVE as an 8-bit byte (ie, unsigned char). If your ADC =
produces a=20
sample point from 9 to 16 bits wide, a sample point should be stored in =
a WAVE=20
as a 16-bit word (ie, signed short). If your ADC produces a sample point =
from 17=20
to 24 bits wide, a sample point should be stored in a WAVE as three =
bytes. If=20
your ADC produces a sample point from 25 to 32 bits wide, a sample point =
should=20
be stored in a WAVE as a 32-bit doubleword (ie, signed long). Etc.</P>
<P>Furthermore, the data bits should be left-justified, with any =
remaining (ie,=20
pad) bits zeroed. For example, consider the case of a 12-bit sample =
point. It=20
has 12 bits, so the sample point must be saved as a 16-bit word. Those =
12 bits=20
should be left-justified so that they become bits 4 to 15 inclusive, and =
bits 0=20
to 3 should be set to zero. Shown below is how a 12-bit sample point =
with a=20
value of binary 101000010111 is formatted left-justified as a 16-bit =
word.</P><PRE> ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ =
___ ___
| | | | | | | | | | | | | | | | |
| 1 0 1 0 0 0 0 1 0 1 1 1 0 0 0 0 |
|___|___|___|___|___|___|___|___|___|___|___|___|___|___|___|___|
<---------------------------------------------> =
<------------->
12 bit sample point is left justified rightmost
4 bits are
zero padded
</PRE>But note that, because the WAVE format uses Intel little endian =
byte=20
order, the LSB is stored first in the wave file as so: <PRE> ___ ___ ___ =
___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___
| | | | | | | | | | | | | | | | | |
| 0 1 1 1 0 0 0 0 | | 1 0 1 0 0 0 0 1 |
|___|___|___|___|___|___|___|___| |___|___|___|___|___|___|___|___|
<-------------> <-------------> =
<----------------------------->
bits 0 to 3 4 pad bits bits 4 to 11
</PRE>For multichannel sounds (for example, a stereo waveform), single =
sample=20
points from each channel are interleaved. For example, assume a stereo =
(ie, 2=20
channel) waveform. Instead of storing all of the sample points for the =
left=20
channel first, and then storing all of the sample points for the right =
channel=20
next, you "mix" the two channels' sample points together. You would =
store the=20
first sample point of the left channel. Next, you would store the first =
sample=20
point of the right channel. Next, you would store the second sample =
point of the=20
left channel. Next, you would store the second sample point of the right =
channel, and so on, alternating between storing the next sample point of =
each=20
channel. This is what is meant by interleaved data; you store the next =
sample=20
point of each of the channels in turn, so that the sample points that =
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -