Windows声音文件WAV文件格式General RIFF File Background
General RIFF description provided by
Robert Shuler <[email protected]>General RIFF File Format RIFF is a Windows file format for storing chunks of multi-media data, associated descriptions, formats, playlists, etc. The Waveform Audio File Format (.WAV) description below provides a precise description of the data unique to .WAV files, but does not describe the RIFF file structure within which the .WAV data is stored, so I have added this section to describe general RIFF files. If you read the raw file data you will need to process the structures described in this section. If you use RIFF access functions within windows, they will strip this information off and you will not see it.RIFF Header A RIFF file has an 8-byte RIFF header, identifying the file, and giving the residual length after the header (i.e. file_length - 8): struct {
char id[4]; // identifier string = "RIFF"
DWORD len; // remaining length after this header
} riff_hdr; The riff_hdr is immediately followed by a 4-byte data type identifier. For .WAV files this is "WAVE" as follows: char wave_id[4]; // WAVE file identifier = "WAVE"RIFF Chunks The entire remainder of the RIFF file is "chunks". Each chunk has an 8-byte chunk header identifying the type of chunk, and giving the length in bytes of the data following the chunk header, as follows:
struct { // CHUNK 8-byte header
char id[4]; // identifier, e.g. "fmt " or "data"
DWORD len; // remaining chunk length after header
} chunk_hdr;
// data bytes follow chunk header This concludes the general RIFF file description. The types of chunks to expect for .WAV files (unexpected chunks should be allowed for in processing RIFF files) and the format of the content data of each chunk type are described in the sections that follow.
RIFF WAVE (.WAV) file formatFrom: Rob Ryan <[email protected]>
Organization: Brown University I found the following lengthy excerpt in a document rmrtf.zrt (it is actually a .zip file) in the vendor/microsoft/multimedia subdirectory at the ftp.uu.net ftp site. It is presumably beyond the scope (in terms of the amount of detail) of your document, but nevertheless, I thought that it may help you in including references to the Windows .WAV format in the future. Let me know if you have any questions/comments. Again, thank you for your helpful summary. Keep it up! The following is taken from RIFFMCI.RTF, "Multimedia Programming Interface and Data Specification v1.0", a Windows RTF (Rich Text Format) file contained in the .zip file, RMRTF.ZRT. The original document is quite long and this constitutes pages 83-95 of the text format version (starting on roughly page 58 of the RTF version). If you would like a PostScript version, let me know and I can make one up for you.Waveform Audio File Format (WAVE) This section describes the Waveform format, which is used to represent digitized sound. The WAVE form is defined as follows. Programs must expect(and ignore) any unknown chunks encountered, as with all RIFF forms. However, <fmt-ck> must always occur before <wave-data>, and both of these chunks are mandatory in a WAVE file.<WAVE-form> ->
RIFF( 'WAVE'
<fmt-ck> // Format
[<fact-ck>] // Fact chunk
[<cue-ck>] // Cue points
[<playlist-ck>] // Playlist
[<assoc-data-list>] // Associated data list
<wave-data> ) // Wave dataWAVE chunks are described in the following sections.WAVE Format Chunk The WAVE format chunk <fmt-ck> specifies the format of the <wave-data>. The <fmt-ck> is defined as follows:<fmt-ck> -> fmt( <common-fields> <format-specific-fields> )<common-fields> ->
struct
{
WORD wFormatTag; // Format category
WORD wChannels; // Number of channels
DWORDdwSamplesPerSec; // Sampling rate
DWORDdwAvgBytesPerSec; // For buffer estimation
WORD wBlockAlign; // Data block size
}Common Fields Chunk The fields in the <common-fields> chunk are as follows: Field Description
wFormatTag A number indicating the WAVE format category of
the file. The content of the <format-specific-fields> portion of the `fmt' chunk, and the interpretation of the waveform data,on this value. must register any new WAVE format categories. See ``Registering Multimedia Formats'' in Chapter 1, ``Overview of Multimedia,'' for information on registering WAVE format categories. ``Wave Format Categories,'' following this section, lists the currently defined WAVE format categories. wChannels The number of channels represented in the
waveform data, such as 1 for mono or 2 for stereo. dwSamplesPerSec The sampling rate (in samples per second)
at which each channel should be played. dwAvgBytesPerSec The average number of bytes per second
at which the waveform data should be transferred. Playback software can estimate the buffer size using this value. wBlockAlign The block alignment (in bytes) of the waveform
data. Playback software needs to process a multiple of wBlockAlign bytes of data at a time, so the value of wBlockAlign can be used for buffer alignment.Format Specific Fields Chunk The <format-specific-fields> consists of zero or more bytes of parameters. Which parameters occur depends on the WAVE format category-see the following section for details. Playback software should be written to allow for (and ignore) any unknown <format-specific-fields> parameters that occur at the end of this field.WAVE Format Categories The format category of a WAVE file is specified by the value of the wFormatTag field of the `fmt' chunk. The representation of data in <wave-data>, and the content of the <format-specific-fields> of the `fmt' chunk, depend on the format category. The currently defined open non-proprietary WAVE format categories are as follows:wFormatTag Value Format Category_WAVE_FORMAT_PCM (0x0001) Microsoft Pulse Code Modulation (PCM) The following are the registered proprietary WAVE format categories:wFormatTag Value Format Category_FORMAT_MULAW (0x0101) IBM mu-law format
IBM_FORMAT_ALAW (0x0102) IBM a-law format
IBM_FORMAT_ADPCM (0x0103) IBM AVC Adaptive Differential PCM formatMicrosoft WAVE_FORMAT_PCM format The following sections describe the Microsoft WAVE_FORMAT_PCM format. If the wFormatTag field of the <fmt-ck> is set to WAVE_FORMAT_PCM, then the waveform data consists of samples represented in pulse code modulation (PCM) format. For PCM waveform data, the <format-specific-fields> is defined as follows:<PCM-format-specific> ->
struct
{
WORD wBitsPerSample; // Sample size
} The wBitsPerSample field specifies the number of bits of data used to represent each sample of each channel. If there are multiple channels, the sample size is the same for each channel. For PCM data, the wAvgBytesPerSec field of the `fmt' chunk should be equal to the following formula rounded up to the next whole number: wBitsPerSample
wChannels x wBitsPerSecond x --------------
8 The wBlockAlign field should be equal to the following formula, rounded to the next whole number: wBitsPerSample
wChannels x --------------
8Data Packing for PCM WAVE Files In a single-channel WAVE file, samples are stored consecutively. For stereo WAVE files, channel 0 represents the left channel, and channel 1 represents the right channel. The speaker position mapping for more than two channels is currently undefined. In multiple-channel WAVE files, samples are interleaved. The following diagrams show the data packing for a 8-bit mono and stereo WAVE files:Data Packing for 8-Bit Mono PCM: Sample 1 Sample 2 Sample 3 Sample 4
--------- --------- --------- ---------
Channel 0 Channel 0 Channel 0 Channel 0Data Packing for 8-Bit Stereo PCM: Sample 1 Sample 2
--------------------- ---------------------
Channel 0 Channel 1 Channel 0 Channel 0
(left) (right) (left) (right) The following diagrams show the data packing for 16-bit mono and stereo WAVE files:Data Packing for 16-Bit Mono PCM: Sample 1 Sample 2
---------------------- ----------------------
Channel 0 Channel 0 Channel 0 Channel 0
low-order high-order low-order high-order
byte byte byte byteData Packing for 16-Bit Stereo PCM: Sample 1
---------------------------------------------
Channel 0 Channel 0 Channel 1 Channel 1
(left) (left) (right) (right)
low-order high-order low-order high-order
byte byte byte byteData Format of the Samples Each sample is contained in an integer i. The size of i is the smallest number of bytes required to contain the specified sample size. The least significant byte is stored first. The bits that represent the sample amplitude are stored in the most significant bits of i, and the remaining bits are set to zero. For example, if the sample size (recorded in nBitsPerSample) is 12 bits, then each sample is stored in a two-byte integer. The least significant four bits of the first (least significant) byte is set to zero. The data format and maximum and minimums values for PCM waveform samples of various sizes are as follows: SampleSize DataFormat Max.Value MinimumValue
One to Unsigned 255 (0xFF) 0
eight bits integer Nine or Signed Largest Most negative
more bits integer i positive value of i
value of i For example, the maximum, minimum, and midpoint values for 8-bit and 16-bit PCM waveform data are as follows: Format Max.Value Min.Value MidpointValue
8-bit PCM 255 (0xFF) 0 128 (0x80)
16-bit PCM 32767 -32768 0
(0x7FFF) (-0x8000)Examples of PCM WAVE Files Example of a PCM WAVE file with 11.025 kHz sampling rate, mono, 8 bits per sample: RIFF( 'WAVE' fmt(1, 1, 11025, 11025, 1, 8)
data( <wave-data> ) ) Example of a PCM WAVE file with 22.05 kHz sampling rate, stereo, 8 bits per sample: RIFF( 'WAVE' fmt(1, 2, 22050, 44100, 2, 8)
data( <wave-data> ) ) Example of a PCM WAVE file with 44.1 kHz sampling rate, mono, 20 bits per sample: RIFF( 'WAVE' INFO(INAM("O Canada"Z))
fmt(1, 1, 44100, 132300, 3, 20)
data( <wave-data> ) )Storage of WAVE Data The <wave-data> contains the waveform data. It is defined as follows: <wave-data> -> { <data-ck> : <data-list> }
<data-ck> -> data( <wave-data> )
<wave-list> -> LIST( 'wavl' { <data-ck> : // Wave samples
<silence-ck> }... ) // Silence
<silence-ck> -> slnt( <dwSamples:DWORD> ) // Count of
// silent samples Note: The `slnt' chunk represents silence, not necessarily a repeated zero volume or baseline sample. In 16-bit PCM data, if the last sample value played before the silence section is a 10000, then if data is still output to the D to A converter, it must maintain the 10000 value. If a zero value is used, a click may be heard at the start and end of the silence section. If play begins at a silence section, then a zero value might be used since no other information is available. A click might be created if the data following the silent section starts with a nonzero value.FACT Chunk The <fact-ck> fact chunk stores important information about the contents of the WAVE file. This chunk is defined as follows: <fact-ck> -> fact( <dwFileSize:DWORD> ) // Number of samples The `fact'' chunk is required if the waveform data is contained in a `wavl'' LIST chunk and for all compressed audio formats. The chunk is not required for PCM files using the `data'' chunk format. The "fact" chunk will be expanded to include any other information required by future WAVE formats. Added fields will appear following the <dwFileSize> field. Applications can use the chunk size field to determine which fields are present.Cue-Points Chunk The <cue-ck> cue-points chunk identifies a series of positions in the waveform data stream. The <cue-ck> is defined as follows: <cue-ck> -> cue( <dwCuePoints:DWORD> // Count of cue points
<cue-point>... ) // Cue-point table
<cue-point> -> struct
{
DWORD dwName;
DWORD dwPosition;
FOURCC fccChunk;
DWORD dwChunkStart;
DWORD dwBlockStart;
DWORD dwSampleOffset;
} The <cue-point> fields are as follows: Field Description
dwName Specifies the cue point name. Each
<cue-point> record must have a unique dwName field.
dwPosition Specifies the sample position of the cue
point.This is the sequential sample number within the play order. See ``Playlist Chunk,'' later in this document, for a discussion of the play order.
fccChunk Specifies the name or chunk ID of thechunk
containing the cue point.
dwChunkStart Specifies the file position of the start of
the chunk containing the cue point. This is a byte offset relative to the start of the data section of the `wavl' LIST chunk.
dwBlockStart Specifies the file position of the start of
the block containing the position. This is a byte offset relative to the start of the data section of the `wavl' LIST chunk.
dwSampleOffset Specifies the sample offset of the cuepoint
relative to the start of the block.Examples of File Position Values The following table describes the <cue-point> field values for a WAVE file containing multiple `data' and `slnt' chunks enclosed in a `wavl' LIST chunk:CuePointLoc. Field Value
a `slnt' fccChunk FOURCC value `slnt'. dwChunkStart File position of the`slnt' chunk
relative to the start of the data section in the `wavl' LIST chunk. dwBlockStart File position of the datasection of
the `slnt' chunk relative to the start of the data section of the `wavl' LIST chunk.
dwSampleOffset Sample position of the cuepoint
relative to the start of the `slnt' chunk.In a PCM fccChunk FOURCC value `data'.
`data' chunk
dwChunkStart File position of the`data' chunk
relative to the start of the data section in the `wavl' LIST chunk. dwBlockStart File position of the cuepoint
relative to the start of the data section of the `wavl' LIST chunk. dwSampleOffset Zero value.In a fccChunk FOURCC value `data'.
compressed
`data' chunk
dwChunkStart File position of the startof the
`data' chunk relative to the start of the data section of the `wavl' LIST chunk. dwBlockStart File position of theenclosing block
relative to the start of the data section of the `wavl' LIST chunk. The software can begin the decompression at this point. dwSampleOffset Sample position of the cuepoint
relative to the start of the block. The following table describes the <cue-point> field values for a WAVE file containing a single `data' chunk:CuePointLoc. Field Value
Within PCM fccChunk FOURCC value `data'.
data
dwChunkStart Zero value. dwBlockStart Zero value. dwSampleOffset Sample position of the cuepoint
relative to the start of the `data' chunk.In a fccChunk FOURCC value `data'.
compressed
`data' chunk
dwChunkStart Zero value. dwBlockStart File position of theenclosing block
relative to the start of the `data' chunk. The software can begin the decompression at this point. dwSampleOffset Sample position of the cuepoint
relative to the start of the block.Playlist Chunk The <playlist-ck> playlist chunk specifies a play order for a series of cue points. The <playlist-ck> is defined as follows:<playlist-ck> -> plst( <dwSegments:DWORD> // Count of play segments
<play-segment>... ) // Play-segment table<play-segment> -> struct {
DWORD dwName;
DWORD dwLength;
DWORD dwLoops;
} The <play-segment> fields are as follows: Field Description
dwName Specifies the cue point name. This value
must match one of the names listed in the <cue-ck> cue-point table. dwLength Specifies the length of the section
in samples. dwLoops Specifies the number of times to play
the section.Associated Data Chunk The <assoc-data-list> associated data list provides the ability to attach information like labels to sections of the waveform data stream. The <assoc-data-list> is defined as follows:<assoc-data-list> -> LIST('adtl'
<labl-ck> // Label
<note-ck> // Note
<ltxt-ck> // Text with data length
<file-ck> ) // Media file<labl-ck> -> labl( <dwName:DWORD> <data:ZSTR> )<note-ck> -> note( <dwName:DWORD> <data:ZSTR> )<ltxt-ck> -> ltxt( <dwName:DWORD>
<dwSampleLength:DWORD>
<dwPurpose:DWORD>
<wCountry:WORD>
<wLanguage:WORD>
<wDialect:WORD>
<wCodePage:WORD>
<data:BYTE>... )<file-ck> -> file( <dwName:DWORD>
<dwMedType:DWORD>
<fileData:BYTE>...)Label and Note Information The `labl' and `note' chunks have similar fields. The `labl' chunk contains a label, or title, to associate with a cue point. The `note' chunk contains comment text for a cue point. The fields are as follows: Field Description
dwName Specifies the cue point name. This
value must match one of the names listed in the <cue-ck> cue-point table. data Specifies a NULL-terminated string
containing a text label (for the `labl' chunk) or comment text (for the `note' chunk).Text with Data Length Information The `ltxt'' chunk contains text that is associated with a data segment of specific length. The chunk fields are as follows: Field Description
dwName Specifies the cue point name. This
value must match one of the names listed in the <cue-ck> cue-point table. dwSampleLength Specifies the number of samples in the
segment of waveform data. dwPurpose Specifies the type or purpose of the
text. For example, dwPurpose can specify a FOURCC code like `scrp' for script text or `capt' for close-caption text. wCountry Specifies the country code for the
text. See ``Country Codes'' in Chapter 2, ``Resource Interchange File Format,'' for a current list of country codes. wLanguage, Specify the language and dialect codes
wDialect for the text. See ``Language and Dialect
Codes'' in Chapter 2, ``Resource Interchange File Format,'' for a current list of language and dialect codes. wCodePage Specifies the code page for the text.Embedded File Information The `file' chunk contains information described in other file formats (for example, an `RDIB' file or an ASCII text file). The chunk fields are as follows: Field Description
dwName Specifies the cue point name. This value
must match one of the names listed in the <cue-ck> cue-point table. dwMedType Specifies the file type contained in the
fileData field. If the fileData section contains a RIFF form, the dwMedType field is the same as the RIFF form type for the file. This field can contain a zero value. fileData Contains the media file.
General RIFF description provided by
Robert Shuler <[email protected]>General RIFF File Format RIFF is a Windows file format for storing chunks of multi-media data, associated descriptions, formats, playlists, etc. The Waveform Audio File Format (.WAV) description below provides a precise description of the data unique to .WAV files, but does not describe the RIFF file structure within which the .WAV data is stored, so I have added this section to describe general RIFF files. If you read the raw file data you will need to process the structures described in this section. If you use RIFF access functions within windows, they will strip this information off and you will not see it.RIFF Header A RIFF file has an 8-byte RIFF header, identifying the file, and giving the residual length after the header (i.e. file_length - 8): struct {
char id[4]; // identifier string = "RIFF"
DWORD len; // remaining length after this header
} riff_hdr; The riff_hdr is immediately followed by a 4-byte data type identifier. For .WAV files this is "WAVE" as follows: char wave_id[4]; // WAVE file identifier = "WAVE"RIFF Chunks The entire remainder of the RIFF file is "chunks". Each chunk has an 8-byte chunk header identifying the type of chunk, and giving the length in bytes of the data following the chunk header, as follows:
struct { // CHUNK 8-byte header
char id[4]; // identifier, e.g. "fmt " or "data"
DWORD len; // remaining chunk length after header
} chunk_hdr;
// data bytes follow chunk header This concludes the general RIFF file description. The types of chunks to expect for .WAV files (unexpected chunks should be allowed for in processing RIFF files) and the format of the content data of each chunk type are described in the sections that follow.
RIFF WAVE (.WAV) file formatFrom: Rob Ryan <[email protected]>
Organization: Brown University I found the following lengthy excerpt in a document rmrtf.zrt (it is actually a .zip file) in the vendor/microsoft/multimedia subdirectory at the ftp.uu.net ftp site. It is presumably beyond the scope (in terms of the amount of detail) of your document, but nevertheless, I thought that it may help you in including references to the Windows .WAV format in the future. Let me know if you have any questions/comments. Again, thank you for your helpful summary. Keep it up! The following is taken from RIFFMCI.RTF, "Multimedia Programming Interface and Data Specification v1.0", a Windows RTF (Rich Text Format) file contained in the .zip file, RMRTF.ZRT. The original document is quite long and this constitutes pages 83-95 of the text format version (starting on roughly page 58 of the RTF version). If you would like a PostScript version, let me know and I can make one up for you.Waveform Audio File Format (WAVE) This section describes the Waveform format, which is used to represent digitized sound. The WAVE form is defined as follows. Programs must expect(and ignore) any unknown chunks encountered, as with all RIFF forms. However, <fmt-ck> must always occur before <wave-data>, and both of these chunks are mandatory in a WAVE file.<WAVE-form> ->
RIFF( 'WAVE'
<fmt-ck> // Format
[<fact-ck>] // Fact chunk
[<cue-ck>] // Cue points
[<playlist-ck>] // Playlist
[<assoc-data-list>] // Associated data list
<wave-data> ) // Wave dataWAVE chunks are described in the following sections.WAVE Format Chunk The WAVE format chunk <fmt-ck> specifies the format of the <wave-data>. The <fmt-ck> is defined as follows:<fmt-ck> -> fmt( <common-fields> <format-specific-fields> )<common-fields> ->
struct
{
WORD wFormatTag; // Format category
WORD wChannels; // Number of channels
DWORDdwSamplesPerSec; // Sampling rate
DWORDdwAvgBytesPerSec; // For buffer estimation
WORD wBlockAlign; // Data block size
}Common Fields Chunk The fields in the <common-fields> chunk are as follows: Field Description
wFormatTag A number indicating the WAVE format category of
the file. The content of the <format-specific-fields> portion of the `fmt' chunk, and the interpretation of the waveform data,on this value. must register any new WAVE format categories. See ``Registering Multimedia Formats'' in Chapter 1, ``Overview of Multimedia,'' for information on registering WAVE format categories. ``Wave Format Categories,'' following this section, lists the currently defined WAVE format categories. wChannels The number of channels represented in the
waveform data, such as 1 for mono or 2 for stereo. dwSamplesPerSec The sampling rate (in samples per second)
at which each channel should be played. dwAvgBytesPerSec The average number of bytes per second
at which the waveform data should be transferred. Playback software can estimate the buffer size using this value. wBlockAlign The block alignment (in bytes) of the waveform
data. Playback software needs to process a multiple of wBlockAlign bytes of data at a time, so the value of wBlockAlign can be used for buffer alignment.Format Specific Fields Chunk The <format-specific-fields> consists of zero or more bytes of parameters. Which parameters occur depends on the WAVE format category-see the following section for details. Playback software should be written to allow for (and ignore) any unknown <format-specific-fields> parameters that occur at the end of this field.WAVE Format Categories The format category of a WAVE file is specified by the value of the wFormatTag field of the `fmt' chunk. The representation of data in <wave-data>, and the content of the <format-specific-fields> of the `fmt' chunk, depend on the format category. The currently defined open non-proprietary WAVE format categories are as follows:wFormatTag Value Format Category_WAVE_FORMAT_PCM (0x0001) Microsoft Pulse Code Modulation (PCM) The following are the registered proprietary WAVE format categories:wFormatTag Value Format Category_FORMAT_MULAW (0x0101) IBM mu-law format
IBM_FORMAT_ALAW (0x0102) IBM a-law format
IBM_FORMAT_ADPCM (0x0103) IBM AVC Adaptive Differential PCM formatMicrosoft WAVE_FORMAT_PCM format The following sections describe the Microsoft WAVE_FORMAT_PCM format. If the wFormatTag field of the <fmt-ck> is set to WAVE_FORMAT_PCM, then the waveform data consists of samples represented in pulse code modulation (PCM) format. For PCM waveform data, the <format-specific-fields> is defined as follows:<PCM-format-specific> ->
struct
{
WORD wBitsPerSample; // Sample size
} The wBitsPerSample field specifies the number of bits of data used to represent each sample of each channel. If there are multiple channels, the sample size is the same for each channel. For PCM data, the wAvgBytesPerSec field of the `fmt' chunk should be equal to the following formula rounded up to the next whole number: wBitsPerSample
wChannels x wBitsPerSecond x --------------
8 The wBlockAlign field should be equal to the following formula, rounded to the next whole number: wBitsPerSample
wChannels x --------------
8Data Packing for PCM WAVE Files In a single-channel WAVE file, samples are stored consecutively. For stereo WAVE files, channel 0 represents the left channel, and channel 1 represents the right channel. The speaker position mapping for more than two channels is currently undefined. In multiple-channel WAVE files, samples are interleaved. The following diagrams show the data packing for a 8-bit mono and stereo WAVE files:Data Packing for 8-Bit Mono PCM: Sample 1 Sample 2 Sample 3 Sample 4
--------- --------- --------- ---------
Channel 0 Channel 0 Channel 0 Channel 0Data Packing for 8-Bit Stereo PCM: Sample 1 Sample 2
--------------------- ---------------------
Channel 0 Channel 1 Channel 0 Channel 0
(left) (right) (left) (right) The following diagrams show the data packing for 16-bit mono and stereo WAVE files:Data Packing for 16-Bit Mono PCM: Sample 1 Sample 2
---------------------- ----------------------
Channel 0 Channel 0 Channel 0 Channel 0
low-order high-order low-order high-order
byte byte byte byteData Packing for 16-Bit Stereo PCM: Sample 1
---------------------------------------------
Channel 0 Channel 0 Channel 1 Channel 1
(left) (left) (right) (right)
low-order high-order low-order high-order
byte byte byte byteData Format of the Samples Each sample is contained in an integer i. The size of i is the smallest number of bytes required to contain the specified sample size. The least significant byte is stored first. The bits that represent the sample amplitude are stored in the most significant bits of i, and the remaining bits are set to zero. For example, if the sample size (recorded in nBitsPerSample) is 12 bits, then each sample is stored in a two-byte integer. The least significant four bits of the first (least significant) byte is set to zero. The data format and maximum and minimums values for PCM waveform samples of various sizes are as follows: SampleSize DataFormat Max.Value MinimumValue
One to Unsigned 255 (0xFF) 0
eight bits integer Nine or Signed Largest Most negative
more bits integer i positive value of i
value of i For example, the maximum, minimum, and midpoint values for 8-bit and 16-bit PCM waveform data are as follows: Format Max.Value Min.Value MidpointValue
8-bit PCM 255 (0xFF) 0 128 (0x80)
16-bit PCM 32767 -32768 0
(0x7FFF) (-0x8000)Examples of PCM WAVE Files Example of a PCM WAVE file with 11.025 kHz sampling rate, mono, 8 bits per sample: RIFF( 'WAVE' fmt(1, 1, 11025, 11025, 1, 8)
data( <wave-data> ) ) Example of a PCM WAVE file with 22.05 kHz sampling rate, stereo, 8 bits per sample: RIFF( 'WAVE' fmt(1, 2, 22050, 44100, 2, 8)
data( <wave-data> ) ) Example of a PCM WAVE file with 44.1 kHz sampling rate, mono, 20 bits per sample: RIFF( 'WAVE' INFO(INAM("O Canada"Z))
fmt(1, 1, 44100, 132300, 3, 20)
data( <wave-data> ) )Storage of WAVE Data The <wave-data> contains the waveform data. It is defined as follows: <wave-data> -> { <data-ck> : <data-list> }
<data-ck> -> data( <wave-data> )
<wave-list> -> LIST( 'wavl' { <data-ck> : // Wave samples
<silence-ck> }... ) // Silence
<silence-ck> -> slnt( <dwSamples:DWORD> ) // Count of
// silent samples Note: The `slnt' chunk represents silence, not necessarily a repeated zero volume or baseline sample. In 16-bit PCM data, if the last sample value played before the silence section is a 10000, then if data is still output to the D to A converter, it must maintain the 10000 value. If a zero value is used, a click may be heard at the start and end of the silence section. If play begins at a silence section, then a zero value might be used since no other information is available. A click might be created if the data following the silent section starts with a nonzero value.FACT Chunk The <fact-ck> fact chunk stores important information about the contents of the WAVE file. This chunk is defined as follows: <fact-ck> -> fact( <dwFileSize:DWORD> ) // Number of samples The `fact'' chunk is required if the waveform data is contained in a `wavl'' LIST chunk and for all compressed audio formats. The chunk is not required for PCM files using the `data'' chunk format. The "fact" chunk will be expanded to include any other information required by future WAVE formats. Added fields will appear following the <dwFileSize> field. Applications can use the chunk size field to determine which fields are present.Cue-Points Chunk The <cue-ck> cue-points chunk identifies a series of positions in the waveform data stream. The <cue-ck> is defined as follows: <cue-ck> -> cue( <dwCuePoints:DWORD> // Count of cue points
<cue-point>... ) // Cue-point table
<cue-point> -> struct
{
DWORD dwName;
DWORD dwPosition;
FOURCC fccChunk;
DWORD dwChunkStart;
DWORD dwBlockStart;
DWORD dwSampleOffset;
} The <cue-point> fields are as follows: Field Description
dwName Specifies the cue point name. Each
<cue-point> record must have a unique dwName field.
dwPosition Specifies the sample position of the cue
point.This is the sequential sample number within the play order. See ``Playlist Chunk,'' later in this document, for a discussion of the play order.
fccChunk Specifies the name or chunk ID of thechunk
containing the cue point.
dwChunkStart Specifies the file position of the start of
the chunk containing the cue point. This is a byte offset relative to the start of the data section of the `wavl' LIST chunk.
dwBlockStart Specifies the file position of the start of
the block containing the position. This is a byte offset relative to the start of the data section of the `wavl' LIST chunk.
dwSampleOffset Specifies the sample offset of the cuepoint
relative to the start of the block.Examples of File Position Values The following table describes the <cue-point> field values for a WAVE file containing multiple `data' and `slnt' chunks enclosed in a `wavl' LIST chunk:CuePointLoc. Field Value
a `slnt' fccChunk FOURCC value `slnt'. dwChunkStart File position of the`slnt' chunk
relative to the start of the data section in the `wavl' LIST chunk. dwBlockStart File position of the datasection of
the `slnt' chunk relative to the start of the data section of the `wavl' LIST chunk.
dwSampleOffset Sample position of the cuepoint
relative to the start of the `slnt' chunk.In a PCM fccChunk FOURCC value `data'.
`data' chunk
dwChunkStart File position of the`data' chunk
relative to the start of the data section in the `wavl' LIST chunk. dwBlockStart File position of the cuepoint
relative to the start of the data section of the `wavl' LIST chunk. dwSampleOffset Zero value.In a fccChunk FOURCC value `data'.
compressed
`data' chunk
dwChunkStart File position of the startof the
`data' chunk relative to the start of the data section of the `wavl' LIST chunk. dwBlockStart File position of theenclosing block
relative to the start of the data section of the `wavl' LIST chunk. The software can begin the decompression at this point. dwSampleOffset Sample position of the cuepoint
relative to the start of the block. The following table describes the <cue-point> field values for a WAVE file containing a single `data' chunk:CuePointLoc. Field Value
Within PCM fccChunk FOURCC value `data'.
data
dwChunkStart Zero value. dwBlockStart Zero value. dwSampleOffset Sample position of the cuepoint
relative to the start of the `data' chunk.In a fccChunk FOURCC value `data'.
compressed
`data' chunk
dwChunkStart Zero value. dwBlockStart File position of theenclosing block
relative to the start of the `data' chunk. The software can begin the decompression at this point. dwSampleOffset Sample position of the cuepoint
relative to the start of the block.Playlist Chunk The <playlist-ck> playlist chunk specifies a play order for a series of cue points. The <playlist-ck> is defined as follows:<playlist-ck> -> plst( <dwSegments:DWORD> // Count of play segments
<play-segment>... ) // Play-segment table<play-segment> -> struct {
DWORD dwName;
DWORD dwLength;
DWORD dwLoops;
} The <play-segment> fields are as follows: Field Description
dwName Specifies the cue point name. This value
must match one of the names listed in the <cue-ck> cue-point table. dwLength Specifies the length of the section
in samples. dwLoops Specifies the number of times to play
the section.Associated Data Chunk The <assoc-data-list> associated data list provides the ability to attach information like labels to sections of the waveform data stream. The <assoc-data-list> is defined as follows:<assoc-data-list> -> LIST('adtl'
<labl-ck> // Label
<note-ck> // Note
<ltxt-ck> // Text with data length
<file-ck> ) // Media file<labl-ck> -> labl( <dwName:DWORD> <data:ZSTR> )<note-ck> -> note( <dwName:DWORD> <data:ZSTR> )<ltxt-ck> -> ltxt( <dwName:DWORD>
<dwSampleLength:DWORD>
<dwPurpose:DWORD>
<wCountry:WORD>
<wLanguage:WORD>
<wDialect:WORD>
<wCodePage:WORD>
<data:BYTE>... )<file-ck> -> file( <dwName:DWORD>
<dwMedType:DWORD>
<fileData:BYTE>...)Label and Note Information The `labl' and `note' chunks have similar fields. The `labl' chunk contains a label, or title, to associate with a cue point. The `note' chunk contains comment text for a cue point. The fields are as follows: Field Description
dwName Specifies the cue point name. This
value must match one of the names listed in the <cue-ck> cue-point table. data Specifies a NULL-terminated string
containing a text label (for the `labl' chunk) or comment text (for the `note' chunk).Text with Data Length Information The `ltxt'' chunk contains text that is associated with a data segment of specific length. The chunk fields are as follows: Field Description
dwName Specifies the cue point name. This
value must match one of the names listed in the <cue-ck> cue-point table. dwSampleLength Specifies the number of samples in the
segment of waveform data. dwPurpose Specifies the type or purpose of the
text. For example, dwPurpose can specify a FOURCC code like `scrp' for script text or `capt' for close-caption text. wCountry Specifies the country code for the
text. See ``Country Codes'' in Chapter 2, ``Resource Interchange File Format,'' for a current list of country codes. wLanguage, Specify the language and dialect codes
wDialect for the text. See ``Language and Dialect
Codes'' in Chapter 2, ``Resource Interchange File Format,'' for a current list of language and dialect codes. wCodePage Specifies the code page for the text.Embedded File Information The `file' chunk contains information described in other file formats (for example, an `RDIB' file or an ASCII text file). The chunk fields are as follows: Field Description
dwName Specifies the cue point name. This value
must match one of the names listed in the <cue-ck> cue-point table. dwMedType Specifies the file type contained in the
fileData field. If the fileData section contains a RIFF form, the dwMedType field is the same as the RIFF form type for the file. This field can contain a zero value. fileData Contains the media file.
General RIFF description provided by
Robert Shuler <[email protected]>General RIFF File Format RIFF is a Windows file format for storing chunks of multi-media data, associated descriptions, formats, playlists, etc. The Waveform Audio File Format (.WAV) description below provides a precise description of the data unique to .WAV files, but does not describe the RIFF file structure within which the .WAV data is stored, so I have added this section to describe general RIFF files. If you read the raw file data you will need to process the structures described in this section. If you use RIFF access functions within windows, they will strip this information off and you will not see it.RIFF Header A RIFF file has an 8-byte RIFF header, identifying the file, and giving the residual length after the header (i.e. file_length - 8): struct {
char id[4]; // identifier string = "RIFF"
DWORD len; // remaining length after this header
} riff_hdr; The riff_hdr is immediately followed by a 4-byte data type identifier. For .WAV files this is "WAVE" as follows: char wave_id[4]; // WAVE file identifier = "WAVE"RIFF Chunks The entire remainder of the RIFF file is "chunks". Each chunk has an 8-byte chunk header identifying the type of chunk, and giving the length in bytes of the data following the chunk header, as follows:
struct { // CHUNK 8-byte header
char id[4]; // identifier, e.g. "fmt " or "data"
DWORD len; // remaining chunk length after header
} chunk_hdr;
// data bytes follow chunk header This concludes the general RIFF file description. The types of chunks to expect for .WAV files (unexpected chunks should be allowed for in processing RIFF files) and the format of the content data of each chunk type are described in the sections that follow.
RIFF WAVE (.WAV) file formatFrom: Rob Ryan <[email protected]>
Organization: Brown University I found the following lengthy excerpt in a document rmrtf.zrt (it is actually a .zip file) in the vendor/microsoft/multimedia subdirectory at the ftp.uu.net ftp site. It is presumably beyond the scope (in terms of the amount of detail) of your document, but nevertheless, I thought that it may help you in including references to the Windows .WAV format in the future. Let me know if you have any questions/comments. Again, thank you for your helpful summary. Keep it up! The following is taken from RIFFMCI.RTF, "Multimedia Programming Interface and Data Specification v1.0", a Windows RTF (Rich Text Format) file contained in the .zip file, RMRTF.ZRT. The original document is quite long and this constitutes pages 83-95 of the text format version (starting on roughly page 58 of the RTF version). If you would like a PostScript version, let me know and I can make one up for you.Waveform Audio File Format (WAVE) This section describes the Waveform format, which is used to represent digitized sound. The WAVE form is defined as follows. Programs must expect(and ignore) any unknown chunks encountered, as with all RIFF forms. However, <fmt-ck> must always occur before <wave-data>, and both of these chunks are mandatory in a WAVE file.<WAVE-form> ->
RIFF( 'WAVE'
<fmt-ck> // Format
[<fact-ck>] // Fact chunk
[<cue-ck>] // Cue points
[<playlist-ck>] // Playlist
[<assoc-data-list>] // Associated data list
<wave-data> ) // Wave dataWAVE chunks are described in the following sections.WAVE Format Chunk The WAVE format chunk <fmt-ck> specifies the format of the <wave-data>. The <fmt-ck> is defined as follows:<fmt-ck> -> fmt( <common-fields> <format-specific-fields> )<common-fields> ->
struct
{
WORD wFormatTag; // Format category
WORD wChannels; // Number of channels
DWORDdwSamplesPerSec; // Sampling rate
DWORDdwAvgBytesPerSec; // For buffer estimation
WORD wBlockAlign; // Data block size
}Common Fields Chunk The fields in the <common-fields> chunk are as follows: Field Description
wFormatTag A number indicating the WAVE format category of
the file. The content of the <format-specific-fields> portion of the `fmt' chunk, and the interpretation of the waveform data,on this value. must register any new WAVE format categories. See ``Registering Multimedia Formats'' in Chapter 1, ``Overview of Multimedia,'' for information on registering WAVE format categories. ``Wave Format Categories,'' following this section, lists the currently defined WAVE format categories. wChannels The number of channels represented in the
waveform data, such as 1 for mono or 2 for stereo. dwSamplesPerSec The sampling rate (in samples per second)
at which each channel should be played. dwAvgBytesPerSec The average number of bytes per second
at which the waveform data should be transferred. Playback software can estimate the buffer size using this value. wBlockAlign The block alignment (in bytes) of the waveform
data. Playback software needs to process a multiple of wBlockAlign bytes of data at a time, so the value of wBlockAlign can be used for buffer alignment.Format Specific Fields Chunk The <format-specific-fields> consists of zero or more bytes of parameters. Which parameters occur depends on the WAVE format category-see the following section for details. Playback software should be written to allow for (and ignore) any unknown <format-specific-fields> parameters that occur at the end of this field.WAVE Format Categories The format category of a WAVE file is specified by the value of the wFormatTag field of the `fmt' chunk. The representation of data in <wave-data>, and the content of the <format-specific-fields> of the `fmt' chunk, depend on the format category. The currently defined open non-proprietary WAVE format categories are as follows:wFormatTag Value Format Category_WAVE_FORMAT_PCM (0x0001) Microsoft Pulse Code Modulation (PCM) The following are the registered proprietary WAVE format categories:wFormatTag Value Format Category_FORMAT_MULAW (0x0101) IBM mu-law format
IBM_FORMAT_ALAW (0x0102) IBM a-law format
IBM_FORMAT_ADPCM (0x0103) IBM AVC Adaptive Differential PCM formatMicrosoft WAVE_FORMAT_PCM format The following sections describe the Microsoft WAVE_FORMAT_PCM format. If the wFormatTag field of the <fmt-ck> is set to WAVE_FORMAT_PCM, then the waveform data consists of samples represented in pulse code modulation (PCM) format. For PCM waveform data, the <format-specific-fields> is defined as follows:<PCM-format-specific> ->
struct
{
WORD wBitsPerSample; // Sample size
} The wBitsPerSample field specifies the number of bits of data used to represent each sample of each channel. If there are multiple channels, the sample size is the same for each channel. For PCM data, the wAvgBytesPerSec field of the `fmt' chunk should be equal to the following formula rounded up to the next whole number: wBitsPerSample
wChannels x wBitsPerSecond x --------------
8 The wBlockAlign field should be equal to the following formula, rounded to the next whole number: wBitsPerSample
wChannels x --------------
8Data Packing for PCM WAVE Files In a single-channel WAVE file, samples are stored consecutively. For stereo WAVE files, channel 0 represents the left channel, and channel 1 represents the right channel. The speaker position mapping for more than two channels is currently undefined. In multiple-channel WAVE files, samples are interleaved. The following diagrams show the data packing for a 8-bit mono and stereo WAVE files:Data Packing for 8-Bit Mono PCM: Sample 1 Sample 2 Sample 3 Sample 4
--------- --------- --------- ---------
Channel 0 Channel 0 Channel 0 Channel 0Data Packing for 8-Bit Stereo PCM: Sample 1 Sample 2
--------------------- ---------------------
Channel 0 Channel 1 Channel 0 Channel 0
(left) (right) (left) (right) The following diagrams show the data packing for 16-bit mono and stereo WAVE files:Data Packing for 16-Bit Mono PCM: Sample 1 Sample 2
---------------------- ----------------------
Channel 0 Channel 0 Channel 0 Channel 0
low-order high-order low-order high-order
byte byte byte byteData Packing for 16-Bit Stereo PCM: Sample 1
---------------------------------------------
Channel 0 Channel 0 Channel 1 Channel 1
(left) (left) (right) (right)
low-order high-order low-order high-order
byte byte byte byteData Format of the Samples Each sample is contained in an integer i. The size of i is the smallest number of bytes required to contain the specified sample size. The least significant byte is stored first. The bits that represent the sample amplitude are stored in the most significant bits of i, and the remaining bits are set to zero. For example, if the sample size (recorded in nBitsPerSample) is 12 bits, then each sample is stored in a two-byte integer. The least significant four bits of the first (least significant) byte is set to zero. The data format and maximum and minimums values for PCM waveform samples of various sizes are as follows: SampleSize DataFormat Max.Value MinimumValue
One to Unsigned 255 (0xFF) 0
eight bits integer Nine or Signed Largest Most negative
more bits integer i positive value of i
value of i For example, the maximum, minimum, and midpoint values for 8-bit and 16-bit PCM waveform data are as follows: Format Max.Value Min.Value MidpointValue
8-bit PCM 255 (0xFF) 0 128 (0x80)
16-bit PCM 32767 -32768 0
(0x7FFF) (-0x8000)Examples of PCM WAVE Files Example of a PCM WAVE file with 11.025 kHz sampling rate, mono, 8 bits per sample: RIFF( 'WAVE' fmt(1, 1, 11025, 11025, 1, 8)
data( <wave-data> ) ) Example of a PCM WAVE file with 22.05 kHz sampling rate, stereo, 8 bits per sample: RIFF( 'WAVE' fmt(1, 2, 22050, 44100, 2, 8)
data( <wave-data> ) ) Example of a PCM WAVE file with 44.1 kHz sampling rate, mono, 20 bits per sample: RIFF( 'WAVE' INFO(INAM("O Canada"Z))
fmt(1, 1, 44100, 132300, 3, 20)
data( <wave-data> ) )Storage of WAVE Data The <wave-data> contains the waveform data. It is defined as follows: <wave-data> -> { <data-ck> : <data-list> }
<data-ck> -> data( <wave-data> )
<wave-list> -> LIST( 'wavl' { <data-ck> : // Wave samples
<silence-ck> }... ) // Silence
<silence-ck> -> slnt( <dwSamples:DWORD> ) // Count of
// silent samples Note: The `slnt' chunk represents silence, not necessarily a repeated zero volume or baseline sample. In 16-bit PCM data, if the last sample value played before the silence section is a 10000, then if data is still output to the D to A converter, it must maintain the 10000 value. If a zero value is used, a click may be heard at the start and end of the silence section. If play begins at a silence section, then a zero value might be used since no other information is available. A click might be created if the data following the silent section starts with a nonzero value.FACT Chunk The <fact-ck> fact chunk stores important information about the contents of the WAVE file. This chunk is defined as follows: <fact-ck> -> fact( <dwFileSize:DWORD> ) // Number of samples The `fact'' chunk is required if the waveform data is contained in a `wavl'' LIST chunk and for all compressed audio formats. The chunk is not required for PCM files using the `data'' chunk format. The "fact" chunk will be expanded to include any other information required by future WAVE formats. Added fields will appear following the <dwFileSize> field. Applications can use the chunk size field to determine which fields are present.Cue-Points Chunk The <cue-ck> cue-points chunk identifies a series of positions in the waveform data stream. The <cue-ck> is defined as follows: <cue-ck> -> cue( <dwCuePoints:DWORD> // Count of cue points
<cue-point>... ) // Cue-point table
<cue-point> -> struct
{
DWORD dwName;
DWORD dwPosition;
FOURCC fccChunk;
DWORD dwChunkStart;
DWORD dwBlockStart;
DWORD dwSampleOffset;
} The <cue-point> fields are as follows: Field Description
dwName Specifies the cue point name. Each
<cue-point> record must have a unique dwName field.
dwPosition Specifies the sample position of the cue
point.This is the sequential sample number within the play order. See ``Playlist Chunk,'' later in this document, for a discussion of the play order.
fccChunk Specifies the name or chunk ID of thechunk
containing the cue point.
dwChunkStart Specifies the file position of the start of
the chunk containing the cue point. This is a byte offset relative to the start of the data section of the `wavl' LIST chunk.
dwBlockStart Specifies the file position of the start of
the block containing the position. This is a byte offset relative to the start of the data section of the `wavl' LIST chunk.
dwSampleOffset Specifies the sample offset of the cuepoint
relative to the start of the block.Examples of File Position Values The following table describes the <cue-point> field values for a WAVE file containing multiple `data' and `slnt' chunks enclosed in a `wavl' LIST chunk:CuePointLoc. Field Value
a `slnt' fccChunk FOURCC value `slnt'. dwChunkStart File position of the`slnt' chunk
relative to the start of the data section in the `wavl' LIST chunk. dwBlockStart File position of the datasection of
the `slnt' chunk relative to the start of the data section of the `wavl' LIST chunk.
dwSampleOffset Sample position of the cuepoint
relative to the start of the `slnt' chunk.In a PCM fccChunk FOURCC value `data'.
`data' chunk
dwChunkStart File position of the`data' chunk
relative to the start of the data section in the `wavl' LIST chunk. dwBlockStart File position of the cuepoint
relative to the start of the data section of the `wavl' LIST chunk. dwSampleOffset Zero value.In a fccChunk FOURCC value `data'.
compressed
`data' chunk
dwChunkStart File position of the startof the
`data' chunk relative to the start of the data section of the `wavl' LIST chunk. dwBlockStart File position of theenclosing block
relative to the start of the data section of the `wavl' LIST chunk. The software can begin the decompression at this point. dwSampleOffset Sample position of the cuepoint
relative to the start of the block. The following table describes the <cue-point> field values for a WAVE file containing a single `data' chunk:CuePointLoc. Field Value
Within PCM fccChunk FOURCC value `data'.
data
dwChunkStart Zero value. dwBlockStart Zero value. dwSampleOffset Sample position of the cuepoint
relative to the start of the `data' chunk.In a fccChunk FOURCC value `data'.
compressed
`data' chunk
dwChunkStart Zero value. dwBlockStart File position of theenclosing block
relative to the start of the `data' chunk. The software can begin the decompression at this point. dwSampleOffset Sample position of the cuepoint
relative to the start of the block.Playlist Chunk The <playlist-ck> playlist chunk specifies a play order for a series of cue points. The <playlist-ck> is defined as follows:<playlist-ck> -> plst( <dwSegments:DWORD> // Count of play segments
<play-segment>... ) // Play-segment table<play-segment> -> struct {
DWORD dwName;
DWORD dwLength;
DWORD dwLoops;
} The <play-segment> fields are as follows: Field Description
dwName Specifies the cue point name. This value
must match one of the names listed in the <cue-ck> cue-point table. dwLength Specifies the length of the section
in samples. dwLoops Specifies the number of times to play
the section.Associated Data Chunk The <assoc-data-list> associated data list provides the ability to attach information like labels to sections of the waveform data stream. The <assoc-data-list> is defined as follows:<assoc-data-list> -> LIST('adtl'
<labl-ck> // Label
<note-ck> // Note
<ltxt-ck> // Text with data length
<file-ck> ) // Media file<labl-ck> -> labl( <dwName:DWORD> <data:ZSTR> )<note-ck> -> note( <dwName:DWORD> <data:ZSTR> )<ltxt-ck> -> ltxt( <dwName:DWORD>
<dwSampleLength:DWORD>
<dwPurpose:DWORD>
<wCountry:WORD>
<wLanguage:WORD>
<wDialect:WORD>
<wCodePage:WORD>
<data:BYTE>... )<file-ck> -> file( <dwName:DWORD>
<dwMedType:DWORD>
<fileData:BYTE>...)Label and Note Information The `labl' and `note' chunks have similar fields. The `labl' chunk contains a label, or title, to associate with a cue point. The `note' chunk contains comment text for a cue point. The fields are as follows: Field Description
dwName Specifies the cue point name. This
value must match one of the names listed in the <cue-ck> cue-point table. data Specifies a NULL-terminated string
containing a text label (for the `labl' chunk) or comment text (for the `note' chunk).Text with Data Length Information The `ltxt'' chunk contains text that is associated with a data segment of specific length. The chunk fields are as follows: Field Description
dwName Specifies the cue point name. This
value must match one of the names listed in the <cue-ck> cue-point table. dwSampleLength Specifies the number of samples in the
segment of waveform data. dwPurpose Specifies the type or purpose of the
text. For example, dwPurpose can specify a FOURCC code like `scrp' for script text or `capt' for close-caption text. wCountry Specifies the country code for the
text. See ``Country Codes'' in Chapter 2, ``Resource Interchange File Format,'' for a current list of country codes. wLanguage, Specify the language and dialect codes
wDialect for the text. See ``Language and Dialect
Codes'' in Chapter 2, ``Resource Interchange File Format,'' for a current list of language and dialect codes. wCodePage Specifies the code page for the text.Embedded File Information The `file' chunk contains information described in other file formats (for example, an `RDIB' file or an ASCII text file). The chunk fields are as follows: Field Description
dwName Specifies the cue point name. This value
must match one of the names listed in the <cue-ck> cue-point table. dwMedType Specifies the file type contained in the
fileData field. If the fileData section contains a RIFF form, the dwMedType field is the same as the RIFF form type for the file. This field can contain a zero value. fileData Contains the media file.
给我MAIL地址，发给你吧。
thanks anyway.
WAVE文件作为多媒体中使用的声波文件格式之一，它是以RIFF格式为标准的。RIFF是英文Resource Interchange File Format的缩写，每个WAVE文件的头四个字节便是“RIFF”。WAVE文件由文件头和数据体两大部分组成。其中文件头又分为RIFF／WAV文件标识段和声音数据格式说明段两部分。WAVE文件各部分内容及格式见附表。
常见的声音文件主要有两种，分别对应于单声道（11.025KHz采样率、8Bit的采样值）和双声道（44.1KHz采样率、16Bit的采样值）。采样率是指：声音信号在“模→数”转换过程中单位时间内采样的次数。采样值是指每一次采样周期内声音模拟信号的积分值。
对于单声道声音文件，采样数据为八位的短整数（short int 00H-FFH）；而对于双声道立体声声音文件，每次采样数据为一个16位的整数（int），高八位和低八位分别代表左右两个声道。
WAVE文件数据块包含以脉冲编码调制（PCM）格式表示的样本。WAVE文件是由样本组织而成的。在单声道WAVE文件中，声道0代表左声道，声道1代表右声道。在多声道WAVE文件中，样本是交替出现的。
WAVE文件格式说明表 偏移地址 字节数 数据类型 内 容
文件头 00H 4 char "RIFF"标志
04H 4 long int 文件长度
08H 4 char "WAVE"标志
0CH 4 char "fmt"标志
10H 4 过渡字节（不定）
14H 2 int 格式类别（10H为PCM形式的声音数据)
16H 2 int 通道数，单声道为1，双声道为2
18H 2 int 采样率（每秒样本数），表示每个通道的播放速度，
1CH 4 long int 波形音频数据传送速率，其值为通道数×每秒数据位数×每样本的数据位数／8。播放软件利用此值可以估计缓冲区的大小。
20H 2 int 数据块的调整数（按字节算的），其值为通道数×每样本的数据位值／8。播放软件需要一次处理多个该值大小的字节数据，以便将其值用于缓冲区的调整。
22H 2 每样本的数据位数，表示每个声道中各个样本的数据位数。如果有多个声道，对每个声道而言，样本大小都一样。
24H 4 char 数据标记符＂data＂
28H 4 long int 语音数据的长度如有不清楚，再讨论。
typedef struct {
WORD wFormatTag;
WORD nChannels;
DWORD nSamplesPerSec;
DWORD nAvgBytesPerSec;
WORD nBlockAlign;
WORD wBitsPerSample;
WORD cbSize;
} WAVEFORMATEX;
它是从哪里开始的？数据块又是从哪里开始的？其实我只想知道这两个地址的起始位置。
对于DATA数据块中的数据
是按照little-endian排列的,
如何转化成十进制的数?
VB中用什么语句?
有人知道吗?