Opus Audio
Opus is a lossy audio codec designed to handle both speech and music with flexible bitrate and low delay.
One Opus stream can carry an intelligible low-rate voice, music, or a mixture. Its design joins predictive speech coding and transform coding, allowing the encoder to use the tools appropriate to the material and operating mode.
The format is defined in RFC 6716. Its decode rules, coded-frame durations, and supported mode transitions make the relationship between data, delay, and output explicit.
SILK, CELT, and hybrid coding modes
| Mode | Main representation |
|---|---|
| SILK-based predictive mode | Speech-oriented linear prediction and excitation |
| CELT-based transform mode | Frequency-domain coding suited to music and other audio |
| Hybrid mode | Predictive lower-band speech plus transform-coded higher-band content |
Prediction describes recurring speech structure efficiently. Transform coding handles general audio and higher frequencies without forcing all content into a voice model. In the hybrid arrangement, the two parts cover their intended bands rather than redundantly encoding the same whole signal twice.
Mode, audio bandwidth, and bitrate are related encoder choices. The output sample-rate number is another property: a decoder can put a narrower-band reconstruction on a 48 kHz time grid.
Count a 20 ms frame
At a 48 kHz output rate, 20 ms represents 960 sample frames per channel. Uncompressed 16-bit stereo needs 960 × 2 × 2 = 3,840 bytes for that span.
At a nominal 96 kbit/s encoded data budget, 20 ms corresponds to 96,000 × 0.020 / 8 = 240 bytes, before external transport overhead. This calculation illustrates the scale of compression, not a fixed packet size for every Opus mode or VBR frame.
Shorter coded durations can reduce one contribution to latency, but increase framing overhead and change coding tradeoffs. Codec look-ahead, packet accumulation, network buffering, and output buffering are additional delays. A low-delay codec is only one component of a low-delay route.
For suitable communication modes, optional packet-loss tools can provide concealment or forward-error-recovery information. They address missing data during transport; they do not make the stored lossy representation lossless.
Why an Ogg Opus file uses a 48 kHz clock
RFC 7845 defines Ogg Opus timing in 48,000 sample positions per second regardless of the original capture rate or a decoder's chosen output rate. The header's input-rate field describes source information; it does not redefine that clock.
The mapping also describes pre-skip and final trimming so codec delay and padding do not become unwanted audible boundaries.
For an illustrative one-second file:
| Quantity | Sample frames on the 48 kHz clock |
|---|---|
| 51 decoded packets, each representing 20 ms | 48,960 |
| Initial pre-skip | 240 |
| Final discarded padding | 720 |
| Audible duration | 48,000 |
The final retained granule position is 48,240; subtracting the pre-skip gives 48,000, or one second. These selected values demonstrate the accounting, not universal Opus encoder delay settings.
Keep channel mapping with the stream
A multichannel Opus presentation can use several coded streams and a mapping describing how their outputs become presentation channels. A packet reader must preserve that setup as well as the payloads and timing.
For an Opus recording in Emby, inspect its container mapping and the delivered presentation when a duration or channel problem occurs. A bare 48 kHz label cannot diagnose a lost pre-skip instruction or an incorrectly applied channel map. Following those concrete structures explains the symptom.