PCM Drop logoPCM Drop
All articles

Opus 1.6 Explained: Bandwidth Extension, 96 kHz Opus HD and a 24-bit API

·10 min read

Opus is the open audio codec that the IETF standardised in 2012 as RFC 6716. Its authors designed it for interactive audio such as voice over IP, videoconferencing, in-game chat and even live, distributed music performances, and it scales from 6 kbit/s narrowband speech up to 510 kbit/s stereo music. Opus 1.6, released on 15 December 2025, builds on the machine-learning features that Opus 1.5 introduced in March 2024. It adds a neural bandwidth extension, a smaller and more intelligible packet-loss model, an experimental 96 kHz mode called Opus HD, and a new 24-bit integer API.

This article explains each change in terms of the PCM audio that goes into and comes out of the codec. Every technical claim comes from the Opus project's own release notes, the IETF specification or the other primary sources listed at the end. Where a figure is our own calculation or interpretation, we say so.

The Basics: Bandwidths and Sample Rates in Opus

Opus works at five audio bandwidths. RFC 6716 defines them like this:

NameAudio bandwidthEffective sample rate
Narrowband (NB)4 kHz8 kHz
Medium-band (MB)6 kHz12 kHz
Wideband (WB)8 kHz16 kHz
Super-wideband (SWB)12 kHz24 kHz
Fullband (FB)20 kHz48 kHz

Opus never codes audio above 20 kHz, which the RFC describes as the generally accepted upper limit of human hearing, even though the sampling theorem would allow a bandwidth of up to half the sampling rate. A decoder can run at any of these rates. The RFC notes, for example, that a decoder operating at 8 kHz can decode a fullband frame, and one operating at 48 kHz can decode a narrowband frame. Internally, the codec's MDCT layer always works at 48 kHz, and the decoder resamples its output when you ask for a different rate.

This matters for the rest of the article, because the three headline features in 1.6 are all about going beyond a plain stream at one bandwidth: extending wideband speech towards fullband, surviving lost packets, and going beyond 48 kHz. If sample rate and bit depth are new to you, start with our sample rate and bit depth guide.

What Opus 1.6 Contains

The release page lists these major changes since Opus 1.5:

  • A new wideband-to-fullband bandwidth extension (BWE) module
  • Support for 96 kHz audio with Opus HD
  • Significant improvement to Deep Redundancy (DRED)
  • A new 24-bit encoder/decoder API
  • Fixed-point improvements

The release demo page adds that 1.6 remains fully compatible with RFC 6716, so ordinary Opus streams keep working as before. A maintenance release, libopus 1.6.1, followed on 14 January 2026. Its release page says only that it fixes several minor issues discovered since 1.6.

Bandwidth Extension: Generating 8–20 kHz From Wideband Speech

Wideband speech is sampled at 16 kHz, so it carries content up to 8 kHz. The new BWE module is a neural network, marked experimental in 1.6, that was trained to generate 8–20 kHz speech content from 0–8 kHz wideband speech without any side information. Because it needs nothing extra in the bitstream, the Opus team notes that it can enhance speech coded by any earlier Opus version, and that the model can be improved later without breaking compatibility. The team says this is possible because the phonetic information is already contained in the lower band. It deliberately does not attempt to extend narrowband telephone audio to wideband, which the team describes as hard to achieve and tending to be unreliable.

For anyone who works with PCM, the key point is that BWE adds samples that were never transmitted. The 48 kHz audio that comes out of the decoder contains synthesised high-frequency content, so it is a plausible reconstruction and not recovered original audio.

The release notes set firm limits on when it runs:

  • It is only used for speech coded in the SILK wideband mode, and only when the decoder is configured for 48 kHz output.
  • The decoder complexity setting, introduced in Opus 1.5, must be 4 or higher.
  • It never activates for super-wideband or fullband audio, and it is not meant to replace highband content that hybrid mode already encodes.
  • It must be enabled twice: build the library with the --enable-osce configure option, then enable it at run time with -enable_osce_bwe.

The Opus team reports these results from its own subjective listening evaluation (a MOS test):

  • For uncoded speech, BWE closes about half of the quality gap between wideband and fullband.
  • Combined with NoLACE (a speech enhancement that the demo page names but does not describe), it reaches quality similar to Opus 1.4 fullband at double the bitrate (18 kb/s) while coding at 9 kb/s.
  • It also closes the gap with the EVS codec.
  • At 9 kb/s and above, the team says Opus is now able to exceed the quality of a purely neural codec such as EnCodec.

These are the developers' own published results, not an independent test.

DRED: Surviving Lost Packets

On a live call, packets get lost, and the decoder then has to guess what was missing or go quiet. The paper that introduced DRED (Deep REDundancy), by Jean-Marc Valin and co-authors, says that conventional redundancy techniques are limited in how long a loss they can cover and are often unsuitable for bursts of lost packets. DRED uses a neural network to encode large amounts of redundancy at a very low bitrate. According to the paper, it can transmit up to 50x redundancy using less than 32 kb/s, and it outperforms the redundancy scheme Opus already had. DRED first appeared as an experimental extension in Opus 1.5, together with an improved packet loss concealment (PLC) based on deep learning.

The 1.6 release demo page lists what changed:

  • Better intelligibility. The 1.5 model tended to smooth out speech too much at very low bitrates, which could sound slurred. The 1.6 model was trained with a loss function that is more sensitive to large errors (a fourth-power error term). The team says this does not make speech sound better, but it does make it more intelligible.
  • More robustness. The model was trained on a mix of clean and noisy or reverberant speech, which improves quality in difficult conditions without hurting clean speech.
  • A smaller model. The DRED encoder and decoder models are about three times smaller than in 1.5: 600 kB, down from 1800 kB.

