MicrosoftのINTERSPEECH 2022 Audio Deep PLC Challengeで最も優れたニューラルパケットロス隠蔽システムは、1から5の尺度でPLCMOS 4.28を記録した。単に無音を挿入した場合は2.90、クリーンな原音は4.51だった(Microsoft、INTERSPEECH 2022 Audio Deep PLC Challenge論文)。2年後、同じチャレンジがフルバンド音声と最大3秒のロスバーストに移行すると、共同優勝チームは総合品質を2.37から3.49にしか引き上げられず、クリーン音声の4.01を大きく下回ったままだった(Microsoft、ICASSP 2024 Audio Deep PLC Challenge論文)。この問題はまれではない。Googleは、Duo通話の99%がパケットロス、ジッター、遅延への対処を迫られ、10通話に1通話は音声の8%超を失ったと報告した(Google Research、WaveNetEQブログ 2020)。隠蔽は、当社のVoIPとUCaaSの統計で扱うビジネストレンドの下で静かに働く層であり、当社の携帯電話ネットワークの音声品質(MOS)統計が示す事業者側の状況を補完する。当社は、Microsoft Researchのチャレンジ論文、IETFとITU-T、W3C、Google Research、Xiph.OrgのOpus開発者、Meta Engineering、Microsoft LearnとTwilioのドキュメント、そして方法論に挙げた査読付きPLC研究からデータを集約した。
主なポイント
- Google Duo通話の99%がパケットロス、ジッター、遅延への対処を迫られた。10%は総音声時間の8%超を失った(Google Research、WaveNetEQブログ 2020)。
- Microsoft Teamsは、平均パケットロスが0.1、つまり10%を超えると音声ストリームを不良とする(Microsoft Learn、CQD Stream Classification 2026)。
- 付属書Iの隠蔽を備えたG.711のパケットロス耐性係数は25.1で、隠蔽なしでは4.3である(ITU-T G.113、09/2024)。
- ニューラルPLCの優勝システム:PLCMOS 4.28。ゼロ埋めは2.90、クリーン音声は4.51(Microsoft、INTERSPEECH 2022 Deep PLC Challenge論文)。
- Opusチームのハイブリッド型PLCは、2022年のチャレンジで単語正解率(0.882)が1位、総合では2位だった(Valinほか、Real-Time PLC with Mixed Generative and Predictive Model 2022)。
- 最大3秒のバーストでは、参加資格を満たした8システムのうち2つが、P.804総合品質で未処理の損失音声を下回った(Microsoft、ICASSP 2024 Deep PLC Challenge論文)。
- PLCMOSは人間の評価とのモデル単位のピアソン相関が約0.97に達する。参照に整列したデータでは、PESQは0.52にとどまる(Dienerほか、PLCMOS論文 2023)。
- OpusのLBRR帯域内FECは通常ビットレートの約2/3で1フレームをカバーし、DREDは約1/50で最大1秒をカバーする(IETF draft-ietf-mlcodec-opus-dred-07、2026年8月)。
- MetaによるMLowの自社比較によれば、Opusが10%のパケットロスで帯域内FECを符号化するには少なくとも19 kbpsが必要である(Meta Engineering、MLow 2024)。
- Opus 1.6はDREDモデルを約3分の1に縮小し、1,800 kBから600 kBにした(Xiph.Org、Opus 1.6デモ、2025年12月)。
1. どれだけの音声が失われるか、そして各プラットフォームはどこに線を引くか
この文脈でのパケットとは、ネットワーク上で送られる音声の小さな1片(多くの場合20 ms)である。遅れすぎて届くか、まったく届かない場合、受信側には2つの選択肢がある。無音を再生するか、欠落した音声のように聞こえるものを合成して穴を隠蔽するかである。Google自身のデータによれば、Duo通話の99%がパケットロス、ジッター、遅延への対処を迫られた(Google Research、Improving Audio Quality in Duo with WaveNetEQ 2020)。したがって隠蔽は例外的なケースではなく、ほぼすべての通話で動作している。
ロスが背景ノイズから問題に変わる地点について、プラットフォームの見解は一致していない。Microsoft Teamsは平均ロス10%で不良の線を引き、Twilioは5%で引いている。Microsoftは、不良というラベルがユーザーが実際に品質の問題を感じたことを意味するわけではないと明示的に警告している。メディアスタックがロスを補正するためである(Microsoft Learn, Stream Classification in CQD 2026)。この但し書きこそが、より優れた隠蔽を求める議論のすべてである。PLCが伸びるほど、プラットフォームは警報のしきい値を高く設定できる。
| 指標 | 値 | 出典 |
|---|---|---|
| パケットロス、ジッター、遅延に対処しなければならないGoogle Duo通話の割合 | 99% | Google Research、WaveNetEQブログ 2020 |
| 総音声時間の3%超を失うDuo通話の割合 | 20% | Google Research、WaveNetEQブログ 2020 |
| 総音声時間の8%超を失うDuo通話の割合 | 10% | Google Research、WaveNetEQブログ 2020 |
| Teamsが音声ストリームを不良に分類する平均パケットロス率のしきい値 | 0.1(10%)超。500パケットを超えるストリームにのみ適用 | Microsoft Learn、CQD Stream Classification 2026 |
| Twilioのhigh_packet_loss通話タグを発動させるパケットロス水準 | 5%超 | Twilio Voice Insights、Details: Call Tags |
| TwilioがブラウザまたはモバイルSDKの通話にlow_mosタグを付ける推定MOSの水準 | 3.5未満 | Twilio Voice Insights、Details: Call Tags |
| Opus DREDの評価に使われたDeep PLC Challengeテストセットの平均ロス率 | 18.4%、最大1秒のバースト | Valinほか、DRED論文(arXiv 2212.04453 v3、2024年) |
入手可能な最新データ:Google Research、2020年。大手プラットフォームで、より新しい通話単位のロス分布を公表したところはない。Teamsは関連する指標「Ratio Concealed Samples Avg」をストリームごとに報告しており、0.1は音声フレームの10%に隠蔽されたサンプルが含まれていたことを意味する(Microsoft Learn, CQD dimensions and measures 2026)が、Microsoftは全体規模の値を公表していない。ブラウザ側の対応指標であるconcealedSamplesとconcealmentEventsは、W3C WebRTC統計API(勧告候補ドラフト、2025年9月25日)で定義されている。
2. ITU-TのE-modelにおける従来型コーデックの隠蔽
ニューラルネットワーク以前、隠蔽とは直前の正常なピッチ周期を繰り返すか外挿することを意味した。ITU-Tの計画モデル(E-model)は、コーデックがロスにどれだけ耐えられるかを、パケットロス耐性係数Bplで評価する。これは単純な数値で、高いほどパケットが失われても品質の低下が緩やかであることを意味する。付属書Iの隠蔽アルゴリズムを備えたG.711のBplは25.1で、隠蔽なしのG.711の4.3の約6倍に近い(ITU-T G.113 09/2024、表I.4)。
この差が実際に何を意味するかは、数値で見るとより明確になる。ITU-T G.107(06/2015)の式7-29、Ie-eff = Ie + (95 - Ie) x Ppl / (Ppl/BurstR + Bpl)を用いると、5%のランダムロス(BurstR = 1)におけるG.711(Ie = 0)は、隠蔽なしで95 x 5 / (5 + 4.3) = 51.1の劣化ポイント、隠蔽ありで95 x 5 / (5 + 25.1) = 15.8となる。これを既定の評価値R = 93.2から引くと、R 42.1とR 77.4になり、G.107付属書Bの式で推定MOSに換算すると約2.2と3.9になる(当社の計算。E-modelの他のすべての入力は既定値のまま)。隠蔽だけで、ロス5%の通話は劣悪から許容範囲へと変わる。
| 指標 | 値 | 出典 |
|---|---|---|
| 隠蔽なしのG.711(64 kbit/s、10 msパケット):ランダムロス時のパケットロス耐性係数Bpl | 4.3 | ITU-T G.113(09/2024)、表I.4 |
| G.711付属書Iの隠蔽アルゴリズムを備えたG.711:ランダムロス時のBpl | 25.1 | ITU-T G.113(09/2024)、表I.4 |
| 音声区間検出を備えたG.729付属書A(8 kbit/s、20 msパケット、内蔵の隠蔽):IeとBpl | Ie 11、Bpl 19.0 | ITU-T G.113(09/2024)、表I.4 |
| 20 msパケットのG.711、ロス2%で8パケットが1回のバーストで失われる場合(バースト比7.84):実効劣化Ie-eff | 10 | ITU-T G.113(09/2024)、表I.6 |
| G.722付属書IIIの高品質隠蔽を備えた64 kbit/sのG.722:広帯域Bpl(両耳で聴取) | 7.1 | ITU-T G.113(09/2024)、付属書IV |
| 24.4 kbit/sの超広帯域モードのEVS:フルバンドBpl | 11.4 | ITU-T G.113(09/2024)、付属書V |
| すべての入力が既定値のときのE-model評価値R | 93.2 | ITU-T G.107(06/2015) |
背景:Bpl値は、同じ尺度(狭帯域、広帯域、フルバンド)の中でのみ比較できる。G.113にはOpusの値がまったく記載されていないため、OpusベースのWebRTC音声は他の手段で評価する必要がある(第5節を参照)。
3. ニューラル隠蔽と無音の比較:2022年のDeep PLCチャレンジ
INTERSPEECH 2022のチャレンジは、Microsoft Teams通話から記録したトレースによる実際のロスパターンと、アルゴリズム遅延の合計が20 ms以下という厳格なリアルタイム規則のもとで、ニューラルPLCを評価した。その最大の成果は、優勝システムと何もしない場合との差の大きさである。優勝システムの比較尺度(CMOS。0はクリーンな原音と区別できないことを意味する)でのスコアは-0.55で、ゼロ埋めの-1.23を上回った(Microsoft、INTERSPEECH 2022 Audio Deep PLC Challenge論文)。
明瞭度の面では、より控えめな結果になる。単語正解率(音声認識器の単語誤り率を1から引いた値)は、無音の0.86から優勝システムの0.88へとわずかに上がっただけで、クリーン音声は0.97だった。聞き手は隠蔽を大きな改善として聞き取るが、音声認識器は優勝システムでも単語の12%を取りこぼし、クリーン音声での3%と対照的である。これは当社の音声認識の単語誤り率の統計と並べて覚えておく価値のあるパターンである。
| 指標 | 値 | 出典 |
|---|---|---|
| クリーンな基準音声:PLCMOS(1から5)と単語正解率 | 4.51と0.97 | Microsoft、INTERSPEECH 2022 Deep PLC Challenge論文 |
| ゼロ埋めのベースライン(失われたパケットの代わりに無音):PLCMOS、CMOS、単語正解率 | 2.90、-1.23、0.86 | Microsoft、INTERSPEECH 2022 Deep PLC Challenge論文 |
| 優勝システム(チーム #12、時間領域U-Net、約2.36Mパラメータ):PLCMOS、CMOS、単語正解率 | 4.28、-0.55、0.88 | Microsoft、INTERSPEECH 2022 Deep PLC Challenge論文 |
| 参加資格を満たした最下位のシステム(チーム #6)とゼロ埋めベースラインの比較:CMOS | -1.31と-1.23 | Microsoft、INTERSPEECH 2022 Deep PLC Challenge論文 |
| Opusチームのハイブリッド型生成・予測PLC:単語正解率とその指標での順位 | 0.882で1位。CMOSと総合では2位 | Valinほか、Real-Time PLC with Mixed Generative and Predictive Model 2022 |
| 同じシステム:ノートPCのCPU(Intel i7-10810U)での音声10 msあたりの計算量 | 1.3から1.4 ms、1コアの約13%から14% | Valinほか 2022 |
外れ値に関する注記:順位付けされたシステムのうち1つは、CMOSで無音のベースラインを下回った。調整が不十分な生成器は、空白よりも悪く聞こえることがあるという注意喚起である。盲検セットは短いバーストに偏っており、966クリップのうち504クリップの最大バーストは120 ms以下だった。ハイブリッドシステムの数値はValinほかに基づくもので、その隠蔽方式は後にOpus 1.5に搭載された(第7節を参照)。
4. 長いバースト:隠蔽が今も破綻する領域(ICASSP 2024)
2024年版は意図的に課題を難しくした。48 kHzのフルバンド音声を、多次元のITU-T P.804方式で評価し(Microsoft Research, ICASSP 2024 Audio Deep PLC Challenge)、ロスバーストは最大3秒である。最良のシステムでも、損失音声とクリーン音声の距離の約3分の2しか埋められなかった。総合品質は2.37から3.49に上がったが、クリーン音声は4.01である((3.49 - 2.37) / (4.01 - 2.37) = 68%)(Microsoft、ICASSP 2024 Audio Deep PLC Challenge論文)。
最も示唆に富む列は不連続性で、P.804における聞き取れる途切れや不具合のスコアである(高いほど滑らか)。最良のシステムで2.47から3.90に上がり、他のどの次元よりも大きな伸びだった。隠蔽は聞き手が最初に気づく穴を修復するが、合成された音声は自然さを犠牲にする。単語正解率にもこのトレードオフが表れている。共同優勝チームの1つは単語の0.81を認識したが、手を加えていない損失音声の0.83をわずかに下回った。作り出された音声は、無音よりも音声認識器を惑わせうることを示唆している。
| 指標 | 値 | 出典 |
|---|---|---|
| P.804総合品質(1から5):クリーン音声、未処理の損失音声、共同優勝チーム(1024KとNWPU & ByteAudio)の比較 | 4.01、2.37、3.49と3.44 | Microsoft、ICASSP 2024 Deep PLC Challenge論文 |
| P.804不連続性スコア:クリーン、損失、最良システム(1024K)の比較 | 4.55、2.47、3.90 | Microsoft、ICASSP 2024 Deep PLC Challenge論文 |
| 単語正解率:クリーン、損失、1024K、NWPU & ByteAudioの比較 | 0.98、0.83、0.81、0.84 | Microsoft、ICASSP 2024 Deep PLC Challenge論文 |
| P.804総合品質で未処理の損失音声を下回った、参加資格を満たしたシステム | 8システム中2システム(2.11と2.17) | Microsoft、ICASSP 2024 Deep PLC Challenge論文 |
| 2024年版の音声帯域幅と聴取テストの方式 | フルバンド、48,000 Hz。ITU-T P.804の多次元評価と単語誤り率 | Microsoft Research、ICASSP 2024 Deep PLC Challengeのページ |
背景:9番目のシステムは総合2.91を記録したが、遅延の上限を超えたため未完了として掲載された。主催者は、2022年当時のシステムは「より長いロス系列ではうまく機能しない可能性がある」と指摘しており、そこはまさに冗長符号化(第6節)が受け持つ領域である。
5. 隠蔽の採点:汎用の品質指標が見逃す理由
隠蔽のエラーは短く、断続的で、しばしばもっともらしい。これは汎用の品質指標がまさに捉えるようには作られていないものである。参照に整列したデータでは、PESQのPLCシステムの人間評価とのモデル単位のピアソン相関はわずか0.52、STOIは0.21にとどまったのに対し、PLCMOSは0.98に達した(Dienerほか、PLCMOS論文、Microsoft、Interspeech 2023)。システムの順位付けを誤る指標は、研究分野全体を誤った方向へ導きかねない。
PLCMOSはクリーンな参照なしで動作する。これは、原音が受信側では決して得られない実際の通話にとって重要である。弱点はファイル単位の精度で、クリップ単位では0.85、システム単位では0.97となり、単一の通話を判定するよりもアルゴリズムの順位付けのほうがはるかに得意である。同じ緊張関係は合成音声の採点にも見られ、当社の合成音声の自然さMOS統計で取り上げている。
| 指標 | 値 | 出典 |
|---|---|---|
| PLCMOSと人間評価:モデル単位のピアソン相関と順位相関 | 約0.97と約0.95 | Dienerほか、PLCMOS論文 2023 |
| DNSMOS(汎用のノイズ抑制指標):ファイル単位とモデル単位のピアソン相関 | 0.52と0.85 | Dienerほか、PLCMOS論文 2023 |
| 参照に整列したデータでのPESQとPLCMOS:モデル単位のピアソン相関 | 0.52と0.98 | Dienerほか、PLCMOS論文 2023 |
| STOI(明瞭度の指標):モデル単位のピアソン相関 | 0.21 | Dienerほか、PLCMOS論文 2023 |
| PLCMOSの主な学習セット(LibriSpeech Basic)の人間による投票数 | 333,740 | Dienerほか、PLCMOS論文 2023 |
| IETFの機械学習コーデック聴取テスト一式のテストファイル | クリーン音声100、ノイズまたは残響90、話者の重なり20 | IETF draft-ietf-mlcodec-test-battery-00、2026年6月 |
背景:クラウドソーシングによる評価は、PLCMOSのラベリング予備調査で専門家の評価と約0.83 PCC(95%信頼区間:[0.78, 0.87])の相関を示した。IETFの聴取テスト一式のドラフトは、パケットロスのシナリオを今も「詳細未定」としており、ニューラルコーデックに対する標準的なロス試験はまだ存在しない。
6. 冗長符号化:隠蔽を避けるためにビットを支払う
隠蔽は推測し、冗長性はバックアップを送る。前方誤り訂正(FEC)とは、以前の音声の低品質なコピーを後続のパケットに付加することで、失われたパケットを作り出すのではなく再構築できるようにする方式である。トレードオフは帯域幅である。Opusの従来型の帯域内FEC(LBRR)は、通常ビットレートの約2/3でわずか1フレームをカバーするのに対し、Deep REDundancy(DRED)は通常ビットレートの約1/50で最大1秒以上をカバーする(IETF draft-ietf-mlcodec-opus-dred-07、2026年8月)。
より古いREDの方式は、その効果の大きさを示している。Chromeでのロス20%のテストでは、各パケットに直前の1フレームを送ると、隠蔽された音声の割合が18%から4%に下がり、直前の2フレームを送ると0.7%まで下がった(webrtcHacks, RED: Improving Audio Quality with Redundancy 2020)。代償として、音声は約30 kbpsから、コピー1つで60 kbps、2つで90 kbpsに増えた。DREDは、ビットレートを倍増させずに同様の保護を得るために存在する。
| 指標 | 値 | 出典 |
|---|---|---|
| Opus LBRR帯域内FEC:冗長性の深さとビットレートのコスト | 1フレーム。通常のOpusビットレートの約2/3 | IETF draft-ietf-mlcodec-opus-dred-07、2026年 |
| Opus DRED:冗長性の深さとビットレートのコスト | パケットあたり最大1秒以上。通常ビットレートの約1/50 | IETF draft-ietf-mlcodec-opus-dred-07、2026年 |
| DREDの評価:パケットごとに運ぶ冗長性と、各フレームの送信回数 | 1.04秒。コピー52回 | Valinほか、DRED論文(arXiv 2212.04453 v3、2024年) |
| DRED評価におけるLBRR試験条件のビットレート(基本24 kb/sにLBRRを加えたもの) | 合計40 kb/s、LBRRは平均約16 kb/s | Valinほか、DRED論文 2024 |
| Chromeでロス20%のときの隠蔽された音声の割合:REDなし、直前1フレーム、直前2フレームの比較 | 18%、4%、0.7% | webrtcHacks、HanckeによるREDテスト 2020 |
| ランダムロス60%のときの隠蔽された音声の割合:REDなし、直前1フレーム、直前2フレームの比較 | 60%、32%、18% | webrtcHacks、HanckeによるREDテスト 2020 |
| パケットロス10%で帯域内FECを符号化するOpusの最小ビットレート | 19 kbps(ベンダー自身の比較) | Meta Engineering、MLowコーデックのブログ 2024 |
| 受信側のパケットロス30%でのMetaのMLowサンプルのビットレート | 14 kbps(ベンダー自身の主張) | Meta Engineering、MLowコーデックのブログ 2024 |
背景:webrtcHacksの数値は2020年の単独著者による実験室テストである(ChromeにおけるREDの、入手可能な最新の公開測定)。Metaの数値は同社自身のMLowの発表に基づくもので、独立した再現はされていない。論文のP.808聴取テスト(966発話、各10人の聴取者)におけるDREDのすべての差は、p < .05で有意と報告された。
7. 隠蔽の実装:計算量、サイズ、標準
隠蔽モデルは、通話中で最も安価なスマートフォンに収まって初めて意味を持つ。Opus 1.5のDeep PLCは、高ロス時にノートPCのCPUコアの約1%を消費し、ライブラリに約1 MBを追加する(Xiph.Org, Opus 1.5 demo、2024年3月、開発者自身の数値)。同じチームによる2022年のチャレンジ参加作品は、コアの13%から14%を必要とした(第3節)が、2つの数値は測定方法が異なり、厳密な同条件の比較ではない。
これに対し、標準の層はほとんど動かない。WebRTCの音声規則(RFC 7874、2016年)はOpusとG.711を必須としているが、隠蔽やFECには何の要件も設けておらず、ロス時の品質は各実装に完全に委ねられている。Opus 1.6はモデルの縮小を続けた。そのDREDネットワークは1.5の約3分の1の大きさである(Xiph.Org, Opus 1.6 demo、2025年12月)。
| 指標 | 値 | 出典 |
|---|---|---|
| Opus 1.5のDeep PLC:追加されるライブラリサイズとCPUコスト | 約1 MB。高ロス時にノートPCコアの約1%。デコーダー複雑度5以上が必要 | Xiph.Org、Opus 1.5デモ 2024年(開発者自身の数値) |
| Opus 1.5のDRED:追加されるライブラリサイズ、実行時コスト、ビットレートのオーバーヘッド | 約2 MB。約1%。約12から32 kb/s | Xiph.Org、Opus 1.5デモ 2024年(開発者自身の数値) |
| 隠蔽音声と冗長音声の合成に使われるニューラルボコーダーFARGAN:複雑度 | 600 MFLOPS、LPCNetの1/5 | Xiph.Org、Opus 1.5デモ 2024年 |
| Opus 1.5のWebRTCテスト(PLCMOS v2)におけるロス率 | 0%から90%まで10%刻み。DREDは90%のロスでも品質を保つと報告されている | Xiph.Org、Opus 1.5デモ 2024年(開発者自身の主張) |
| Opus 1.6のDREDモデルサイズとOpus 1.5の比較 | 600 kBと1,800 kB | Xiph.Org、Opus 1.6デモ、2025年12月 |
| Opusのフレームサイズ、パケット長、ビットレート範囲 | 2.5から60 msのフレーム。最大120 msのパケット。6から510 kbit/s | IETF RFC 6716(2012年) |
| Opusのアルゴリズム遅延 | 5 msから65.2 ms | IETF RFC 6716(2012年) |
| WebRTCエンドポイントが対応しなければならないコーデック | OpusとG.711(PCMAとPCMU)。PLCやFECの要件はなし | IETF RFC 7874(2016年) |
背景:RFC 6716とRFC 7874は3年以上前のものだが、現行の標準であることに変わりはない(RFC 6716、RFC 7874)。DREDドラフトが承認されれば、ニューラルな冗長層によってRFC 6716が更新されることになる。
数字で見るWebRTC音声パケットロス隠蔽(まとめ)
| 指標 | 値 | 出典 |
|---|---|---|
| パケットロス、ジッター、遅延に対処しなければならないGoogle Duo通話 | 99% | Google Research、WaveNetEQブログ 2020 |
| 音声の8%超を失うDuo通話 | 10% | Google Research、WaveNetEQブログ 2020 |
| 音声パケットロス平均に対するTeamsの不良しきい値 | 0.1(10%)超 | Microsoft Learn、CQD Stream Classification 2026 |
| Twilioのhigh_packet_lossタグのしきい値 | 5%超 | Twilio Voice Insights、Details: Call Tags |
| G.711のロス耐性係数Bpl:隠蔽なしと付属書Iの隠蔽ありの比較 | 4.3と25.1 | ITU-T G.113(09/2024) |
| 音声区間検出を備えたG.729付属書A:Bpl | 19.0 | ITU-T G.113(09/2024) |
| 2022年チャレンジのPLCMOS:ゼロ埋め、優勝システム、クリーン音声の比較 | 2.90、4.28、4.51 | Microsoft、INTERSPEECH 2022 Deep PLC Challenge論文 |
| 2022年チャレンジの単語正解率:ゼロ埋め、優勝システム、クリーン音声の比較 | 0.86、0.88、0.97 | Microsoft、INTERSPEECH 2022 Deep PLC Challenge論文 |
| Opusチームのハイブリッド型PLCの音声10 msあたりの計算量 | 1.3から1.4 ms(1コアの13%から14%) | Valinほか 2022 |
| 2024年チャレンジのP.804総合品質:損失、最良システム、クリーン音声の比較 | 2.37、3.49、4.01 | Microsoft、ICASSP 2024 Deep PLC Challenge論文 |
| 未処理の損失音声を下回った2024年チャレンジのシステム | 8システム中2システム | Microsoft、ICASSP 2024 Deep PLC Challenge論文 |
| PLCMOSの人間評価とのモデル単位のピアソン相関 | 約0.97 | Dienerほか、PLCMOS論文 2023 |
| PLCシステムに対するPESQとSTOIのモデル単位のピアソン相関 | 0.52と0.21 | Dienerほか、PLCMOS論文 2023 |
| LBRRとDREDの冗長性の深さ | 1フレームと最大1秒以上 | IETF draft-ietf-mlcodec-opus-dred-07、2026年 |
| 通常のOpusに対するDREDの冗長性ビットレート | 約1/50 | IETF draft-ietf-mlcodec-opus-dred-07、2026年 |
| ロス20%での隠蔽された音声:REDなしと2フレームREDの比較 | 18%と0.7% | webrtcHacks、HanckeによるREDテスト 2020 |
| ロス10%でのOpus帯域内FECの最小ビットレート | 19 kbps(ベンダー自身の比較) | Meta Engineering、MLowコーデックのブログ 2024 |
| Opus 1.5 Deep PLCのCPUコスト | ノートPCコアの約1% | Xiph.Org、Opus 1.5デモ 2024年 |
| Opus 1.6のDREDモデルサイズと1.5の比較 | 600 kBと1,800 kB | Xiph.Org、Opus 1.6デモ 2025年 |
方法論と出典
- Microsoft Research、INTERSPEECH 2022 Audio Deep Packet Loss Concealment Challenge論文(Dienerほか、2022年):arxiv.org/pdf/2204.05222
- Microsoft Research、ICASSP 2024 Audio Deep Packet Loss Concealment Challenge論文(2024年):arxiv.org/html/2402.16927v1
- Microsoft Research、ICASSP 2024 Audio Deep PLC Challengeのプログラムページ:microsoft.com
- Dienerほか、PLCMOS: a data-driven non-intrusive metric for the evaluation of packet loss concealment algorithms(Interspeech 2023):arxiv.org/pdf/2305.15127
- Valinほか、Real-Time Packet Loss Concealment With Mixed Generative and Predictive Model(2022年):arxiv.org/pdf/2205.05785
- Valinほか、DRED: Deep REDundancy Coding of Speech Using a Rate-Distortion-Optimized Variational Autoencoder(arXiv v3、2024年):arxiv.org/pdf/2212.04453
- IETF、Deep Audio Redundancy (DRED) Extension for the Opus Codec、draft-ietf-mlcodec-opus-dred-07(2026年8月):ietf.org
- IETF、ML codec listening test battery、draft-ietf-mlcodec-test-battery-00(2026年6月):ietf.org
- IETF RFC 6716、Definition of the Opus Audio Codec(2012年):rfc-editor.org
- IETF RFC 7874、WebRTC Audio Codec and Processing Requirements(2016年):rfc-editor.org
- W3C、Identifiers for WebRTC’s Statistics API(勧告候補ドラフト、2025年9月25日):w3.org
- ITU-T G.113(09/2024)、Transmission impairments due to speech processing:itu.int
- ITU-T G.107(06/2015)、The E-model:itu.int
- Google Research、Improving Audio Quality in Duo with WaveNetEQ(2020年4月):research.google
- Microsoft Learn、Stream Classification in Call Quality Dashboard(2026年6月更新):learn.microsoft.com
- Microsoft Learn、Dimensions and measures available in Call Quality Dashboard(2026年7月更新):learn.microsoft.com
- Twilio、Voice Insights Details: Call Tags:twilio.com
- Meta Engineering、MLow: Meta’s low bitrate audio codec(2024年6月):engineering.fb.com
- Xiph.Org、Opus 1.5デモ(2024年3月)とOpus 1.6デモ(2025年12月):opus-codec.org/demo/opus-1.5、opus-codec.org/demo/opus-1.6
- webrtcHacks、RED: Improving Audio Quality with Redundancy(Philipp Hancke、2020年8月):webrtchacks.com
- データウォッチ:大手プラットフォームによる通話単位のロス分布はGoogleの2020年のDuoの数値のみであり、REDの隠蔽測定は2020年の単独著者によるテストであるため、どちらも入手可能な最新データとして明記している。第2節のE-modelの例は、ITU-T G.107の式7-29と付属書B、およびG.113のBpl値を用い、他のすべての入力を既定値に保って当社が計算したものであり、測定値ではなく推定値である。チャレンジのスコアは版をまたいで比較できない。2022年は広帯域音声、PLCMOSとCMOS、最大1秒のバーストを用い、2024年はフルバンド音声、P.804、最大3秒のバーストを用いた。2022年の論文ではPLCMOSとCMOSのピアソン相関は約0.95だったが、後のPLCMOSリリースでは別の評価セットで約0.97と報告されている。Xiph.OrgとMetaの数値は開発者自身の主張である。Teams(10%)とTwilio(5%)のしきい値は、各ベンダーが自社のメディアスタックに合わせて調整しているため、設計上食い違う。DREDドラフト(2027年2月に失効)と、パケットロスのシナリオが未定義のままであるIETF聴取テスト一式のドラフトは、RFCとして公開される前に変更される可能性がある。
最終更新日:2026年10月24日。当社はこのまとめを四半期ごとに更新しており、次回の更新は、IETFのmlcodecワーキンググループがOpus DREDドラフトの次の改訂版と、聴取テスト一式のパケットロスシナリオを公開した時点を予定している。