Web audio codec guide - Web media technologies

Web audio codec guide
=====================

Even modest quality, high-fidelity stereo sound can use a substantial amount of disk space. For web developers, an even bigger concern is the network bandwidth needed in order to transfer audio, whether for streaming or to download it for use during gameplay. The processing of audio data to encode and decode it is handled by an audio **codec** (**CO**der/**DEC**oder). In this article, we look at audio codecs used on the web to compress and decompress audio, what their capabilities and use cases are, and offer guidance when choosing audio codecs to use for your content.

Additionally, WebRTC implementations generally use a subset of these codecs for their encoding and decoding of media, and may support additional codecs as well, for optimal cross-platform support of video and audio conferencing, and to integrate better with legacy telecommunication solutions. See Codecs used by WebRTC for details.

For information about the fundamental concepts behind how digital audio works, see the article Digital audio concepts.

Common codecs
-------------

The list below denotes the codecs most commonly used on the web and which containers (file types) support them. If all you need to know is which codecs are even possible to use, this is for you. Of course, individual browsers may or may not choose to support all of these codecs, and their support for which container types can use them may vary as well. In addition, browsers may choose to support additional codecs not included on this list.

| Codec name (short) | Full codec name | Container support |
| --- | --- | --- |
| AAC | Advanced Audio Coding | MP4,
 ADTS,
 3GP |
| ALAC | Apple Lossless Audio Codec | MP4,
 QuickTime
 (MOV)
  |
| AMR | Adaptive Multi-Rate | 3GP |
| FLAC | Free Lossless Audio Codec | MP4,
 Ogg,
 FLAC |
| G.711 | Pulse Code Modulation (PCM) of Voice Frequencies | RTP /
 WebRTC |
| G.722 |
 7 kHz Audio Coding Within 64 kbps (for
 telephony/VoIP)
  | RTP /
 WebRTC |
| MP3 | MPEG-1 Audio Layer III | MP4,
 ADTS,
 MPEG,
 3GP

 When MPEG-1 Audio Layer III codec data is stored in an MPEG file, and
 there is no video track on the file, the file is typically referred to
 as an MP3 file, even though it's still an MPEG format file.
  |
| Opus | Opus | WebM,
 MP4,
 Ogg |
| Vorbis | Vorbis | WebM,
 Ogg |

Factors affecting the encoded audio
-----------------------------------

There are two general categories of factors that affect the encoded audio which is output by an audio codec's encoder: details about the source audio's format and contents, and the codec and its configuration during the encoding process.

For each factor that affects the encoded audio, there is a simple rule that is nearly always true: because the fidelity of digital audio is determined by the granularity and precision of the samples taken to convert it into a data stream, the more data used to represent the digital version of the audio, the more closely the sampled sound will match the source material.

### The effect of source audio format on encoded audio output

Because encoded audio inherently uses fewer bits to represent each sample, the source audio format may actually have less impact on the encoded audio size than one might expect. However, a number of factors do still affect the encoded audio quality and size. The table below lists a number of key source audio file format factors and their impact on the encoded audio.

 The effect of source audio format and contents on the encoded audio quality
 and size
 | Feature | Effect on quality | Effect on size |
| --- | --- | --- |
| Channel count |
 The number of channels affects only the perception of directionality,
 not the quality.
  |
 Each channel may substantially increase the encoded audio size,
 depending on contents and encoder settings.
  |
| Noise / Hiss |
 Unwanted background noise or hiss tends to reduce audio quality both
 directly (by masking details of the foreground audio) and indirectly (by
 making the audio waveform more complicated and therefore difficult to
 reduce in size while maintaining precision).
  |
 Hiss, static, or background noise increases the audio complexity, which
 generally reduces the amount of compression which is possible.
  |
| Sample rate |
 The more samples available per second, the higher the resulting encoded
 audio fidelity is likely to be.
  | Increasing the sample rate increases the encoded audio file's size. |
| Sample size |
 The larger the samples, the more detail each sample can contain,
 resulting in more accurate representation of each sample.
  |
 Depends on the codec; codecs typically have an internal sample format
 that may or may not be the same as the original sample size. But more
 source detail may make the encoded file larger; it will never make it
 smaller.
  |

Of course, these effects can be altered by decisions made while encoding the audio. For example, if the encoder is configured to reduce the sample rate, the sample rate's effect on the output file will be reduced in kind.

For more information about these and other features of audio data, see Audio data format and structure.

### The effect of codec configuration on encoded audio output

Audio codecs typically employ cleverly-designed and highly-complex mathematical algorithms to take source audio data and compress it to take substantially less space in memory or network bandwidth. In addition to choosing the type of encoder to use, you may have the opportunity to adjust the encoder using parameters that choose specific algorithms, tune those algorithms, and specify how many passes to apply while encoding.

Audio encoder configuration effects on quality and size| Feature | Effect on quality | Effect on size |
| --- | --- | --- |
| Lossless compression | No loss of fidelity | Unlikely to get more than 40-50% compression |
| Lossy compression |
 Always some loss of fidelity; the higher the compression, the more the
 loss
  | Compression of up to 80-95% possible |
| Quality setting | The higher the quality, the better the fidelity of the encoded audio |
 The higher the fidelity, the larger the resulting file becomes, though
 the amount of change varies from codec to codec
  |
| Bit rate | The higher the bit rate, the higher the quality can be | The higher the bit rate, the larger the encoded file is likely to be |
| Audio frequency bandwidth |
 If there is any audio in the removed frequency band(s), there may be a
 noticeable loss of fidelity
  |
 Removing frequency bands means less data to encode, thus smaller encoded
 files
  |
| Stereo coding |
 Simple stereo and
 mid-side stereo coding
 don't affect quality;
 intensity stereo coding
 introduces loss of detail, however.
  | Joint stereo can reduce the size of the encoded audio to some extent |

The parameters available—and the range of possible values—varies from codec to codec, and even among different encoding utilities for the same codec, so read the documentation that comes with the encoding software you use to learn more.

### Features affecting encoded audio size

Several factors affect the size of the encoded audio. Some of these are a matter of the form of the source audio; others are related to decisions made while encoding the audio.

#### Lossless versus lossy codecs

There are two basic categories of audio compression. **Lossless** compression algorithms reduce the size of the audio without compromising the quality or fidelity of the sound. Upon decoding audio compressed with a lossless codec such as FLAC or ALAC, the result is identical in every way to the original sound, down to the bit.

**Lossy** codecs, on the other hand, take advantage of the fact that the human ear is not a perfect interpreter of audio, and of the fact that the human brain can pluck the important information out of imperfect or noisy audio. They strip away audio frequencies that aren't used much, tolerate loss of precision in the decoded output, and use other methods to lose audio content, quality, and fidelity to produce smaller encoded media. Upon decoding, the output is, to varying degrees, still understandable. The specific codec used—and the compression configuration selected—determine how close to the original, uncompressed audio signal the output seems to be when heard by the human ear.

Because of the differences in how lossy codecs work compared to lossless ones, especially the fact that lossless ones have to be much more conservative with their compression, lossy codecs nearly always result in significantly smaller compressed audio than lossless codecs do.

Generally speaking, the most common reasons to choose lossless audio are because you require archival-quality storage, or because the audio samples will be remixed and recompressed, and you wish to avoid the amplification of artifacts in the audio due to recompression. For real-time streaming of audio, a lossy codec is usually required in order to ensure the flow of data can keep up with the audio playback rate regardless of network performance.

### Maximum number of channels

The audio delivered to each speaker in a sound system is provided by one audio channel in a stream. Monaural sound is a single channel. Stereo sound is two. 5.1 surround sound has five audio channels, plus one **Low Frequency Enhancement** (**LFE**) channel.

LFE channels are specifically designed to store low-frequency audio data, and are commonly used to provide audio data for subwoofers, for example. When you see the number of audio channels written in the form X.Y (such as 2.1 or 5.1), the number after the decimal point, Y, is the number of LFE channels. For example, MP3 supports one LFE channel, while AAC supports up to 16.

In addition to providing audio for specific speakers in a sound system, some codecs may allow audio channels to be used to provide alternative audio, such as vocals in different languages or descriptive audio for visually impaired people.

### Audio frequency bandwidth

The **audio frequency bandwidth** of a codec indicates the range of audio frequencies that can be represented using the codec. Some codecs operate specifically by eliminating audio that falls outside a given frequency range. There is a correlation between the sample rate and the maximum sound frequency that can be represented by a waveform represented by a codec. At a theoretical level, the maximum frequency a codec can represent is the sample rate divided by two; this frequency is called the Nyquist frequency. In reality, the maximum is slightly lower, but it's close.

The audio frequency bandwidth comes into play especially vividly when a codec is designed or configured to represent human speech rather than a broad range of sounds. Human speech generally resides within the audio frequency range of 300 Hz to 18 kHz. However, the vast majority of human vocalizations exist in the range 300 Hz to 8 kHz, and you can capture enough of human vocalizations in the frequency range 500 Hz to 3 kHz to still be understandable.

For that reason, speech-specific codecs often begin by dropping sound that falls outside a set range. That range is the audio frequency bandwidth. G.722, for example, strips away sounds outside the audio frequency bandwidth of 50 Hz to 7 kHz. This reduces the amount of data that needs to be encoded from the outset.

Codec details
-------------

Below we take a brief look at each of these codecs, looking at their basic capabilities and their primary use cases.

### AAC (Advanced Audio Coding)

The **Advanced Audio Coding** (**AAC**) codec is defined as part of the MPEG-4 (H.264) standard; specifically, as part of MPEG-4 Part 3 and MPEG-2 Part 7. Designed to be able to provide more compression with higher audio fidelity than MP3, AAC has become a popular choice, and is the standard format for audio in many types of media, including Blu-Ray discs and HDTV, as well as being the format used for songs purchased from online vendors including iTunes.

AAC has a number of profiles that define methods of compressing audio for specific use cases, including everything from high quality surround sound to low-fidelity audio for speech-only use.

As a patent-encumbered format, AAC support is somewhat less predictable. For example, Firefox only supports AAC if support is provided by the operating system or an external library.

|  |  |
| --- | --- |
| Supported bit rates | Arbitrary, up to 512 kbps |
| Variable Bit Rate (VBR) support | Yes |
| Supported sample formats | 32-bit integer |
| Supported sample rates | 8 kHz - 96 kHz |
| Recommended minimum bit rate for stereo sound | 96 kbps at 48 kHz sample rate |
| Compression | Lossy |
| Maximum audio channels | 48 (plus 16 Low Frequency Enhancement channels) |
| Audio frequency bandwidth |
 0 Hz - 96 kHz (standard audio channels)0 Hz - 120 Hz (LFE
 channels)
  |
| Latency | 20 ms to 405 ms |
| Browser compatibility |

| Feature | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari |
| --- | --- | --- | --- | --- | --- | --- |
| AAC support | Yes | Yes | Yes | 9 | Yes | 3.1 |

 Due to patent issues, Firefox does not directly support AAC. Instead,
 Firefox relies upon a platform's native support for AAC. This
 capability was introduced on each platform in different Firefox
 releases:

 Chrome supports AAC only in MP4 containers, and only supports AAC's
 Main Profile. In addition, AAC is not available in Chromium builds.
  |
| Container support | MP4, ADTS, 3GP |
| RTP /
 WebRTC compatible
  | Yes |
| Licensing |
 For streaming or distributing AAC-encoded content: no license required;
 developers of codecs are required to obtain a patent license through
 VIA Licensing |

AAC support in Firefox using external library, by platform| Platform | First Firefox versionwith AAC support |
| --- | --- |
| Windows (Vista and later) | 22 |
| Android | 20 |
|
 Linux (depends on
 GStreamer)
  | 26 |
| macOS | 35 |

### ALAC (Apple Lossless Audio Codec)

The **Apple Lossless Audio Codec** (**ALAC** or **Apple Lossless**) is a lossless codec developed by Apple. After initially being a closed format, Apple opened it up under an Apache license.

Cross-platform and browser support for ALAC is not very strong, making it a less than ideal choice for general usage. However, if your target is primarily macOS and iOS users, it may be worth considering, as the operating systems have integrated support for ALAC. Otherwise, FLAC is likely a better choice, if you must use a lossless codec.

Keep in mind, however, that lossless codecs require substantially more bandwidth and storage capacity, and may not be a good choice outside very specific use cases.

|  |  |
| --- | --- |
| Supported bit rates |
 Based on the sample format and sample rate, as well as the compression
 level
  |
| Variable Bit Rate (VBR) support | No |
| Supported sample formats | 16-bit, 20-bit, 24-bit, and 32-bit integer |
| Supported sample rates | 1 Hz to 384,000 Hz |
| Recommended minimum bit rate for stereo sound | n/a |
| Compression | Lossless; up to 45-60% |
| Maximum audio channels | 8 (up to 7.1 surround) |
| Audio frequency bandwidth | ? |
| Latency | ? |
| Browser compatibility |

| Feature | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari |
| --- | --- | --- | --- | --- | --- | --- |
| ALAC support | No | No | No | No | No | Yes |

 |
| Container support | MP4 |
| RTP /
 WebRTC compatible
  | No |
| Licensing |
 Open license (Apache License 2.0);
 source code available on GitHub |

### AMR (Adaptive Multi-Rate)

The **Adaptive Multi-Rate audio codec** is optimized for encoding human speech efficiently. It was standardized in 1999 as part of the 3GPP audio standard used for both GSM and UMTS cellular telephony, and uses a multi-rate narrowband algorithm to encode audio frequencies at a telephony-grade quality level at around 7.4 kbps. In addition to being used for real-time telephony, AMR audio may be used for voicemail and other short audio recordings.

AMR audio which is stored in files may be typed `.amr`, but may also be encapsulated in `.3gp` files.

As a speech-specific codec, AMR is essentially useless for any other content, including audio containing only singing voices. Additionally, because AMR is designed to minimize capacity requirements, it only captures the portion of the full audio frequency bandwidth of human speech which is absolutely necessary to understand what's being said, so quality is reduced accordingly. If you need the ability to record audio at a minimal impact to network and/or storage capacity, AMR can be a great choice. However, if you need high-fidelity reproduction of human speech—or even low-quality music reproduction—you need to choose another format.

|  |  |
| --- | --- |
| Supported bit rates | **Half Rate (HR) and Full Rate (FR):** 1.8 kbps, 4.75 kbps,
 5.15 kbpz, 5.9 kbps, 6.7 kbps, 7.4 kbps, 7.95 kbps
  |
| **Full Rate (FR) only:** 10.2 kbps and 12.2 kbps |
| Variable Bit Rate (VBR) support | No |
| Supported sample formats | 13-bit integer |
| Supported sample rates | 8 kHz |
| Recommended minimum bit rate for stereo sound | n/a |
| Compression | Lossy |
| Maximum audio channels | 1 |
| Audio frequency bandwidth | 200 Hz to 3,400 Hz |
| Latency | 25 ms |
| Browser compatibility |

| Feature | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari |
| --- | --- | --- | --- | --- | --- | --- |
| AMR support | No | ? | No | ? | No | ? |

 While the Chrome browser does not support AMR, ChromeOS supports
 AMR-NB (narrowband) and AMR-WB (wideband).
  |
| Container support | AMR, 3GPP |
| RTP /
 WebRTC compatible
  | No |
| Licensing |
 Non-free; license fees and annual royalties apply. See
 VoiceAge licensing
 for details
  |

### FLAC (Free Lossless Audio Codec)

**FLAC** (**Free Lossless Audio Codec**) is a lossless audio codec published by the Xiph.org Foundation. It provides good compression rates with no loss of audio fidelity; that is, the decompressed audio is identical to the original. Because the compression algorithm is specifically designed for audio, it gives better results than would be achieved using a general-purpose compression algorithm.

FLAC is a great choice for smaller audio effects files where pristine quality and tonal accuracy are desired, as well as for archival of music.

|  |  |
| --- | --- |
| Supported bit rates | — |
| Variable Bit Rate (VBR) support | No |
| Supported sample formats | 4-bit to 24-bit integers |
| Supported sample rates |
 1 Hz to 65,535 Hz (in 1 Hz increments) or 10 Hz to 655,350 Hz in 10 Hz
 increments
  |
| Recommended minimum bit rate for stereo sound | — |
| Compression | Lossless; up to 40-50% size reduction |
| Maximum audio channels | 8 |
| Audio frequency bandwidth | Full-spectrum |
| Latency | 4.3 ms to 92 ms with 46.4 ms being the typical average |
| Browser compatibility |

| Feature | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari |
| --- | --- | --- | --- | --- | --- | --- |
| FLAC support | Yes | Yes | 51 (desktop)58 (mobile) | No | No | 11 |

 |
| Container support | MP4, Ogg, FLAC |
| RTP /
 WebRTC compatible
  | No |
| Licensing | Fully open and free of any licensing requirements |

### G.711 (Pulse Code Modulation of Voice Frequencies)

The **G.711** specification, published by the International Telecommunications Union (ITU), was issued in 1972 to define standard audio encoding for telephone applications. It supports voice-grade audio covering frequencies from 300 to 3400 Hz. It is used extensively for telephone traffic and voicemail, and it is the highest quality audio encoding which can be transmitted through the public telephone network.

G.711 is not a high fidelity codec, but is instead optimized to support a wide range of voice levels (from whisper to shout) while maintaining high intelligibility and low computational complexity. G.711 uses a logarithmic companding algorithm which provides 14 bits of dynamic range in an 8-bit sample. It uses a sampling rate of 8000 samples/sec, corresponding to a bitrate of 64000 bps.

There are two flavors of G.711 which indicate the exact mathematical equation for the algorithm: µ-law (commonly used in North America and Japan) and A-law (common in the rest of the world). There is no substantial quality difference between the two laws, and it is simple to transcode audio from one to the other. Nevertheless, it is important to specify which law is in use in any replay application or file format. A-law audio will replay poorly if mistakenly uncompressed with the µ-law algorithm, and vice versa.

This codec is required to be supported by all WebRTC solutions because it is simple, easy to implement, widely-used, and broadly compatible across all modern computing platforms.

|  |  |
| --- | --- |
| Supported bit rates | 64 kbps |
| Variable Bit Rate (VBR) support | No |
| Supported sample formats | encoded audio is 8 bits per sample |
| Supported sample rates | 8 kHz |
| Recommended minimum bit rate for stereo sound | 128 kbps |
| Compression | Logarithmic companding (µ-law or A-law) |
| Maximum audio channels | 2 |
| Audio frequency bandwidth | 300 Hz – 3400 Hz |
| Latency | 0.125 ms |
| Browser compatibility |

| Feature | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari |
| --- | --- | --- | --- | --- | --- | --- |
| G.711 support | 23 | 15 | 22 | No | 43 | 11 |

G.711 is supported only for WebRTC connections. |
| Container support | 3GP, WAV |
| RTP /
 WebRTC compatible
  | Yes |
| Licensing |
 All applicable patents have expired, so G.711 is free to use without
 restriction
  |

### G.722 (64 kbps (7 kHz) audio coding)

Published by the International Telecommunications Union (ITU), the **G.722** codec is designed specifically for voice compression. Its audio coding bandwidth is limited to the 50 Hz to 7,000 Hz range, which covers most of the frequency range of typical human vocalization. This makes it ill-suited for handling any audio that might range outside the human speech range, such as music.

G.722 audio is encoded using Adaptive Differential Pulse Code Modulation (ADPCM), in which each sample is represented not by its absolute value, but as a value indicating how much the new sample differs from the previous sample.

G.722 is primarily used with WebRTC connections, as it's one of the audio codecs mandated by the WebRTC specification.

|  |  |
| --- | --- |
| Supported bit rates |
 G.722: 48 kbps, 56 kbps, and 64 kbps; however, in practice 64 kbps is
 always usedG.722 Annex B Super Wide-Band: 64 kbps, 80 kbps, and 96
 kbpsG.722 Annex D Stereo Wide-Band: 64 kbps and 80 kbpsG.722
 Annex D Stereo Super Wide-Band: 80 kbps, 96 kbps, 112 kbps, and 128 kbps
  |
| Variable Bit Rate (VBR) support | No |
| Supported sample formats | 14-bit integer |
| Supported sample rates |
 16 kHz (ADPCM is specified to allow 8 kHz, 11.025 kHz, 22.05 kHz, 44.1
 kHz, but G.722 uses 16 kHz)
  |
| Recommended minimum bit rate for stereo sound | 128 kbps at 44.1 kHz sample rate |
| Compression | Lossy |
| Maximum audio channels | 2 |
| Audio frequency bandwidth | 50 Hz - 7 kHz |
| Latency | 4 ms |
| Browser compatibility |

| Feature | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari |
| --- | --- | --- | --- | --- | --- | --- |
| G.722 support | Yes | Yes | Yes | No | Yes | Yes |

WebRTC only. |
| Container support | 3GP, AMR-WB |
| RTP /
 WebRTC compatible
  | Yes |
| Licensing |
 All applicable patents have expired; G.722 is free to use without
 restriction
  |

### MP3 (MPEG-1 Audio Layer III)

Of the audio formats specified by the MPEG/MPEG-2 standards, **MPEG-1 Audio Layer III**—otherwise known as **MP3**—is by far the most widely used and best-known. The MP3 codec is defined by MPEG-1 Part 3 and MPEG-2 Part 3, and was introduced in 1991 (and finalized in 1992).

When MP3-format audio is stored inside an MPEG container, the resulting file is also referred to as just an "MP3 file" or "MP3." Files with the ubiquitous `.mp3` extension are stored in what is perhaps the most widely distributed audio file format in the world, which is in large part responsible for the digital audio revolution of the late 1990s and early 2000s.

MPEG-1 MP3 audio supports higher bit rates as well as higher sampling rates than MP3 audio in MPEG-2 files. MPEG-1 format MP3 is generally best for music or other complex audio, while MPEG-2 mode MP3 audio is acceptable for speech and other simpler sounds.

The patents behind MP3 have expired, removing many or most licensing concerns around using MP3 files in your projects. That makes them a good choice for many projects.

|  |  |
| --- | --- |
| Supported bit rates | **MPEG-1 mode:** 32 kbps, 40 kbps, 48 kbps, 56 kbps, 64
 kbps, 80 kbps, 96 kbps, 112 kbps, 128 kbps, 160 kbps, 192 kbps, 224
 kbps, 256 kbps, 320 kbps
  |
| **MPEG-2 mode:** 8 kbps, 16 kbps, 24 kbps, 32 kbps, 40
 kbps, 48 kbps, 56 kbps, 64 kbps, 80 kbps, 96 kbps, 112 kbps, 128 kbps,
 144 kbps, 160 kbps
  |
| Variable Bit Rate (VBR) support | Yes |
| Supported sample formats | 16-bit integer |
| Supported sample rates | **MPEG-1 mode:** 32000 Hz, 44100 Hz, 48000 Hz |
| **MPEG-2 mode:** 16000 Hz, 22050 Hz, 24000 Hz (Half the
 frequency of the MPEG-1 supported modes)
  |
| Recommended minimum bit rate for stereo sound | 128 kbps at 48 kHz sample rate |
| Compression | Lossy |
| Maximum audio channels | **MPEG-1 mode:** 2 [2.0] |
| **MPEG-2 mode:** 5 (plus 1 optional Low Frequency
 Enhancement channel) [5.1]
  |
| Audio frequency bandwidth | Varies, depending on bit rate and psychoacoustic analysis |
| Latency | At least 100 ms |
| Browser compatibility |

| Feature | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari |
| --- | --- | --- | --- | --- | --- | --- |
| MP3 support | Yes | Yes | Yes | 9 | Yes | 3.1 |

 |
| Container support | MPEG-1, MPEG-2, MP4, ADTS, 3GP |
| RTP /
 WebRTC compatible
  | No |
| Licensing |
 Patent-free in the EU as of 2012; patent-free in the United States as of
 April 16, 2017; now free to use
  |

For patent reasons, Firefox did not directly support MP3 prior to version 71; instead, platform-native libraries were used to support MP3. This capability was introduced on each platform in different Firefox releases:

MP3 support with external library, by platform, in Firefox| Platform | First Firefox versionwith MP3 support |
| --- | --- |
| Windows (Vista and later) | 22 |
| Android | 20 |
|
 Linux (depends on
 GStreamer)
  | 26 |
| macOS | 35 |

### Opus

The Opus audio format was created by the Xiph.org Foundation as a fully open audio format; it has been standardized by IETF as RFC 6716. It's a good general-purpose audio codec that can efficiently handle both low-complexity audio such as speech as well as music and other high-complexity sounds.

Opus supports multiple compression algorithms, and can even use more than one algorithm in the same audio file, since the encoder can choose the bit rate, audio bandwidth, algorithm, and other details of the compression settings for each frame of audio.

Opus is a good all-around audio codec for use in your web applications, and can be used for any audio tasks you have in mind.

|  |  |
| --- | --- |
| Supported bit rates | 6 kbps - 510 kbps |
| Variable Bit Rate (VBR) support | Yes |
| Supported sample formats | 16-bit integer and 32-bit float (-1.0 to 1.0) |
| Supported sample rates |

| Profile | Effective sample rate |
| --- | --- |
| Narrowband (NB) | 8 kHz |
| Medium band (MB) | 12 kHz |
| Wideband (WB) | 16 kHz |
| Super Wideband (SWB) | 24 kHz |
| Fullband (FB) | 48 kHz |

 The specified sample rates are *effective sample rates*. Opus
 uses an algorithm based on audio bandwidths rather than sample rates.
 See RFC 6716, section 2 for details. In addition, there is an
 *optional* part of the Opus specification (Opus Custom) that
 does allow for non-standard sample rates, but the use of this feature
 is discouraged.
  |
| Recommended minimum bit rate for stereo sound | 96 kbps at 48 kHz sample rate |
| Compression | Lossy |
| Maximum audio channels | 255 (up to 1 LFE channel) |
| Audio frequency bandwidth |

| Profile | Audio bandwidth |
| --- | --- |
| Narrowband (NB) | 4 kHz |
| Medium band (MB) | 6 kHz |
| Wideband (WB) | 8 kHz |
| Super Wideband (SWB) | 12 kHz |
| Fullband (FB) | 20 kHz |

 Although the
 Nyquist–Shannon sampling theorem
 shows that audio bandwidth can be as much as one half of the sampling
 rate, Opus doesn't allow encoding outside a maximum 20 kHz audio
 frequency band, since the human ear can't perceive anything above the
 20 kHz point anyway. This saves some space in the encoded audio.
  |
| Latency | 5 ms to 66.5 ms |
| Browser compatibility |

| Feature | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari |
| --- | --- | --- | --- | --- | --- | --- |
| Opus support | 33 | 14 | 15 | No | 20 | 11 |

 This information refers to support for Opus in HTML
 `<audio>` and `<video>`
 elements, and not to WebRTC.

 Safari supports Opus in the `<audio>` element
 only when packaged in a CAF file, and only on macOS High Sierra
 (10.13) or iOS 11.
  |
| Container support | Ogg, WebM, MPEG-TS, MP4 |
| RTP /
 WebRTC compatible
  | Yes |
| Licensing | Fully open and free of any licensing requirements |

### Vorbis

Vorbis is an open format from the Xiph.org Foundation which supports a wide range of channel combinations, including monaural, stereo, polyphonic, quadraphonic, 5.1 surround, ambisonic, or up to 255 discrete audio channels. Depending on the quality setting used during encoding, the resulting bit rate can vary from around 45 kbps to 500 kbps. Vorbis inherently uses variable bit rate encoding; the bit rate can vary from one sample to the next as needed during the compression process.

Generally, Vorbis is more efficient in terms of size and bit rate than MP3 at similar quality levels. This and its free and open license, make it a good choice for many kinds of audio data as long as its high latency isn't a problem.

|  |  |
| --- | --- |
| Supported bit rates | 45 kbps - 500 kbps |
| Variable Bit Rate (VBR) support | Yes |
| Supported sample formats | 16-bit integer |
| Supported sample rates | 8 kHz - 192 kHz |
| Recommended minimum bit rate for stereo sound |
 192 kbps at 48 kHz; this is typically accomplished by setting the
 quality level to 6 to 8.
  |
| Compression | Lossy |
| Maximum audio channels | 255 |
| Audio frequency bandwidth |  |
| Latency | At least 100 ms |
| Browser compatibility |

| Feature | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari |
| --- | --- | --- | --- | --- | --- | --- |
| Vorbis support | 4 | 17 | 3.5 | No | 11.5 | No |

 This information refers to support for Vorbis in HTML
 `<audio>` and `<video>`
 elements, and not to WebRTC.
  |
| Container support | Ogg, WebM |
| RTP /
 WebRTC compatible
  | Yes |
| Licensing | Fully open and free of any licensing requirements |

Choosing an audio codec
-----------------------

Typically, regardless of what codec you use, it will generally get the job done, even if it's not the ideal choice, as long as you choose a codec not specifically designed for a totally different kind of source audio. Choosing a voice-only codec and trying to use it for music will not give you usable results, for instance.

Some codecs may limit compatibility, however, and others may be more optimal for your needs than others. Here we'll provide guidance to help you select an appropriate codec for your use case.

When choosing a codec to use for your audio, you should first consider the following questions:

* Will the encoded audio be getting remixed or recompressed? If so, avoid lossy compression, which would be compounded by recompressing the audio; or at least use as little compression as possible.
* If the audio needs to go into a specific file type, keep that in mind, since media containers typically support a specific subset of the available codecs.
* What kind of audio content will the codec be handling? Certain codecs are specifically designed for voice-only content (they take advantage of the reduced frequency range needed for human speech). Others may have an algorithmic tendency to perform worse when encoding specific genres of music.
* What bit rates and other configurable properties does each codec have that may make it a good (or poor) choice?
* To what extent, if at all, does latency matter for your needs? If you need sound that is very precisely timed, the lower the latency the better.
* How much compression do you need to achieve?

Let's consider a few common scenarios to get a feel for the decision-making process.

### Example: Music for streaming

For streaming music, you want to select a codec that minimizes bandwidth usage as much as possible while introducing as few artifacts as possible into the audio through compression. This is necessary because the rate at which the music is downloaded needs to be no greater than the amount of bandwidth available on the network, and ideally there should be room left for network speed fluctuations and use of the network by other applications.

Unless there's a specific need for lossless compression, or the network bandwidth is guaranteed to be high enough to support it, a lossy compression scheme is a good choice. Which one you choose depends on browser compatibility and the availability of any special features you may need the codec to support.

*Usually* the latency is not particularly important when streaming music. Possible exceptions include looped music, where you need music to be able to play back uninterrupted over and over, or when you need to be able to play songs back to back with no gap between them. This can be particularly important for classical music, theatrical soundtracks, and for background music during gameplay.

For general music playback, the three most likely candidates are MP3, AAC, and Vorbis.

* AAC in an MP4 container is supported by all major browsers, which makes this a great choice.
* Vorbis is almost always used in Ogg files, but Ogg containers are not universally supported. Even Microsoft Edge, which supports both Vorbis, does not yet support Ogg containers.
* MP3 (MPEG-1 Audio Layer III) is supported by all major browsers. These files are MPEG-1 files that contain an Audio Layer III track.

If you need to minimize latency during music playback, you should strongly consider Opus, which has the lowest range of latencies of the general-purpose codecs (5 ms to 66.5 ms, compared to at least 100 ms for the others).

**Note:** Compatibility information described here is generally correct as of the time this article was written; however, there may be caveats and exceptions. Be sure to refer to the compatibility tables before committing to a given media format.

Based on this, AAC is likely your best choice if you can only support one audio format. Of course, if you can provide multiple formats (for example, by using the `<source>` element within your `<audio>` and `<video>` elements), you can avoid many or all of those exceptions.

### Example: Music for download

Music being downloaded by the user can be compressed to a larger overall file size than streamed music, since (unlike when streaming) it doesn't matter if the download speed is slower than the playback speed of the media. That means you can consider using lossy compression at higher bit rates, which results in larger files but with less loss of fidelity. Or you can choose a lossless format. The choice depends largely on the union of your application's requirements and the preferences of your users.

For an actual music download service, you might offer songs for download as 128 Kbps MP3 files, 256 kbps AAC files (in MP4 containers), or FLAC files, depending on a preference selected by the user. If you need to choose just one format, select one that makes sense given your requirements and the type of audio content being downloaded.

Generally, of course, MP3 is the most common format used for music; choose a bit rate of at least 192 kbps if possible. The iTunes store, on the other hand, distributes music in 256 kbps AAC format.

### Example: Voice recording and playback

The specific characteristics of human speech allow speech-specific codecs to compress the audio far more than most general-purpose codecs can. That's because although humans hear frequencies ranging from around 20 Hz to 20,000 Hz, and human speech sounds range from about 300 Hz to 18,000 Hz, the majority of the speech sounds that we need in order to understand what's being said lie in the frequency range of 500 Hz to 3,000 Hz or so. That means voice-only codecs can throw away everything else.

The voice-specific codecs are all inherently very lossy, however, and any sound with significant information in the frequency bands outside the vocal range captured will be entirely lost. This makes these codecs completely unsuitable for anything but spoken words. Even audio that contains only voices, but singing rather than speaking, will likely not be of acceptable quality in one of these formats.

Voice recording and playback usually needs to be low-latency in order to synchronize with video tracks, or in order to avoid cross-talk or other problems. Fortunately, the characteristics that lead to speech codecs being so efficient storage space-wise also make them tend to be very low latency. If you're working with WebRTC, G.722, for example, has 4 ms latency (compared with over 100 ms for MP3), and AMR's latency is around 25 ms.

**Note:** For more about WebRTC and the codecs it can use, see Codecs used by WebRTC.

The codecs generally used on the web that are used for voice-only encoding are G.722 and AMR. AMR is a narrowband codec, encoding only the frequencies between 200 Hz and 3,400 Hz at bit rates typically around 7.4 kbps, while G.722 is a wideband codec that expands the audio bandwidth to 50 Hz to 7,000 Hz at much higher bit rates—usually 64 kbps.

If you have plenty of network bandwidth to work with, and are reasonably certain your users will as well, G.722 is the better choice. To maximize the storage and network efficiency in a constrained environment, choose AMR.

### Example: Audio clips for professional mixing

When compressing audio that will be getting mixed or remixed, you typically want zero or close to zero loss of fidelity, which suggests a lossless codec may be in order. However, because lossless encoding naturally has a much lower compression level than lossy encoding, you may find that if your source audio is large enough, you might have to choose a lossy encoder anyway, especially in a web environment in which you can't control the download rate of the media.

Assuming that lossless compression is our best option here (which it usually is, as long as the audio files are small), the three strongest candidates from a codec perspective are FLAC, Apple Lossless (ALA, and MPEG-4 ALS. Which we choose will depend on browser support and which media container formats support them.

For the purposes of this example, we'll assume that all browsers have the same codec and container support as Firefox (although this is far from true). Consider the breadth of actual support for the codecs when making your decisions.

* Firefox supports FLAC in FLAC's native containers as well as in Ogg and MPEG-4 (MP4) files.
* Firefox only supports Apple Lossless through its platform-specific QuickTime support.
* Firefox doesn't support MP4 ALS.

In this case, it appears that FLAC is most likely the best codec to go with; ALAC has little to no direct browser support.

Audio encoding software
-----------------------

There are many tools available for encoding audio. The simplest are those which are meant for ripping CDs or pulling in audio files and quickly and automatically converting them to MP3 or AAC format to store in a library, such as iTunes. But when developing web apps that use audio as a component of the app, such as games, you will need more control over the encoding process and more options surrounding the format used while encoding the audio.

A few popular options:

FFmpeg

Arguably the best-known and most widely regarded open source codec package available, FFmpeg supports the majority of the most popular audio formats and provides command-line tools and libraries for encoding, decoding, and performing format conversions of both audio and video. Binaries are available for macOS, Linux, and Windows.

Handbrake

A highly popular open source front-end to FFmpeg which adds a graphical user interface that makes it much easier to control the wide variety of options FFmpeg offers while encoding audio and/or video. Binaries are available for macOS, Linux, and Windows.

Audacity

An open source audio editor that supports loading audio from many different formats, editing, filtering, and adjusting the audio, and saving it back out in either the original format or a new format. Available for macOS, Linux, and Windows.

LAME

A high quality open source MP3 encoder with support for CBR, ABR, and VBR encoding as well as a variety of other options. Distributed only in source form by the LAME project, but can be installed using Homebrew or similar tools.

See also
--------

* Media container formats
* The `<audio>` and `<video>` elements
* WebRTC API
* Web video codec guide
* Codecs used by WebRTC


Media container formats (file types) - Web media technologies

Media container formats (file types)
====================================

 The format of audio and video media files is defined in two parts (three if a file has both audio and video in it, of course): the audio and/or video codecs used and the media container format (or file type) used.
 In this guide, we'll look at the container formats used most commonly on the web, covering basics about their specifications as well as their benefits, limitations, and ideal use cases.

WebRTC does not use a container at all.
 Instead, it streams the encoded audio and video tracks directly from one peer to another using `MediaStreamTrack` objects to represent each track.
 See Codecs used by WebRTC for information about codecs commonly used for making WebRTC calls, as well as browser compatibility information around codec support in WebRTC.

Common container formats
------------------------

 While there are a vast number of media container formats, the ones listed below are the ones you are most likely to encounter.
 Some support only audio while others support both audio and video.
 The MIME types and extensions for each are listed. The most commonly used containers for media on the web are probably MPEG-4 (MP4), Web Media File (WEBM), and MPEG Audio Layer III (MP3).
 However, you may also encounter MP3, Ogg, WAV, AVI, MOV, and other formats.
 Not all of these are broadly supported by browsers, however; some combinations of container and codec are sometimes given their own file extensions and MIME types as a matter of convenience, or because of their ubiquity.
 For example, an Ogg file with only an Opus audio track is sometimes referred to as an Opus file, and might even have the extension `.opus`.
 But it's still actually just an Ogg file.

 In other cases, a particular codec, stored in a certain container type, is so ubiquitous that the pairing is treated in a unique fashion.
 A good example of this is the MP3 audio file, which is in fact an MPEG-1 container with a single audio track encoded using MPEG-1 Audio Layer III encoding.
 These files use the `audio/mp3` MIME type and the `.mp3` extension, even though their containers are just MPEG.

### Index of media container formats (file types)

To learn more about a specific container format, find it in this list and click through to the details, which include information about what the container is typically useful for, what codecs it supports, and which browsers support it, among other specifics.

| Codec name (short) | Full codec name | Browser compatibility |
| --- | --- | --- |
| 3GP | Third Generation Partnership | Firefox for Android |
| ADTS | Audio Data Transport Stream | Firefox
Available only if available on the underlying operating system's media framework. |
| FLAC | Free Lossless Audio Codec | Chrome 56, Edge 16, Firefox 51, Safari 11 |
| MPEG / MPEG-2 | Moving Picture Experts Group (1 and 2) | — |
| MPEG-4 (MP4) | Moving Picture Experts Group 4 | Chrome 3, Edge 12, Firefox, Internet Explorer 9, Opera 24, Safari 3.1 |
| Ogg | Ogg | Chrome 3, Firefox 3.5, Edge 17 (desktop only), Internet Explorer 9, Opera 10.50
Edge requires Web Media Extensions to be installed. |
| QuickTime (MOV) | Apple QuickTime movie | Only older versions of Safari, plus other browsers that supported Apple's QuickTime plugin |
| WebM | Web Media | Chrome 6, Edge 17 (desktop only), Firefox 4, Opera 10.6, Safari 14.1 (macOS), Safari 15 (iOS).
Edge requires Web Media Extensions to be installed. |

 Unless otherwise specified, both mobile and desktop browser compatibility is implied if a browser is listed here.
 Support is also implied only for the container itself, not for any specific codecs.

### 3GP

 The **3GP** or **3GPP** media container is used to encapsulate audio and/or video that is specifically intended for transmission over cellular networks for consumption on mobile devices.
 The format was designed for use on 3G mobile phones, but can still be used on more modern phones and networks.
 However, the improved bandwidth availability and increased data caps on most networks has reduced the need for the 3GP format.
 However, this format is still used for slower networks and for lower-performance phones.

This media container format is derived from the ISO Base Media File Format and MPEG-4, but is specifically streamlined for lower bandwidth scenarios.

| Audio | Video |
| --- | --- |
| `audio/3gpp` | `video/3gpp` |
| `audio/3gpp2` | `video/3gpp2` |
| `audio/3gp2` | `video/3gp2` |

 These MIME types are the fundamental types for the 3GP media container; other types may be used depending on the specific codec or codecs in use.
 In addition, you can add the `codecs` parameter to the MIME type string to indicate which codecs are used for the audio and/or video tracks, and to optionally provide details about the profile, level, and/or other codec configuration specifics.

Video codecs supported by 3GP| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| AVC (H.264) |  |  |  |  |
| H.263 |  |  |  |  |
| MPEG-4 Part 2 (MP4v-es) |  |  |  |  |
| VP8 |  |  |  |  |

Audio codecs supported by 3GP| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| AMR-NB |  |  |  |  |
| AMR-WB |  |  |  |  |
| AMR-WB+ |  |  |  |  |
| AAC-LC |  |  |  |  |
| HE-AAC v1 |  |  |  |  |
| HE-AAC v2 |  |  |  |  |
| MP3 |  |  |  |  |

### ADTS

**Audio Data Transport Stream** (**ADTS**) is a container format specified by MPEG-4 Part 3 for audio data, intended to be used for streamed audio, such as for Internet radio.
 It is, essentially, an almost bare stream of AAC audio data, comprised of ADTS frames with a minimal header.

| Audio |
| --- |
| `audio/aac` |
| `audio/mpeg` |

 The MIME type used for ADTS depends on what kind of audio frames are contained within.
 If ADTS frames are used, the `audio/aac` MIME type should be used.
 If the audio frames are in MPEG-1/MPEG-2 Audio Layer I, II, or III format, the MIME type should be `audio/mpeg`.

Audio codecs supported by ADTS| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| AAC |  |  | Yes |  |
| MP3 |  |  | Yes |  |

Firefox support for AAC relies upon the operating system's media infrastructure, so it is available as long as the OS supports it.

### FLAC

 The **Free Lossless Audio Codec** (**FLAC**) is a lossless audio codec; there is also an associated simple container format, also called FLAC, that can contain this audio.
 The format is not encumbered by any patents, so its use is safe from interference.
 FLAC files can only contain FLAC audio data.

| Audio |
| --- |
| `audio/flac` |
| `audio/x-flac` (non-standard) |

Audio codecs supported by FLAC| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| FLAC |  |  | Yes |  |

### MPEG/MPEG-2

 The **MPEG-1** and **MPEG-2** file formats are essentially identical.
 Created by the Moving Picture Experts Group (MPEG), these formats are widely used in physical media, including as the format of the video on DVD media.

 On the internet, perhaps the most common use of the MPEG file format is to contain Layer\_III/MP3 sound data; the resulting files are the wildly popular MP3 file used by digital music devices around the world.
 Otherwise, MPEG-1 and MPEG-2 are not widely used in Web content.

 The main differences between MPEG-1 and MPEG-2 take place in the media data formats rather than the container format.
 MPEG-1 was introduced in 1992; MPEG-2 was introduced in 1996.

| Audio | Video |
| --- | --- |
| `audio/mpeg` | `video/mpeg` |

Video codecs supported by MPEG-1 and MPEG-2| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| MPEG-1 Part 2 |  |  | No |  |
| MPEG-2 Part 2 |  |  | No |  |

Audio codecs supported by MPEG-1 and MPEG-2| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| MPEG-1 Audio Layer I |  |  | No |  |
| MPEG-1 Audio Layer II |  |  | No |  |
| MPEG-1 Audio Layer III (MP3) |  |  | Yes |  |

### MPEG-4 (MP4)

**MPEG-4** (**MP4**) is the latest version of the MPEG file format.
 There are two versions of the format, defined in parts 1 and 14 of the specification.
 MP4 is a popular container today, as it supports several of the most-used codecs and is broadly supported.

 The original MPEG-4 Part 1 file format was introduced in 1999; the version 2 format, defined in Part 14, was added in 2003.
 The MP4 file format is derived from the ISO base media file format, which is directly derived from the QuickTime file format developed by Apple.

When specifying the MPEG-4 media type (`audio/mp4` or `video/mp4`), you can add the `codecs` parameter to the MIME type string to indicate which codecs are used for the audio and/or video tracks, and to optionally provide details about the profile, level, and/or other codec configuration specifics.

| Audio | Video |
| --- | --- |
| `audio/mp4` | `video/mp4` |

 These MIME types are the fundamental types for the MPEG-4 media container; other MIME types may be used depending on the specific codec or codecs in use within the container.
 In addition, you can add the `codecs` parameter to the MIME type string to indicate which codecs are used for the audio and/or video tracks, and to optionally provide details about the profile, level, and/or other codec configuration specifics.

Video codecs supported by MPEG-4| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| AVC (H.264) |  |  | Yes

 Firefox support for H.264 relies upon the operating system's media
 infrastructure, so it is available as long as the OS supports it.
  |  |
| AV1 |  |  | Yes
Firefox support for AV1 is disabled on Windows on ARM (enable by setting the preference `media.av1.enabled` to `true`). |  |
| H.263 |  |  | No |  |
| MPEG-4 Part 2 Visual |  |  | No |  |
| VP9 |  |  | Yes |  |

Audio codecs supported by MPEG-4| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| AAC |  |  | Yes
Firefox support for H.264 relies upon the operating system's media infrastructure, so it is available as long as the OS supports it. |  |
| FLAC |  |  | Yes |  |
| MPEG-1 Audio Layer III (MP3) |  |  | Yes |  |
| Opus |  |  | Yes |  |

### Ogg

 The Ogg container format is a free and open format maintained by the Xiph.org Foundation.
 The Ogg framework also defines patent unencumbered media data formats, such as the Theora video codec and the Vorbis and Opus audio codecs.
 Xiph.org documents about the Ogg format are available on their website.

 While Ogg has been around for a long time, it has never gained the wide support needed to make it a good first choice for a media container.
 You are typically better off using WebM, though there are times when Ogg is useful to offer, such as when you wish to support older versions of Firefox and Chrome which don't yet support WebM.
 For example, Firefox 3.5 and 3.6 support Ogg, but not WebM.

You can get more information about Ogg and its codecs in the Theora Cookbook.

| Audio | Video |
| --- | --- |
| `audio/ogg` | `video/ogg` |

 The `application/ogg` MIME type can be used when you don't necessarily know whether the media contains audio or video.
 If at all possible, you should use one of the specific types, but fall back to `application/ogg` if you don't know the content format or formats.

You can also add the `codecs` parameter to the MIME type string to indicate which codecs are used for the audio and/or video tracks, and to optionally further describe the track media formats.

Video codecs supported by Ogg| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| Theora |  |  | Yes |  |
| VP8 |  |  | Yes |  |
| VP9 |  |  | Yes |  |

Audio codecs supported by Ogg| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| FLAC |  |  | Yes |  |
| Opus |  |  | Yes |  |
| Vorbis |  |  | Yes |  |

### QuickTime

 The **QuickTime** file format (**QTFF**, **QT**, or **MOV**) was created by Apple for use by its media framework of the same name.
 The extension for these files, `.mov`, comes from the fact that the format was initially used for movies and was usually called the "QuickTime movie" format.
 While QTFF served as the basis for the MPEG-4 file format, there are differences and the two are not quite interchangeable.

 QuickTime files support any sort of time-based data, including audio and video media, text tracks, and so forth.
 QuickTime files are primarily supported by macOS, but for a number of years, QuickTime for Windows was available to access them on Windows.
 However, QuickTime for Windows is no longer supported by Apple as of early 2016, and *should not be used*, as there are known security concerns.
 However, Windows Media Player now has integrated support for QuickTime version 2.0 and earlier files; support for later versions of QuickTime requires third-party additions.

 On Mac OS, the QuickTime framework not only supported QuickTime format movie files and codecs, but supported a vast array of popular and specialty audio and video codecs, as well as still image formats.
 Through QuickTime, Mac applications (including web browsers, through the QuickTime plugin or direct QuickTime integration) were able to read and write audio formats including AAC, AIFF, MP3, PCM, and Qualcomm PureVoice; and video formats including AVI, DV, Pixlet, ProRes, FLAC, Cinepak, 3GP, H.261 through H.265, MJPEG, MPEG-1 and MPEG-4 Part 2, Sorenson, and many more.

In addition, a number of third-party components are available for QuickTime, some of which add support for additional codecs.

 Because QuickTime support is, for all intents and purposes, primarily available on Apple devices, it is no longer widely used on the internet.
 Apple itself generally now uses MP4 for video.
 In addition, the QuickTime framework has been deprecated on the Mac for some time, and is no longer available at all starting in macOS 10.15 Catalina.

| Video |
| --- |
| `video/quicktime` |

 The `video/quicktime` MIME type is the fundamental type for the QuickTime media container.
 It's worth noting that QuickTime (the media framework on Mac operating systems) supports a wide variety of containers and codecs, so it actually supports many other MIME types.

You can add the `codecs` parameter to the MIME type string to indicate which codecs are used for the audio and/or video tracks, and to optionally provide details about the profile, level, and/or other codec configuration specifics.

Video codecs supported by QuickTime| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| AVC (H.264) |  |  | No |  |
| Cinepak |  |  | No |  |
| Component Video |  |  | No |  |
| DV |  |  | No |  |
| H.261 |  |  | No |  |
| H.263 |  |  | No |  |
| MPEG-2 |  |  | No |  |
| MPEG-4 Part 2 Visual |  |  | No |  |
| Motion JPEG |  |  | No |  |
| Sorenson Video 2 |  |  | No |  |
| Sorenson Video 3 |  |  | No |  |

Audio codecs supported by QuickTime| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| AAC |  |  | No |  |
| ALaw 2:1 |  |  | No |  |
| Apple Lossless (ALAC) |  |  | No |  |
| HE-AAC |  |  | No |  |
| MPEG-1 Audio Layer III (MP3) |  |  | No |  |
| Microsoft ADPCM |  |  | No |  |
| µ-Law 2:1 (u-Law) |  |  | No |  |

### WAVE (WAV)

The **Waveform Audio File Format** (**WAVE**), usually referred to as WAV due to its filename extension being `.wav`, is a format developed by Microsoft and IBM to store audio bitstream data.

 It is derived from the Resource Interchange File Format (RIFF), and as such is similar to other formats such as Apple's AIFF.
 The WAV codec registry can be found at RFC 2361; however, because nearly all WAV files use linear PCM, support for the other codecs is sparse.

The WAVE format was first released in 1991.

| Audio |
| --- |
| `audio/wave` |
| `audio/wav` |
| `audio/x-wav` |
| `audio/x-pn-wav` |

The `audio/wave` MIME type is the standard type, and is preferred; however, the others have been used by various products over the years and may be used as well in some environments.

Audio codecs supported by WAVE| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| ADPCM (Adaptive Differential Pulse Code Modulation) |  |  | No |  |
| GSM 06.10 |  |  | No |  |
| LPCM (Linear Pulse Code Modulation) |  |  | Yes |  |
| MPEG-1 Audio Layer III (MP3) |  |  | No |  |
| µ-Law (u-Law) |  |  | No |  |

### WebM

**WebM** (**Web Media**) is a format based on Matroska which is designed specifically for use in modern web environments.
 It's based entirely on free and open technologies and primarily uses codecs that are in turn free and open, although some products support other codecs in WebM containers as well.

 WebM was first introduced in 2010 and is now widely supported.
 Compliant implementations of WebM are required to support the VP8 and VP9 video codecs and the Vorbis and Opus audio codecs.
 The WebM container format and its required codecs are all available under open licenses.
 Any other codecs may require a license to use.

| Audio | Video |
| --- | --- |
| `audio/webm` | `video/webm` |

Video codecs supported by WebM| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| AV1 | Yes | Yes | Yes

 Firefox support for AV1 was added to macOS in Firefox 66; for Windows in Firefox 67; and Firefox 68 on Linux.
 Firefox for Android does not yet support AV1; the implementation in Firefox is designed to use a secure process, which is not supported yet in Android.
  | Yes |
| VP8 | Yes | Yes | Yes | Yes |
| VP9 | Yes | Yes | Yes | Yes |

Audio codecs supported by WebM| Codec | Browser support |
| --- | --- |
| Chrome | Edge | Firefox | Safari |
| Opus | Yes | Yes | Yes | Yes |
| Vorbis | Yes | Yes | Yes | Yes |

Choosing the right container
----------------------------

 There are a few factors to consider when selecting the best container or containers to use for your media.
 The relative importance of each will depend on your needs, your license requirements, and the compatibility requirements of your target audience.

### Guidelines

 The best choice also depends on what you'll be doing with the media.
 Playing back media is a different thing than recording and/or editing it.
 If you're going to be manipulating the media data, using an uncompressed format can improve performance, while using a lossless compressed format at least prevents the accumulation of noise as compression artifacts are multiplied with each re-compression that occurs.

* If your target audience is likely to include users on mobile, especially on lower-end devices or on slow networks, consider providing a version of your media in a 3GP container with appropriate compression.
* If you have any specific encoding requirements, make sure the container you choose supports the appropriate codecs.
* If you want your media to be in a non-proprietary, open format, consider using one of the open container formats such as FLAC (for audio) or WebM (for video).
* If for any reason you are only able to provide media in a single format, choose a format that's available on the broadest selection of devices and browsers, such as MP3 (for audio) or MP4 (for video and/or audio).
* If your media is audio-only, choosing an audio-only container format likely makes sense.
 Now that the patents have all expired, MP3 is a widely supported and good choice.
 WAVE is good but uncompressed, so be aware of that before using it for large audio samples.
 FLAC is a very good choice, due to its lossless compression, if the target browsers all support it.

 Unfortunately, neither of the relatively major lossless compression formats (FLAC and ALAC) are universally supported.
 FLAC is the more broadly supported of the two, but is not supported by macOS without additional software installed, and is not supported at all on iOS.
 If you need to offer lossless audio, you may need to provide both FLAC and ALAC to get close to universal compatibility.

### Container selection advice

 The tables below offer suggested containers to use in various scenarios.
 These are just suggestions.
 Be sure to consider the needs of your application and your organization before selecting a container format.

#### Audio-only files

| If you need… | Consider using this container format |
| --- | --- |
| Compressed files for general-purpose playback | MP3 (MPEG-1 Audio Layer III) |
| Losslessly compressed files | FLAC with ALAC fallback |
| Uncompressed files | WAV |

 Now that MP3's patents have all expired, the choice of audio file format has become much easier to make.
 It's no longer necessary to choose between MP3's broad compatibility and the need to pay royalties when using it.

#### Video files

| If you need… | Consider using this container format |
| --- | --- |
| General purpose video, preferably in an open format | WebM (ideally with MP4 fallback) |
| General purpose video | MP4 (ideally with WebM or Ogg fallback) |
| High compression optimized for slow connections | 3GP (ideally with MP4 fallback) |
| Compatibility with older devices/browsers | QuickTime (ideally with AVI and/or MPEG-2 fallback) |

 These suggestions make a number of assumptions.
 You should carefully consider the options before making a final decision, especially if you have a lot of media that will need to be encoded.

Maximizing compatibility with multiple containers
-------------------------------------------------

 To optimize compatibility, it's worth considering providing more than one version of media files, using the `<source>` element to specify each source within the `<audio>` or `<video>` element.
 For example, you can offer an Ogg or WebM video as the first choice, with a fallback in MP4 format.
 You could even choose to offer a retro-like QuickTime or AVI fallback for good measure.

 To do this, you create a `<video>` (or `<audio>`) element with no `src` attribute.
 Then add child `<source>` elements within the `<video>` element, one for each version of the video you offer.
 This can be used to offer various versions of a video that can be selected depending on bandwidth availability, but in our case, we'll use it to offer format options.

In the example shown here, a video is offered to the browser in two formats: WebM and MP4.

Try it
------

 The video is offered first in WebM format (with the `type` attribute set to `video/webm`).
 If the user agent can't play that, it moves on to the next option, whose `type` is specified as `video/mp4`.
 If neither of those can be played, the text "This browser does not support the HTML video element." is presented.

Specifications
--------------

| Specification | Comment |
| --- | --- |
| ETSI 3GPP | Defines the 3GP container format |
| ISO/IEC 14496-3 (MPEG-4 Part 3 Audio) | Defines MP4 audio including ADTS |
| FLAC Format | The FLAC format specification |
| ISO/IEC 11172-1 (MPEG-1 Part 1 Systems) | Defines the MPEG-1 container format |
| ISO/IEC 13818-1 (MPEG-2 Part 1 Systems) | Defines the MPEG-2 container format |
| ISO/IEC 14496-14 (MPEG-4 Part 14: MP4 file format) | Defines the MPEG-4 (MP4) version 2 container format |
| ISO/IEC 14496-1 (MPEG-4 Part 1 Systems) | Defines the original MPEG-4 (MP4) container format |
| RFC 3533 | Defines the Ogg container format |
| RFC 5334 | Defines the Ogg media types and file extensions |
| QuickTime File Format Specification | Defines the QuickTime movie (MOV) format |
| Multimedia Programming Interface and Data Specifications 1.0 | The closest thing to an official WAVE specification |
| Resource Interchange File Format (used by WAV) | Defines the RIFF format; WAVE files are a form of RIFF |
| WebM Container Guidelines | Guide for adapting Matroska for WebM |
| Matroska Specifications | The specification for the Matroska container format upon which WebM is based |
| WebM Byte Stream Format | WebM byte stream format for use with Media Source Extensions |

Browser compatibility
---------------------

| Container format name | Audio | Video |
| --- | --- | --- |
| MIME type | Extension(s) | Browser support | MIME type | Extension(s) | Browser support |
| 3GP | `audio/3gpp` | `.3gp` | Firefox | `video/3gpp` | `.3gp` | Firefox |
| ADTS (Audio Data Transport Stream) | `audio/aac` | `.aac` | Firefox | — | — | — |
| FLAC | `audio/flac` | `.flac` | Firefox | — | — | — |
| MPEG-1 / MPEG-2 (MPG or MPEG) | `audio/mpeg` | `.mpg``.mpeg` | Firefox | `video/mpeg` | `.mpg``.mpeg` | Firefox |
| `audio/mp3` | `.mp3` | Firefox |
| MPEG-4 (MP4) | `audio/mp4` | `.mp4``.m4a` | Firefox | `video/mp4` | `.mp4``.m4v``.m4p` | Firefox |
| Ogg | `audio/ogg` | `.oga``.ogg` | Firefox | `video/ogg` | `.ogv``.ogg` | Firefox |
| QuickTime Movie (MOV) | — | — | — | `video/quicktime` | `.mov` | Safari |
| WAV (Waveform Audiofile) | `audio/wav` | `.wav` | Firefox | — | — | — |
| WebM | `audio/webm` | `.webm` | Firefox | `video/webm` | `.webm` | Firefox |

See also
--------

* WebRTC API
* MediaStream Recording API
* `<audio>` and `<video>` elements


Digital audio concepts - Web media technologies

Digital audio concepts
======================

Representing audio in digital form involves a number of steps and processes, with multiple formats available both for the raw audio and the encoded or compressed audio which is actually used on the web. This guide is an overview examining how audio is represented digitally, and how codecs are used to encode and decode audio for use on the web.

Sampling audio
--------------

Audio is an inherently analog feature of the natural world. As an object vibrates, it causes the molecules surrounding it to vibrate as well. These molecules affect the ones adjacent to them, and so forth, propagating the vibration in the form of a wave outward from the source until the amplitude of the wave (its volume) fades away with distance. The granularity of an audio wave in the real world, then, is that of an individual molecule of the medium through which the sound wave is traveling.

On Earth, the medium most audio travels through is the air. Some audio does travel through water, or even through the rock comprising the planet itself (if you've ever heard the rumble or boom of an earthquake, you've experienced this phenomenon), but nearly all of the sounds you hear every day travel to your ears through the air.

The sounds a person hears every day are, then, actually vibrations in the air which cause the inner workings of the ear. The farther the air molecules move with each pulse of the wave, the higher the amplitude of the wave, and the louder the sound is. The faster the molecules vibrate, the higher the frequency of the wave.

The higher the amplitude (height) of the wave, the louder the sound is at that instant. The shorter the wavelength (the closer together the crests of the wave are), the higher the frequency (or pitch) of the sound that's produced.

![A simple sound waveform](/en-US/docs/Web/Media/Formats/Audio_concepts/audio-waveform.svg)

Computers, however, are digital. In order to represent a sound wave in a way computers can manipulate and work with (let alone transmit over a network), the sound has to be converted into a digital form. This process is called **analog to digital conversion** (**A/D** for short).

The first factor affecting the fidelity of the captured audio is the **audio bandwidth**; that is, the range of audio frequencies the A/D converter is capable of capturing and converting into digital form. The audio bandwidth is also affected by the codec, if it chooses to discard any frequency bands while encoding the sound.

Sound enters the computer through a microphone or other input in the form of a stream of electrons whose voltage varies to represent the amplitude of the sound wave. This analog signal is then converted into digital form by a circuit that captures the incoming wave's amplitude at regular intervals, converting that data into a number in a form that is understood by the audio recording system. Each of these captured moments is a **sample**. By chaining all the samples together, you can approximately represent the original wave, as seen in the diagram below.

![An audio waveform with samples taken periodically](/en-US/docs/Web/Media/Formats/Audio_concepts/audio-waveform-samples1.svg)

In this example, the blue line represents the samples taken from the audio waveform, which is black. At regular intervals, the A/D converter circuitry reads the voltage of the signal as a value between (in this case) -1.0 and +1.0. Since the amplitude varies over the duration of that time slice, the A/D converter must choose a value to represent that slice, whether by taking the value at a particular moment (in the diagram above, the midpoint of each slice is used as the value), or by averaging the amplitude over the duration of each sample. Those sample values are then recorded as the amplitude of the waveform at that time.

When it comes time to play back that sound later, these amplitudes are used to generate an approximation of the original waveform; instead of playing back an exact duplicate of the original, smooth wave, the rougher, blue wave is played.

The more often you take samples of the original audio, the closer to the original you can get. The number of samples taken per second is called the **sample rate**. Consider the wave above, and how much different the blue, digital wave would look if you took samples twice as often. Or ten times as often. The more samples you take, the smoother the wave becomes.

Audio data format and structure
-------------------------------

At the most basic level, audio is represented by a stream of samples, each specifying the amplitude of the audio waveform as measured for a given slice of the overall waveform of the audio signal. There are several formats used for the individual samples within an audio file. Most audio files use 16-bit signed integers for each sample, but others use 32-bit floating-point values or 24-bit or 32-bit integers. Some older audio file formats—which you won't find in use on the web—used 8-bit integer samples. In addition, samples may use signed or unsigned values, as well. The size of an individual sample is called the **sample size**.

The position of each audio source within the audio signal is called a **channel**. Each channel contains a sample indicating the amplitude of the audio being produced by that source at a given moment in time. For instance, in stereo sound, there are two audio sources: one speaker on the left, and one on the right. Each of these is represented by one channel, and the number of channels contained in the audio signal is called the **channel count**.

While recording or generating multi-channel audio files, the channels are assembled into a series of **audio frames**, each consisting of one sample for each of the audio's channels. An individual sample is a numeric value representing the amplitude of the sound waveform at a single moment in time, and may be represented in various formats.

Stereo audio is probably the most commonly used channel arrangement in web audio, and 16-bit samples are used for the majority of day-to-day audio in use today. For 16-bit stereo audio, each sample taken from the analog signal is recorded as two 16-bit integers, one for the left channel and one for the right. That means each sample requires 32 bits of memory. At the common sample rate of 48 kHz (48,000 samples per second), this means each second of audio occupies 192 kB of memory. Therefore, a typical three-minute song requires about 34.5 MB of memory. That's a lot of storage, but worse, it's an insane amount of network bandwidth to use for a relatively short piece of audio. That's why most digital audio is compressed.

The process of compressing and decompressing audio is performed by encoding and decoding it using an audio **codec** (**CO**der/**DE**coder). Over the years, a large variety of codecs have been developed, several of which are commonly used on the web. For details about the most important and useful ones for web developers to be familiar with, see the article Guide to audio codecs used on the web.

### Audio channels and frames

There are two types of audio channel. Standard audio channels are used to present the majority of the audible sound. The sound for the left and right main channels, as well as all of your surround sound speakers (center, left and right rear, left and right sides, ceiling channels, and so forth) are all standard audio channels. Special **Low Frequency Enhancement** (**LFE**) channels provide the signal for special speakers designed to produce the low frequency sounds and vibration to create a visceral sensation when listening to the audio. The LFE channels typically drive subwoofers and similar devices.

Monophonic audio has one channel, stereo sound has two channels, 5.1 surround sound has 6 channels (five standard and one LFE), and so forth. Each audio frame is a data record that contains the samples for all of the channels available in an audio signal. The size of an audio frame is calculated by multiplying the sample size in bytes by the number of channels, so a single frame of stereo 16-bit audio is 4 bytes long and a single frame of 5.1 floating-point audio is 24 (4 bytes per sample multiplied by 6 channels).

**Note:** Some codecs will actually separate the left and right channels, storing them in separate blocks within their data structure. However, an audio frame is always comprised of all of the data for all available channels.

The number of frames that comprise a single second of audio varies depending on the sample rate used when recording the sound. Since the sample rate corresponds to the number of "slices" a sound wave is divided into for each second of time, it's sometimes thought of as a frequency (in the sense that it's a description of something that repeats periodically, not in terms of actual audio frequency), and the samples per second measurement therefore uses the Hertz as its unit.

The most common sample rates are:

8000 Hz

The international G.711 standard for audio used in telephony uses a sample rate of 8000 Hz (8 kHz). This is enough for human speech to be comprehensible.

44100 Hz

The 44.1 kHz sample rate is used for compact disc (CD) audio. CDs provide uncompressed 16-bit stereo sound at 44.1 kHz. Computer audio also frequently uses this frequency by default.

48000 Hz

The audio on DVD is recorded at 48 kHz. This is also often used for computer audio.

96000 Hz

High-resolution audio.

192000 Hz

Ultra-high resolution audio. Not commonly used yet, but this will change over time.

There is a reason why 44.1 kHz is considered the minimum "high fidelity" sampling rate. The Nyquist-Shannon sampling theorem dictates that to reproduce a sound accurately, it must be sampled at twice the rate of the sound's frequency. Since the range of human hearing is from around 20 Hz to 20,000 Hz, reproducing the highest-pitched sounds people can generally hear requires a sample rate of more than 40,000 Hz.

To provide additional room for a low-pass filter in order to avoid distortion caused by aliasing, an additional 2.05 kHz transition band is added to the pre-sampling frequency (resulting in 22,050 Hz). Doubling that per the Nyquist theorem results in a final minimum frequency of (you guessed it) 44.1 kHz.

High-resolution (96 kHz) audio is used in some high-end audio systems, and it and ultra-high resolution (192 kHz) audio are useful for audio mastering, where you need as much quality as possible while manipulating and editing the sound before downsampling to the sample rate you will use for the final product. This is similar to how photographers will use high resolution images for editing and compositing before presenting the customer with a JPEG suitable for use on a website.

### Audio file size and network bandwidth

Once you know the size of a single audio frame and how many frames per second make up your audio data, you can easily calculate how much space the raw sound data itself will occupy (and therefore how much bandwidth it would consume on a network).

For example, consider a stereo audio clip (that is, two audio channels) with a sample size of 16 bits (2 bytes), recorded at 48 kHz:

2
×
2

bytes

sample

×
48000

samples

second

=
192000

bytes

second

=
192
kBps

2 \times 2\frac { bytes }{ sample } \times 48000\frac { samples }{ second } = 192000\frac { bytes }{ second } = 192 kBps

At 192 kBps, lower-end networks are already going to be strained just by a single audio stream playing. If the network is also doing other things, the problem strikes even on higher bandwidth networks. With so much competition for network capacity, especially on slower networks, this amount of data may be too much to viably transmit during any kind of real-time applications.

To solve this problem, the audio must be made smaller using compression.

**Note:** Network bandwidth is obviously not the same thing as audio bandwidth, which is discussed in Sampling audio, above.

Audio compression basics
------------------------

Unlike text and many other kinds of data, audio data tends to be **noisy**, meaning the data rarely consists of a series of exactly repeated bytes or byte sequences. As a result, audio data is difficult to compress using traditional algorithms such as those used by general-purpose tools like `zip`, which usually work by replacing repeating sequences of data with a shorthand representation.

There are several techniques which can be applied when compressing audio. Most codecs use a combination of these, and may use other techniques as well.

The simplest thing you can do is to apply a filter that removes hiss and quiet sounds, converting any quiet sections into silence and smoothing out the signal. This can produce stretches of silence as well as other repeating or nearly repeating signals that can be shortened.

You can apply a filter that narrows the audio bandwidth, removing any audio frequencies that you don't care about. This is especially useful for voice-only audio signals. Doing this removes data, making the resulting signal more likely to be easy to compress.

### Psychoacoustics

If you know what kind of audio you're most likely to handle, you can potentially find special filtering techniques applicable specifically to that kind of sound, that will optimize the encoding.

The most commonly-used compression methods for audio apply the science of **psychoacoustics**. This is the science that studies how humans perceive sound, and what parts of the audio frequencies we hear are most important to how we respond to those sounds, given the context and content of the sound. Factors such as the ability to sense the change in frequency of a sound, the overall range of human hearing vs. the frequencies of the audio signal, audio localization, and so forth all can be considered by a codec.

By using a sound (no pun intended) understanding of psychoacoustics, it's possible to design a compression method that will minimize the compressed size of the audio while maximizing the perceived fidelity of the sound. An algorithm employing psychoacoustics may use any of the techniques mentioned here, and will almost certainly apply others as well.

All of this means there is a fundamental question that has to be asked and answered before choosing a codec: Given the content of the sound, the usage context, and the target audience, is it acceptable to lose some degree of audio fidelity, and if so, how much; or is it necessary that, upon decoding the data, the result be identical to the source audio?

### Lossy vs. lossless compression

If loss of detail and potentially fidelity is unacceptable or undesirable, a **lossless** codec is preferred. On the other hand, if some degree of reduction of audio fidelity is okay, a **lossy** codec can be used. Generally, lossy compression results in significantly smaller output than lossless compression methods; also, many lossy codecs are excellent, with the loss in quality and detail being difficult or even impossible for the average listener to discern.

**Note:** While a high-quality lossy compression algorithm's effect on sound quality may be difficult for the average person to detect, certain people have exceptionally good hearing, or are particularly adept at noticing the kinds of changes introduced to music by lossy compression techniques.

The majority of audio codecs use some form of lossy compression, because of the better compression ratio those algorithms offer. Whereas lossless compression algorithms usually manage no better than a 40-50% of the size of the original, uncompressed sound data, modern lossy compression algorithms can reduce the size of the audio to between 5-20% of the original size, depending on the complexity of the audio. The vastly superior compression ratios possible with lossy compression usually make it a compelling choice, and adequate or excellent audio quality is possible with well-chosen codec configurations.

Researchers are continuing to devise better ways to analyze and compress audio, so new formats come out periodically that offer various improvements, either in compression ratio or audio fidelity (or both).

Use cases for lossless audio include scenarios such as:

* Any situation in which the listener expects precise audio reproduction and may have an ear for sound that's good enough to make out the intricate details of unaltered audio
* Audio loops and samples used in music and sound effects production work
* Situations in which audio clips or samples may be remixed and then compressed; using lossless audio for the mastering process avoids compressing previously compressed data, resulting in additional quality loss

Factors that may recommend the use of lossy compression include:

* Very large source audio
* Constrained storage (either because the storage space is small, or because there's a large amount of sound to store into it)
* A need to constrain the network bandwidth required to broadcast the audio; this is especially important for live streams and teleconferencing
Psychoacoustics 101
-------------------

Diving into the details of psychoacoustics and how audio compression works is far beyond the scope of this article, but it is useful to have a general idea of how audio gets compressed by common algorithms can help understand and make better decisions about audio codec selection.

Lossy compression algorithms generally use psychoacoustics to determine which components of an audio waveform can be lost or subdued in some way that can improve compression ratios while minimizing the audible effect for the target listeners. By manipulating the waveform to make it easier to compress, or by removing components of the sound that aren't really heard, the waveform becomes simpler, resulting in data which has more consistency and is therefore easier to compress. Restricting the audio bandwidth to include only the frequencies most important to how the human ear will interpret the decoded sound can also improve compression factors.

The type of content being encoded can affect the choice of codec. In particular, the waveform for music is almost always more complex than that of an audio sample that contains only human voices. In addition, the human voice uses a small portion of the range of audio frequencies the human ear can detect.

**Note:** Telephone networks, which were originally designed specifically to transmit human voices, can only carry audio (or any other kind of signal) in the frequency band from 300 Hz to 3,000 Hz. This doesn't quite cover the entire range of human speech at the low end, but enough of the waveform is available that the human ear and brain compensate easily. This also means that humans are generally acclimated to hearing speech constrained to so narrow an audio bandwidth.

Human speech uses a relatively narrow frequency band (around 300 Hz to 18,000 Hz, though the exact range varies from person to person due to factors including gender). In addition, the vast majority of human speech sounds tend to lie between 500 Hz and 3,000 Hz or so, making it possible to drop substantial portions of the overall waveform without compromising the listener's ability to understand the words being said. You can even adjust the audio bandwidth to factor in the pitch of the individual speaker's voice.

Because of all these factors, and because speech waveforms are typically less complex than music, high (and more specifically "high enough") fidelity reproduction of speech can be achieved at a relatively low bit rate.

When a compression algorithm designed to compress general audio analyzes an audio waveform, it can discard anything outside the range of human hearing (or possibly even more, depending on how willing the algorithm is willing to risk losing detail at the high and/or low end of the frequency band). That means that the codec can discard audio whose frequency is lower than about 20 Hz or higher than about 20,000 Hz (20 kHz). This narrows the audio bandwidth of the sound, thereby reducing the amount of data required to represent the signal in its compressed form. The audio bandwidth can't be reduced nearly as much as for a speech-only codec, but it is still a helpful start.

Some people can hear outside this range to some extent. More often, people's ability to hear higher frequencies is rather lower than this; in particular, it's worth noting that by middle age, the high end of that frequency range usually falls from 20 kHz down to around 12 kHz to 14 kHz. This suggests that the higher frequencies can often be discarded without overly affecting comprehensibility of the sound, so you can substantially reduce how much of the audio space you need to retain, thereby making your sound simpler and easier to compress.

This is portrayed in the diagram below. The diagram compares the frequency range of human hearing (green) to the frequency range of human speech (red) and the range of frequencies in which the majority of human vocalizations lie (yellow).

![Diagram showing human hearing range compared to human speech range](/en-US/docs/Web/Media/Formats/Audio_concepts/human-hearing-range.svg)

The large differences among these ranges gives us room to lose details in audio data without significantly impacting the ability of the human ear to notice any real change in audio quality. These facts can be taken advantage of when compressing audio.

On top of simplifying the sound through psychoacoustic analysis, codecs use other algorithms and transforms to further simplify and reduce the size of the audio. If you'd like to learn more about the way compression works on audio, take a look at Audio data compression on Wikipedia.

Importantly, codecs do all the hard work for you. It's why so much engineering and scientific study goes into the creation of new algorithms and codecs. All you need to do is consider the options and your use case, then choose the appropriate codec for your needs.

**Note:** For a more detailed guide to choosing audio codecs, see Choosing an audio codec.

Lossless encoder parameters
---------------------------

Lossless encoders have a lot less room to manipulate the audio to improve the compression rate, given the need to be able to reproduce the original audio, which limits the number of options available to configure these encoders. The options tend to revolve around choosing the method by which the encoder performs the encoding and how much time and processor power it's allowed to consume in order to do so.

These parameters vary depending on the codec, but can include:

* Specifying specific algorithms to use during particular phases of the encoding process
* Parameters for those algorithms to use, such as how much predictive depth to use when trying to model the audio
* The number of passes to make while analyzing the audio, or the number of times given algorithms should be run
Lossy encoder parameters
------------------------

Most codecs have input values you can tune to optimize the compression in various ways, either for size or for quality. When using a lossy encoder, the higher the quality, the larger the encoded audio will be. Because of this, most options affect both quality and size in some manner.

You will need to refer to the documentation for the encoding software you use to determine which options are available, which will depend on the codec and the encoding software itself. Some codecs have a number of values you can adjust (some of which may require a deep understanding of both psychoacoustics and of the codec's algorithms), and others offer a simple "quality" parameter you can set, which automatically adjusts various properties of the algorithm.

### Bit rate

There are two mutually-exclusive ways to control the quality of the compressed audio using the bit rate. The first involves targeting an average bit rate for the encoded data, while the second involves specifying a constant quality value to target while allowing the bit rate to vary.

#### Average bit rate

The first method for controlling the quality of the output file is to specify the **Average Bit Rate** (**ABR**) to target when encoding the audio. The encoder will attempt to produce an encoded sound file that, when playing it back, uses, on average, the specified number of bits for each second of audio. This controls quality from the perspective of the encoded audio size; the higher the bit rate, the higher the resulting audio quality will be. The quality of the audio will fluctuate over time as needed in order to meet the targeted bit rate.

Somewhat similar to ABR is **CBR** (**Constant Bit Rate**). Where ABR attempts to keep the bit rate on average at a given level, while allowing some fluctuation, CBR uses an actually fixed bit rate for the duration of the audio. CBR is primarily used in codecs designed for voice-only purposes, where the frequency range and variation tends to be minimal, allowing CBR encoding to work without unworkable fluctuations in audio quality.

#### Variable bit rate

**Variable Bit Rate** (**VBR**) encoding works by accepting as an input into the encoder a **constant quality** setting. This indicates a quality level to maintain for the duration of the audio, allowing the bit rate to fluctuate as needed to achieve that quality level. In portions of the sound where compression is easily achieved with minimum impact to quality, the bit rate may be very low, while in areas where compression is more complex, the bit rate will be higher.

### Audio frequency bandwidth

Some codecs allow you to configure the audio frequency bandwidth directly, either by specifying the range of frequencies to allow, by establishing upper and/or lower frequency limits, or by specifying an audio source type that determines how to configure the algorithm based on the expected frequency use of the incoming signal.

In addition, some codecs support special limited frequency bandwidth channels, such as the LFE channel, which inherently limit the frequency range available. In the case of LFE, the audio frequency bandwidth is limited to a frequency range suitable for use by a subwoofer or similar audio experience enhancement device.

Some codecs offer special profiles which are specifically intended for particular usage scenarios, such as VoIP; these profiles may also include by default restrictions to the audio frequency bandwidth.

### Joint stereo

Stereo sound is typically represented by audio frames containing one sample per channel. This results in audio frames that require 2 times *sampleSize* bits each, where *sampleSize* is the number of bits each audio sample takes. Therefore, for a 16-bit stereo audio recording, each sample uses 2 times 16, or 32, bits of space. This is standard left/right (L/R) stereo or **simple stereo**.

**Joint stereo** is a method of storing stereo audio samples in a more space-efficient manner by taking into account that usually the sound entering each ear is similar. Thus, rather than storing every bit of each channel's sample, a base amplitude and a per-channel amplitude deviation value are stored, wherein the deviation value may use fewer bits than a complete sample.

There are two types of joint stereo: mid-side and intensity. Over the duration of an audio file, the encoder may change which format is being used to represent the stereo signal over the course of the audio file.

#### Mid-side stereo coding

**Mid-side stereo coding** (**MS**) works by recording frames that contain a fundamental **mid channel**, which is the average amplitude of the original left and right audio channels. This is essentially what you would calculate as the amplitude when converting a stereo signal into mono. Then you store the **side channel** value; this value is a number which can be added to the **mid channel** value to determine left channel's original amplitude, and subtracted from the mid channel value to compute the right channel's original value.

In other words, given a left channel, L, and a right channel, R, you perform the following calculations when encoding a sample:

mid
=

L
+
R

2

mid = \frac { L + R }{ 2 }

side
=

L
-
R

2

side = \frac { L - R }{ 2 }

Then you store the values of `mid` and `side`. While `mid` is still the same size as your sample size (such as 16 bits), the value of `side` can probably be stored in a smaller number of bits, since the amplitude of the two channels is probably relatively similar. The encoder can then take this smaller number of total bits per frame and perform additional computations to further reduce the size.

While decoding the audio, the absolute left and right channel values are calculated like this:

L
=
mid
+
side

L\quad =\quad mid\quad +\quad side

R
=
mid
-
side

L\quad =\quad mid\quad -\quad side

On its own, mid-side stereo coding is lossless, and is commonly used by both lossless and lossy audio codecs. Any loss of detail comes from other steps of the encoding process.

#### Intensity stereo coding

**Intensity stereo coding** reduces the encoded audio bit rate by taking advantage of the way humans determine the location of sounds in space; this is called sound localization. We hear in stereo because our ears detect a sound at different times depending on where the sound is coming from.

This is because our ears are separated by several inches, thanks to being on opposite sides of our heads. A sound coming from our right will arrive at our right ear before it arrives at our left ear. Our brains determine where the sound is in the space around us by using that time difference to figure out the angle from which the sound is coming. However, as the frequency of the audio signal drops, the wavelength goes up. Eventually, the wavelength approaches then exceeds the distance between the ears, and it becomes difficult or impossible to unambiguously localize the sound.

Armed with this information, we can approximately represent a stereo audio signal by merging the frequencies that aren't used to determine directionality into a single channel, then include information that indicates the directionality of the sound. This requires fewer bits to represent, but is inherently somewhat lossy.

See also
--------

* Guide to audio codecs used on the web