There is one compatibility catch. DRED is signalled in the bitstream, and the 1.6 model is incompatible with the one in 1.5. Mixing a 1.5 encoder with a 1.6 decoder, or the reverse, produces no unwanted sounds, but the DRED information is simply not available to the incompatible decoder. The team says it hopes, but does not promise, that the 1.6 model will not need to change in the final DRED standard, which the demo page says is covered by an IETF draft.

Opus HD: 96 kHz and Up to 2 Mb/s

Opus HD is an experimental, in-development mode that codes 96 kHz audio with bandwidth beyond the usual 20 kHz and bitrates up to 2 Mb/s. For scale, the RFC's maximum is 510 kb/s, so the new ceiling is roughly four times higher (our arithmetic). The Opus team writes that 48 kHz audio is "good enough for everyone", and it points to other uses for the higher rate, such as sensors and ultrasonics.

Opus HD is built as an extension layer on top of ordinary Opus. A regular decoder plays an Opus HD stream without any trouble, just without the extra bandwidth and bitrate. The layer also raises the resolution inside the audible 0–20 kHz band. The standard Opus quantisers can reach about 8 bits per coefficient as the bitrate approaches its 510 kb/s maximum, while Opus HD quantisers can reach 20 bits.

The release notes make a point that is worth remembering whenever bit depth comes up: this quantiser resolution is not the same thing as the PCM sample bit depth. They say that even with bit depths below 8 bits, Opus can still code the full dynamic range of 24-bit audio, and more.

To use it, build with --enable-qext, then either pass -qext to opus_demo or call OPUS_SET_QEXT(1) on the encoder. A decoder built with Opus HD support uses any Opus HD layer it finds, unless you call OPUS_SET_IGNORE_EXTENSIONS(1). The release demo page links to an IETF draft for the extension.

The 24-bit Integer API

Until now, Opus offered 16-bit integer and 32-bit float calls. Both remain available. Opus 1.6 adds 24-bit integer calls with a 24 suffix, aimed at high-resolution pipelines that prefer to avoid floating-point arithmetic, such as platforms where floating-point operations are expensive.

C has no native 24-bit integer type, so the API uses opus_int32 with the audio stored in the lower 24 bits. That gives a nominal range of −2²³ to 2²³−1, or −8,388,608 to 8,388,607 (our arithmetic). Like the float API, it accepts values slightly beyond that range without hard clipping, which preserves peaks that the 16-bit API would lose. The two main calls look like this (signatures simplified from opus.h in the 1.6 source):

opus_int32 opus_encode24(OpusEncoder *st, const opus_int32 *pcm, int frame_size,
                         unsigned char *data, opus_int32 max_data_bytes);

int opus_decode24(OpusDecoder *st, const unsigned char *data, opus_int32 len,
                  opus_int32 *pcm, int frame_size, int decode_fec);

The same 24 variants exist for the multistream calls (opus_multistream_encode24() and opus_multistream_decode24()), the projection (Ambisonics) calls, the custom-mode calls and DRED decoding (opus_decoder_dred_decode24()).

Here is a practical PCM detail. Packed 24-bit PCM, such as the s24le format used by FFmpeg, stores each sample in three bytes, but the API wants a 32-bit integer per sample. Packed samples therefore have to be unpacked first. This small helper does it for little-endian data (our own code, compiled and tested on the extreme values):

static int32_t unpack_s24le(const unsigned char *p) {
    int32_t v = (int32_t)((uint32_t)p[0] | ((uint32_t)p[1] << 8) | ((uint32_t)p[2] << 16));
    if (v & 0x800000) v -= 0x1000000;   /* sign-extend from 24 bits */
    return v;
}

Feeding it the bytes FF FF 7F gives 8,388,607, 00 00 80 gives −8,388,608 and FF FF FF gives −1.

What to Expect in Practice

Most of what is new in 1.6 is opt-in. Bandwidth extension needs a build option and a run-time switch. Opus HD needs a build option and an explicit encoder call. The release notes describe BWE and Opus HD as experimental, and the team says only that it hopes the DRED model will stay stable. Whether a video-call app, browser or game engine turns any of this on is a decision for that project's developers, so do not expect your existing calls to change overnight. For everyone else, ordinary Opus files and streams are unaffected, because 1.6 stays compatible with RFC 6716.

If you decode Opus to raw PCM, the decoder lets you choose the output sample rate from the RFC's table (8, 12, 16, 24 or 48 kHz), and 48 kHz is the rate the codec's internal MDCT layer uses. Enter whatever you chose into the PCM player to check the result by ear, and see our raw audio troubleshooting guide if it sounds too fast or too slow.

Summary

Opus 1.6 is a compatible update that adds experimental, opt-in features: a neural bandwidth extension that synthesises 8–20 kHz speech content, a smaller and more intelligible DRED model for packet loss, a 96 kHz Opus HD layer, and a 24-bit integer API that stores each sample in the lower 24 bits of a 32-bit integer. Each of these comes with caveats that the Opus team spells out in its own release notes, and we have repeated them here instead of rounding them up into promises.

Sources and verification

The facts in this article were checked against the primary sources below on . Figures described as our own calculation are derived from those sources. If you spot a mistake, please tell us through the contact page.