Opusはなぜ最強か — 現代音声コーデックの設計
話し声用と音楽用に分かれていた音声コーデックを、SILKとCELTという2つのエンジンを1本のビットストリームに束ねて統合したのがOpusです。線形予測とMDCTの役割分担、帯域エネルギーを守るgain-shape量子化、遅延の内訳、そしてWebRTCの必須コーデックになった技術的・制度的な理由を前提知識ゼロから解説します。
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モードです。
直感: 2つのエンジンを1本のパケットに束ねる
Hybrid モードでは、8 kHz を境に低域を SILK、高域を CELT が担当します。人の声の情報の大半は低域にあるので、そこは声の模型で安く正確に。倍音や子音のシャリ感が乗る高域は、成分表で広く浅く。
3つのモードの選択は、エンコーダがビットレートと信号の性質から自動で決めます。極端に低いビットレートで声を運べと言われれば SILK-only、余裕があって音楽なら CELT-only、その中間が Hybrid。使う側が指定するのは「何kbpsで、どういう用途か」だけで、どのエンジンが動いているかは隠されています。
決定的なのは、この2つが同じレンジコーダ(算術符号器)の状態を共有し、1本のビット列に交互に書き込むことです。2つのファイルを並べて連結するのではないので、層の境目でバイト境界に揃えるための無駄が出ません(レンジコーダの原理はエントロピー符号化にあります)。
そしてパケットの先頭1バイト(TOC バイト)が、そのパケットのモード・帯域幅・フレーム長・ステレオかどうかを自分で名乗ります。だから送信側は、ネットワークが細ったフレームで音声モード・狭帯域・低ビットレートに落とし、回復したら音楽モード・フルバンドに戻す、ということをSDPの再交渉なしに次のパケットからやれる。「切り替えで途切れる」問題が、設計レベルで消えています。
コメント
コメントにはログインが必要です