JA EN
体系音声圧縮
·★ 会員·論文·14分で読めます

Opusはなぜ最強か — 現代音声コーデックの設計

話し声用と音楽用に分かれていた音声コーデックを、SILKとCELTという2つのエンジンを1本のビットストリームに束ねて統合したのがOpusです。線形予測とMDCTの役割分担、帯域エネルギーを守るgain-shape量子化、遅延の内訳、そしてWebRTCの必須コーデックになった技術的・制度的な理由を前提知識ゼロから解説します。

対象textタスクcompression

Definition of the Opus Audio Codec

一次資料 — この記事の根拠

この解説の公開 2026-08-25

Definition of the Opus Audio CodecRFC 6716論文ページ
WebRTC Audio Codec and Processing RequirementsRFC 7874論文ページ

一台で全部やる楽器は、長いあいだ無かった

2010年ごろまで、音を圧縮する道具は綺麗に二派に分かれていました。

片方は電話の系譜です。人の声だけを相手にして、極端に低いビットレートと短い遅延で動く。G.729、AMR、Speex。会話は成立しますが、これで音楽を流すと水中から聞いているような音になります。

もう片方は音楽の系譜です。MP3、AAC、Vorbis。フルバンドの音楽を綺麗に鳴らせますが、遅延が大きく、話し声を数十kbpsまで絞ると急に破綻します。

だからビデオ会議のアプリは、中で2つのコーデックを抱え、「いま音楽が鳴っているか」を判定して切り替える、といった継ぎ接ぎをしていました。切り替わる瞬間には途切れが出ます。

Opus(RFC 6716、2012年)は、この分断そのものを設計で消しにいったコーデックです。6 kb/s の低速な音声から 510 kb/s のステレオ音楽まで、8 kHz から 48 kHz のサンプリングまで、2.5 ms から 60 ms のフレーム長まで、1つのコーデック、1本のビットストリームで連続的に覆います。しかも切り替えはパケット単位で、外部の合図なしに行えます。

いま WebRTC でブラウザ同士が話すとき、Discord でボイスチャットをつなぐとき、YouTube が WebM で音を配るとき、鳴っているのはたいていこれです。この記事では「なぜ1本化できたのか」を、2つのエンジンの中身まで降りて解きます。

前提として、変換して丸めて詰める、という骨格は音声圧縮を1から、耳の穴を測る心理音響モデルはMP3と心理音響で扱っています。ここではその先、遅延とネットワークという別軸が設計を支配する領域に入ります。

比喩: 「口の模型」と「絵の具の配合表」

2つの系譜は、そもそも音の捉え方が違います。

電話の系譜は、口の模型を作ります。 人の声は、声帯がブーッと鳴らした音を、喉から口までの管が共鳴で色付けして出てきたものです。だったら音そのものを送らず、「今フレームの管の形」と「震え方」だけを送って、受け側で作り直せばいい。声のできかたを知っているぶん、極端に安く済みます。ただしこのモデルはピアノやシンバルを想定していないので、音楽を通すと形が合いません。

音楽の系譜は、絵の具の配合表を作ります。 音を周波数の成分に分解し、「どの高さがどれだけ含まれるか」の表にする。表の数値を、聴こえない範囲で雑に丸める。何の音でも扱えますが、表を作るには一定の長さをまとめて見る必要があり、そのぶん遅延が要ります。

Opus の答えは「どちらかを選ぶ」ではありませんでした。声の模型は SILK(Skypeが開発した音声コーデック由来)、成分表は CELT(Constrained Energy Lapped Transform)として両方積み、周波数で分担させる。 これが SILK-only / CELT-only / Hybrid の3モードです。

FIG 1変換して係数を丸める、という成分表側の骨格。Q値を下げると係数が消え、絵が痩せていく。CELTがこの上に足した発明は、後で見る「帯域ごとの大きさだけは絶対に痩せさせない」という制約です

直感: 2つのエンジンを1本のパケットに束ねる

Hybrid モードでは、8 kHz を境に低域を SILK、高域を CELT が担当します。人の声の情報の大半は低域にあるので、そこは声の模型で安く正確に。倍音や子音のシャリ感が乗る高域は、成分表で広く浅く。

3つのモードの選択は、エンコーダがビットレートと信号の性質から自動で決めます。極端に低いビットレートで声を運べと言われれば SILK-only、余裕があって音楽なら CELT-only、その中間が Hybrid。使う側が指定するのは「何kbpsで、どういう用途か」だけで、どのエンジンが動いているかは隠されています。

決定的なのは、この2つが同じレンジコーダ(算術符号器)の状態を共有し、1本のビット列に交互に書き込むことです。2つのファイルを並べて連結するのではないので、層の境目でバイト境界に揃えるための無駄が出ません(レンジコーダの原理はエントロピー符号化にあります)。

そしてパケットの先頭1バイト(TOC バイト)が、そのパケットのモード・帯域幅・フレーム長・ステレオかどうかを自分で名乗ります。だから送信側は、ネットワークが細ったフレームで音声モード・狭帯域・低ビットレートに落とし、回復したら音楽モード・フルバンドに戻す、ということをSDPの再交渉なしに次のパケットからやれる。「切り替えで途切れる」問題が、設計レベルで消えています。

声の模型の中身は線形予測(LPC)です。直前のサンプルたちの重み付き和で、次のサンプルを予想します。

この先にあるもの

§

ここから先は会員限定です

解説記事371本・教科書26章・学生モード48単元・論文精読6本が、月額¥490ですべて読み放題になります。新しい解説は毎日3本ずつ増えます。いつでも解約でき、解約後も期間の終わりまで読めます。

会員の方はログインすると続きが表示されます

参考文献

  1. Definition of the Opus Audio Codec. RFC 6716論文ページ
  2. WebRTC Audio Codec and Processing Requirements. RFC 7874論文ページ

本記事は上記論文の本文にもとづいて執筆しています。数値・主張は原典を優先してください。

コメント

コメントにはログインが必要です