Revision as of 19:59, 11 December 2023 editHeyElliott (talk | contribs)Extended confirmed users118,110 edits WP:N'TTag: 2017 wikitext editor← Previous edit | Revision as of 21:17, 11 December 2023 edit undoKvng (talk | contribs)Extended confirmed users, New page reviewers107,681 edits review: formatting consistency. use footnote better.Tag: nowiki addedNext edit → | ||
Line 69: | Line 69: | ||
The WAV specification includes some optional features. The optional <code><nowiki><fact-ck></nowiki></code> chunk reports the number of samples for some compressed coding schemes. The <code><nowiki><cue-ck></nowiki></code> chunk identifies some significant sample numbers in the wave file. The <code><nowiki><playlist-ck></nowiki></code> chunk allows the samples to be played out of order or repeated rather than just from beginning to end. The associated data list (<code><nowiki><assoc-data-list></nowiki></code>) allows labels and notes to be attached to cue points; text annotation may be given for a group of samples (e.g., caption information). | The WAV specification includes some optional features. The optional <code><nowiki><fact-ck></nowiki></code> chunk reports the number of samples for some compressed coding schemes. The <code><nowiki><cue-ck></nowiki></code> chunk identifies some significant sample numbers in the wave file. The <code><nowiki><playlist-ck></nowiki></code> chunk allows the samples to be played out of order or repeated rather than just from beginning to end. The associated data list (<code><nowiki><assoc-data-list></nowiki></code>) allows labels and notes to be attached to cue points; text annotation may be given for a group of samples (e.g., caption information). | ||
Finally, the mandatory <code><nowiki><wave-data></nowiki></code> chunk contains the actual samples in the format previously specified. |
Finally, the mandatory <code><nowiki><wave-data></nowiki></code> chunk contains the actual samples in the format previously specified. | ||
Note that the WAV file definition does not show where an <code>INFO</code> chunk should be placed. It is also silent about the placement of a <code>CSET</code> chunk (which specifies the character set used). | Note that the WAV file definition does not show where an <code>INFO</code> chunk should be placed. It is also silent about the placement of a <code>CSET</code> chunk (which specifies the character set used). | ||
The RIFF specification attempts to be a formal specification, but its formalism lacks the precision seen in other tagged formats. For example, the RIFF specification does not clearly distinguish between a set of subchunks and an ordered sequence of subchunks.<!-- Compare ASN SET-OF and SEQUENCE-OF --> The RIFF form chunk suggests it should be a sequence container. |
The RIFF specification attempts to be a formal specification, but its formalism lacks the precision seen in other tagged formats. For example, the RIFF specification does not clearly distinguish between a set of subchunks and an ordered sequence of subchunks.<!-- Compare ASN SET-OF and SEQUENCE-OF --> The RIFF form chunk suggests it should be a sequence container. Sequencing information is specified in the RIFF form of a WAV file consistent with the formalism: "However, <code><nowiki><fmt-ck></nowiki></code> must always occur before <code><nowiki><wave-data></nowiki></code>, and both of these chunks are mandatory in a WAVE file."<ref>{{Harvnb|IBM|Microsoft|1991|loc=PDF p. 56}}</ref> The specification suggests a <code>LIST</code> chunk is also a sequence: "A LIST chunk contains a list, or ordered sequence, of subchunks."<ref>{{Harvnb|IBM|Microsoft|1991|loc=PDF p. 23}}</ref> However, the specification does not give a formal specification of the <code>INFO</code> chunk; an example <code>INFO</code> <code>LIST</code> chunk ignores the chunk sequence implied in the <code>INFO</code> description.<ref>{{Harvnb|IBM|Microsoft|1991|loc=PDF p. 21}}, <code>INAM</code> appears before <code>ICOP</code></ref> The <code>LIST</code> chunk definition for <code><nowiki><wave-data></nowiki></code> does use the <code>LIST</code> chunk as a sequence container with good formal semantics.<!--]--> | ||
The WAV specification allows for not only a single, contiguous, array of audio samples, but also discrete blocks of samples and silence that are played in order. Most WAV files use a single array of data. The specification for the sample data is confused:<ref>Specification from {{Harvnb|IBM|Microsoft|1991}} which also describes how the production syntax is interpreted.</ref> | The WAV specification allows for not only a single, contiguous, array of audio samples, but also discrete blocks of samples and silence that are played in order. Most WAV files use a single array of data. The specification for the sample data is confused:<ref>Specification from {{Harvnb|IBM|Microsoft|1991}} which also describes how the production syntax is interpreted.</ref> |
Revision as of 21:17, 11 December 2023
File format standard for storing audio on PCs Not to be confused with WavPack. "Wav" redirects here. For the scientific wave, see Wave. For the waves of water, see Wind wave. For other uses, see Wav (disambiguation). "Wave Sound" redirects here. For the festival, see Wave Sound (festival).Filename extension | .wav .wave |
---|---|
Internet media type | audio/vnd.wave, audio/wav, audio/wave, audio/x-wav |
Type code | WAVE |
Uniform Type Identifier (UTI) | com.microsoft.waveform-audio |
Developed by | IBM and Microsoft |
Initial release | August 1991; 33 years ago (1991-08) |
Latest release | Multiple Channel Audio Data and WAVE Files 7 March 2007; 17 years ago (2007-03-07) (update) |
Type of format | Audio file format, container format |
Extended from | RIFF |
Extended to | BWF, RF64 |
Waveform Audio File Format (WAVE, or WAV due to its filename extension; pronounced /wæv/ or /weɪv/ ) is an audio file format standard, developed by IBM and Microsoft, for storing an audio bitstream on personal computers. It is the main format used on Microsoft Windows systems for uncompressed audio. The usual bitstream encoding is the linear pulse-code modulation (LPCM) format.
WAV is an application of the Resource Interchange File Format (RIFF) bitstream format method for storing data in chunks, and thus is similar to the 8SVX and the Audio Interchange File Format (AIFF) format used on Amiga and Macintosh computers, respectively.
Description
The WAV file is an instance of a Resource Interchange File Format (RIFF) defined by IBM and Microsoft. The RIFF format acts as a wrapper for various audio coding formats.
Though a WAV file can contain compressed audio, the most common WAV audio format is uncompressed audio in the linear pulse-code modulation (LPCM) format. LPCM is also the standard audio coding format for audio CDs, which store two-channel LPCM audio sampled at 44.1 kHz with 16 bits per sample. Since LPCM is uncompressed and retains all of the samples of an audio track, professional users or audio experts may use the WAV format with LPCM audio for maximum audio quality. WAV files can also be edited and manipulated with relative ease using software.
On Microsoft Windows, the WAV format supports compressed audio using the Audio Compression Manager (ACM). Any ACM codec can be used to compress a WAV file. The user interface (UI) for Audio Compression Manager may be accessed through various programs that use it, including Sound Recorder in some versions of Windows.
Beginning with Windows 2000, a WAVE_FORMAT_EXTENSIBLE
header was defined which specifies multiple audio channel data along with speaker positions, eliminates ambiguity regarding sample types and container sizes in the standard WAV format and supports defining custom extensions to the format.
Specification
RIFF
A RIFF file is a tagged file format. It has a specific container format (a chunk) with a header that includes a four-character tag (FourCC) and the size (number of bytes) of the chunk. The tag specifies how the data within the chunk should be interpreted, and there are several standard FourCC tags. Tags consisting of all capital letters are reserved tags. The outermost chunk of a RIFF file has a RIFF
tag; the first four bytes of chunk data are an additional FourCC tag that specify the form type and are followed by a sequence of subchunks. In the case of a WAV file, the additional tag is WAVE
. The remainder of the RIFF data is a sequence of chunks describing the audio information.
The advantage of a tagged file format is that the format can be extended later while maintaining backward compatibility. The rule for a RIFF (or WAV) reader is that it should ignore any tagged chunk that it does not recognize. The reader will not be able to use the new information, but the reader should not be confused.
The specification for RIFF files includes the definition of an INFO
chunk. The chunk may include information such as the title of the work, the author, the creation date, and copyright information. Although the INFO
chunk was defined for RIFF in version 1.0, the chunk was not referenced in the formal specification of a WAV file. Many readers had trouble processing this. Consequently, the safest thing to do from an interchange standpoint was to omit the INFO
chunk and other extensions and send a lowest-common-denominator file. There are other INFO chunk placement problems.
RIFF files were expected to be used in international environments, so there is CSET
chunk to specify the country code, language, dialect, and code page for the strings in a RIFF file. For example, specifying an appropriate CSET
chunk should allow the strings in an INFO
chunk (and other chunks throughout the RIFF file) to be interpreted as Cyrillic or Japanese characters.
RIFF also defines a JUNK
chunk whose contents are uninteresting. The chunk allows a chunk to be deleted by just changing its FourCC. The chunk could also be used to reserve some space for future edits so the file could be modified without being resized. A later definition of RIFF introduced a similar PAD
chunk.
RIFF WAVE
The top-level definition of a WAV file is:
<WAVE-form> → RIFF('WAVE' <fmt-ck> // Format of the file // Fact chunk // Cue points // Playlist // Associated data list <wave-data> ) // Wave data
The top-level RIFF form uses a WAVE
tag. It is followed by a mandatory <fmt-ck>
chunk that describes the format of the sample data that follows. This chunk includes information such as the sample encoding, number of bits per channel, the number of channels, and the sample rate.
The WAV specification includes some optional features. The optional <fact-ck>
chunk reports the number of samples for some compressed coding schemes. The <cue-ck>
chunk identifies some significant sample numbers in the wave file. The <playlist-ck>
chunk allows the samples to be played out of order or repeated rather than just from beginning to end. The associated data list (<assoc-data-list>
) allows labels and notes to be attached to cue points; text annotation may be given for a group of samples (e.g., caption information).
Finally, the mandatory <wave-data>
chunk contains the actual samples in the format previously specified.
Note that the WAV file definition does not show where an INFO
chunk should be placed. It is also silent about the placement of a CSET
chunk (which specifies the character set used).
The RIFF specification attempts to be a formal specification, but its formalism lacks the precision seen in other tagged formats. For example, the RIFF specification does not clearly distinguish between a set of subchunks and an ordered sequence of subchunks. The RIFF form chunk suggests it should be a sequence container. Sequencing information is specified in the RIFF form of a WAV file consistent with the formalism: "However, <fmt-ck>
must always occur before <wave-data>
, and both of these chunks are mandatory in a WAVE file." The specification suggests a LIST
chunk is also a sequence: "A LIST chunk contains a list, or ordered sequence, of subchunks." However, the specification does not give a formal specification of the INFO
chunk; an example INFO
LIST
chunk ignores the chunk sequence implied in the INFO
description. The LIST
chunk definition for <wave-data>
does use the LIST
chunk as a sequence container with good formal semantics.
The WAV specification allows for not only a single, contiguous, array of audio samples, but also discrete blocks of samples and silence that are played in order. Most WAV files use a single array of data. The specification for the sample data is confused:
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
These productions are confused. Apparently <data-list>
(undefined) and <wave-list>
(defined but not referenced) should be identical. Even if that problem is fixed, the productions then allow a <data-ck>
to contain a recursive <wave-data>
(which implies data interpretation problems). The specification should have been something like:
<wave-data> → { <data-ck> | <wave-list> } <data-ck> → data( <bSampleData:BYTE> ... ) <wave-list> → LIST( 'wavl' { <data-ck> | // Wave samples <silence-ck> }... ) // Silence <silence-ck> → slnt( <dwSamples:DWORD> ) // Count of silent samples
to avoid the recursion.
WAV files can contain embedded IFF "lists", which can contain several "sub-chunks".
Metadata
As a derivative of RIFF, WAV files can be tagged with metadata in the INFO chunk. In addition, WAV files can embed any kind of metadata, including but not limited to Extensible Metadata Platform (XMP) data or ID3 tags in extra chunks. Applications may not handle this extra information or may expect to see it in a particular place. Although the RIFF specification requires that applications ignore chunks they do not recognize, some applications are confused by additional chunks.
Popularity
Uncompressed WAV files are large, so file sharing of WAV files over the Internet is uncommon except among video, music and audio professionals where the uncompressed form has become the most popular of all audio formats and, for most, high speed large bandwidth web connections are commonplace. Many audio and music software manufacturers now favour it as their default file format though others are often supported. The high resolution of the format makes it suitable for retaining first generation archived files of high quality, for use on a system where disk space is not a constraint, or in applications such as audio editing where the time involved in compressing and uncompressing data, and the losses in quality of such conversions are a concern.
Use by broadcasters
In spite of their large size, uncompressed WAV files are used by most radio broadcasters, especially those that have adopted a tapeless system.
- BBC Radio in the UK uses 48 kHz 16-bit two-channel WAV audio as standard in their SCISYS dira audio editing and playout system.
- The UK Commercial radio company Global Radio uses 44.1 kHz 16-bit two-channel WAV files in the Genesys playout system, and throughout their broadcast chain.
- The ABC "D-Cart" system, which was developed by the Australian broadcaster, uses 48 kHz 16-bit two-channel WAV files, which is identical to that of Digital Audio Tape.
- The Digital Radio Mondiale consortium uses WAV files as an informal standard for transmitter simulation and receiver testing.
Limitations
The WAV format is limited to files that are less than 4 GiB, because of its use of a 32-bit unsigned integer to record the file size header. Although this is equivalent to about 6.8 hours of CD-quality audio (44.1 kHz, 16-bit stereo), it is sometimes necessary to exceed this limit, especially when greater sampling rates, bit resolutions or channel count are required. The W64 format was therefore created for use in Sound Forge. Its 64-bit header allows for much longer recording times. The RF64 format specified by the European Broadcasting Union has also been created to solve this problem.
Non-audio data
Since the sampling rate of a WAV file can vary from 1 Hz to 4.3 GHz, and the number of channels can be as high as 65535, .wav files have also been used for non-audio data. LTspice, for instance, can store multiple circuit trace waveforms in separate channels, at any appropriate sampling rate, with the full-scale range representing ±1 V or A rather than a sound pressure.
Audio compact discs
Audio compact discs (CDs) do not use the WAV file format, using instead Red Book audio. The commonality is that audio CDs are encoded as uncompressed pulse-code modulation (PCM), which is one of the formats supported by WAV. WAV is a file format for a computer to use that cannot be understood by most CD players directly. To record WAV files to an Audio CD the file headers must be stripped, the contents must be transcoded if not already stored as PCM, and the PCM data written directly to the disc as individual tracks with zero-padding added to match the CD's sector size.
In order for PCM audio to be able to be burned to a CD, it should be in the 44.1 kHz, 16-bit stereo format.
Comparison of coding schemes
Main article: Audio compression (data) Further information: Comparison of audio coding formatsAudio in WAV files can be encoded in a variety of audio coding formats, such as GSM or MP3, to reduce the file size.
This is a reference to compare the monophonic (not stereophonic) audio quality and compression bitrates of audio coding formats available for WAV files including PCM, ADPCM, Microsoft GSM 06.10, CELP, SBC, Truespeech and MPEG Layer-3. These are the default ACM codecs that come with Windows.
Format | Bitrate (kbit/s) | 1 minute (KiB) |
---|---|---|
11,025 Hz 16 bit PCM | 176.4 | 1292 |
08,000 Hz 16 bit PCM | 128 | 0938 |
11,025 Hz 8 bit PCM | 088.2 | 0646 |
11,025 Hz µ-Law | 088.2 | 0646 |
08,000 Hz 8 bit PCM | 064 | 0469 |
08,000 Hz µ-Law | 064 | 0469 |
11,025 Hz 4 bit ADPCM | 044.1 | 0323 |
08,000 Hz 4 bit ADPCM | 032 | 0234 |
11,025 Hz GSM 06.10 | 018 | 0132 |
08,000 Hz MP3 16 kbit/s | 016 | 0117 |
08,000 Hz GSM 06.10 | 013 | 0103 |
08,000 Hz Lernout & Hauspie SBC 12 kbit/s | 012 | 0088 |
08,000 Hz DSP Group Truespeech | 009 | 0066 |
08,000 Hz MP3 8 kbit/s | 008 | 0060 |
08,000 Hz Lernout & Hauspie CELP | 004.8 | 0035 |
The above are WAV files; even those that use MP3 compression have the .wav
extension.
See also
- Audio Compression Manager
- Broadcast Wave Format (BWF)
- Comparison of audio coding formats
- RF64, an extended file format for audio (multichannel file format enabling file sizes to exceed 4 gigabytes)
- Windows Media Audio
References
- Fleischman, E. (June 1998). WAVE and AVI Codec Registries. IETF. doi:10.17487/RFC2361. RFC 2361. Retrieved 2009-12-06.
- "File Extension .WAV Details". Filext.com. Retrieved 2015-08-10.
- ^ IBM; Microsoft (August 1991). "Multimedia Programming Interface and Data Specifications 1.0" (PDF). Retrieved 2020-12-26.
- ^ P. Kabal (2006-06-19). "Audio File Format Specifications - WAVE or RIFF WAVE sound file". McGill University. Retrieved 2010-03-16.
- ^ "Multiple Channel Audio Data and WAVE Files". Microsoft Corporation. 2007-03-07. Retrieved 2010-03-16.
- "WAVE Audio File Format". Library of Congress. 2008-09-12. Retrieved 2023-12-03.
- Di Silvestro, Laile L.; Baribault, Greg (June 20, 1999). Waveform Audio File Format, MIME Sub-type Registration. IETF. I-D draft-ema-vpim-wav-00. Retrieved 2009-12-06.
- "Definition of WAV file in English". Oxford English Living Dictionary. Archived from the original on February 7, 2018.
- Branson, Ryan (21 October 2015) (21 October 2015). "What Makes WAV Better than MP3". Online Video Converter. Retrieved 18 June 2016.
{{cite web}}
: CS1 maint: numeric names: authors list (link) - EBU (July 2009), EBU Tech 3306 - MBWF / RF64: An Extended File Format for Audio (PDF), archived from the original (PDF) on 2009-11-22, retrieved 2010-01-19
- IBM & Microsoft 1991, p. 1-1, "The main advantage of RIFF is its extensibility; file formats based on RIFF can be future-proofed, as format changes can be ignored by existing applications."
- IBM & Microsoft 1991, PDF p. 56, "Programs must expect (and ignore) any unknown chunks encountered, as with all RIFF forms."
- IBM & Microsoft 1991, pp. 2-17 to 2-18
- IBM & Microsoft 1991, p. 2-18
- Microsoft Multimedia Standards Update, New Multimedia Data Types and Data Techniques, Revision 3.0, April 15, 1994, page 6.
- IBM & Microsoft 1991, PDF p. 56
- IBM & Microsoft 1991, PDF p. 56
- IBM & Microsoft 1991, PDF p. 23
- IBM & Microsoft 1991, PDF p. 21,
INAM
appears beforeICOP
- Specification from IBM & Microsoft 1991 which also describes how the production syntax is interpreted.
- "WAVE File Format". 1999-11-15. Archived from the original on 1999-11-15. Retrieved 2010-03-16.
- "WAVE PCM soundfile format". 2003-01-20. Archived from the original on 2009-08-27. Retrieved 2010-03-16.
- "The WAVE File Format". Archived from the original on 2011-07-22. Retrieved 2010-03-16.
- XMP SPECIFICATION PART 3: STORAGE IN FILES (PDF). Adobe Systems Incorporated. 2016. pp. 24–25. Archived from the original (PDF) on 25 February 2018. Retrieved 8 January 2020.
- "WAV". Audacity. Archived from the original on 2020-11-06. Retrieved 2020-01-08.
- "LTspice IV" (PDF). Linear Technologies Corporation. 2009. p. 95. Archived from the original (PDF) on 2012-02-27. Retrieved 2015-09-04.
External links
- WAVE file format specifications - from McGill University, (Last update: 2011-01-03)
- Extensible Wave-Format Descriptors from Microsoft (Updated October 26, 2017)
- More information on WAVE_FORMAT_EXTENSIBLE - University of Bath
- WAVE File Format - technical details (1999)
- WAV & BWF Metadata Guide
- Exif tags; see, for example, page 128
Multimedia compression and container formats | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Video compression |
| ||||||||||||||||
Audio compression |
| ||||||||||||||||
Image compression |
| ||||||||||||||||
Containers |
| ||||||||||||||||
Collaborations | |||||||||||||||||
Methods | |||||||||||||||||
Lists | |||||||||||||||||
See Compression methods for techniques and Compression software for codecs |