Opus 1.5リリース：機械学習でアップグレードされたOpus

 (opus-codec.org)
1 ポイント 投稿者 GN⁺ 2024-03-05 | 1件のコメント | WhatsAppで共有
  • 機械学習ベースの機能として、パケット損失隠蔽、低ビットレート音声品質の向上、DREDによる冗長伝送を追加しつつ、RFC 6716との完全な互換性を維持
  • 新しいMLベース機能はデフォルトでは無効で、サイズとCPUコストのため、ビルド時スイッチと実行時スイッチの両方が必要
  • Deep PLCは--enable-deep-plcでビルドし、デコーダの複雑度を5以上に設定すると動作する。デコーダにのみ影響するため互換性への影響はない
  • DREDは--enable-dredで有効化し、--enable-deep-plcも自動的に有効化する。まだ標準化されておらず、Opus 1.5のDREDは最終版と互換性がないが、ビットストリームの実験版番号で不一致を検出し、DREDペイロードを無視する
  • DREDは最大1秒分の冗長オーディオを一度に送信し、約12〜32 kb/sのオーバーヘッドで20msパケットを実質的に50回送信する方式
  • 低ビットレート音声の改善のためにLACEとNoLACEを追加。--enable-osceでビルドした後、デコーダ複雑度6でLACE、7以上でNoLACEが有効化される
  • LACEとNoLACEは現在、フレームサイズ20ms、帯域幅がwideband以上の場合にのみ適用され、エンコーダとは独立した改善であるため互換性への影響はない
  • DREDの利用にはジッタバッファとのより密接な統合が必要で、Google WebRTCリポジトリのフォークであるwebrtc-opus-ngパッチでDREDを試験できる
  • IETF mlcodecワーキンググループで、Opus拡張メカニズム、deep redundancy、speech coding enhancementの標準化作業が進行中
  • AVX2/FMAサポートとランタイム検出を追加し、対応機器では新しいDNNコードとSILKエンコーダが256ビットSIMDを使用する
  • AArch64でARMv7 Neon最適化を再有効化し、Cortex-A75以降でArm dot product拡張をランタイム検出して、新しいDNNコードの8ビット整数内積を高速化
  • 現実的なパケット損失シミュレータを追加。--enable-lossgenでビルドした後、opus_demoで-sim-loss <percentage>として使用可能

関連記事

1件のコメント

 
GN⁺ 2024-03-05
Hacker Newsの意見

  • この種のコーデックの主な制約は CPUとバッテリー寿命 だが、ここでは機械学習をあちこちに控えめに適用し、従来の非機械学習アルゴリズムと組み合わせることで、CPUに対する品質のトレードオフをうまく取っている点が気に入った
    たとえば低ビットレート/LACE対応では「実証済みのポストフィルタのアイデアから始め、その上にディープラーニングのニューラルネットワークの魔法を本当に必要な分だけ振りかけた」としている
    要点は、生のオーディオサンプルをニューラルネットワークに入れないことだ。「オーディオそのものは決してDNNを通らない。その結果、DNNとしては小さく、複雑さが非常に低いモデルになり、古い携帯電話でも実行できる」というアプローチだ
    組み込みアルゴリズムには正しい方向に見えるし、最近流行している エンドツーエンド機械学習 と比べると、かなり未開拓な領域に見える

    • 機械学習をとても賢く使った例だ。周辺で補助させるだけにして、機械学習アルゴリズムが偶然 音素や単語全体を作り出してしまうこと を防いでいる
      機械学習ベースの音声認識も一部のベンチマークでは優れているが、結果を幻覚する似たようなトレードオフがある

  • P2Pオーディオストリーミングライブラリ(https://git.iem.at/cm/aoo/ - まだアルファ)で Opus を主要コーデックの1つとして使っているので、とてもうれしいニュースだ
    新しい機械学習機能はぜひ自分で触ってみたい

  • NoLACE で9kbpsでこれほど良い音声品質が得られるのは、本当に信じられないほどすごい

    • 1999年に大手音楽ストリーミングスタートアップのリード開発者だった。まだオフィスもなく在宅勤務中だったが、ケーブル接続が切れてしまい、残ったインターネットは Nokia 9000のシリアルポート 経由の9600bpsだけだった
      本番コードをテストし続けるために、音楽カタログ全体を8000kbps WMAで再エンコードしてストリーミングしなければならなかった
      品質はいまひとつだった
    • 本当に初期のストリーミングオーディオコーデック realaudio 1.0 と比べるとどんな音か見てみたかった
      $ ffmpeg -i female_ref.wav - acodec real_144 female_ref.ra
      サポートされないかもしれないので、再びwavに変換して置いておいた: http://9ol.es/female_ref-ra.wav
      これは90年代半ばの14.4kb/sダイヤルアップ向け「14.4」オーディオと見なされていた。ほぼ30年の間に、実際にはより少ないバイト数で得られる品質がここまで向上したのは本当に印象的だ

  • オーディオコーデック、音声合成、音声認識 が相互にかみ合いながら進歩していくのが興味深い。片方の進歩がたいていもう片方の進歩につながる

  • 気になるのは、よくある 機械学習の倫理的な問い を扱っているのかという点だ。具体的には、男性の声と女性の声でアルゴリズムの性能が良かったり悪かったりするのか、言語や方言によってどうなのか、そもそも音声専用なのか、それとも音楽や鳥のさえずりにもよく機能するのかが気になる
    それでもサンプルは印象的で、この程度に聞き取れる品質が通話の標準になることを期待している

    • 論文によれば、学習は「34の言語と方言、900人以上の話者を含むTTSデータセットの組み合わせから得た 16kHz音声205時間」で行われた
      主に英語でテストされたが、まだ標準化されていないため、早めに公開した理由の1つは、人々に実際に使ってもらって問題を報告してもらうためだ
      男女話者の比率はほぼ同じだ。ただしコーデックでは常に、音の高さによってどちらかの方向にわずかな知覚品質の偏りが生じる。そしてここにあるものはすべて音声専用だ
    • 重要な問いではあるが、非機械学習の手作業で調整されたアルゴリズムにも似たような バイアス は簡単に存在しうる
      その場合でも、良いパラメータを見つけるためにテストセット、時には「学習」セットや「検証」セットまで使われる。こうしたデータも、判断を下す評価者の耳も、どちらもバイアスの源になりうる
      機械学習では、本質的にデータなしではアルゴリズムが動かないため、バイアスの問題がよく話題になるが、あらゆるアルゴリズムは人間が設計し、多くのアルゴリズムはパラメータ設定にデータを用いる。どちらもバイアスの源になりうる
      機械学習のほうがよく知られている理由は、従来のアルゴリズムより 帰納バイアス が少なく、データセット内のバイアスをより取り込みやすいからだと思う
    • なぜ倫理の問題が重要なのかわからない。これはオーディオコーデックの新機能であって、子どもの教育課程に入れる新しい教材ではない
    • 別の言語やアクセントを使う立場として、こういうことはよく経験する。ネイティブ話者には問題ないのに、Siri のようなアシスタントが自分の言おうとしていることを理解できない、といった具合だ
      UTFが広く使われる前には、ウェブサイトやアプリが自分の言語で使う特殊文字を無視していたのも似ていた
      これは倫理問題というより、技術的な限界や無知に近いと思う

  • テキストの 字幕ストリーム を一緒に入れたらどうだろうと思う。エンコーダは機械学習で音声をテキストに変換し、デコーダはそのテキストとオーディオの途切れの周辺の音声を一緒に使って、条件付きテキスト音声変換DNNに入力できる
    そうすればネットワークは、オーディオだけを見て途切れた区間を盲目的に補間するという、より難しい問題を学ぶ必要がなくなる。テキストストリームは低ビットレートなので、特定のテキストメッセージが受信される可能性を高めるために、かなりの冗長性を入れることもできる

    • 実際、DRED がやっていることはその提案とそれほど遠くない。違いは、音声/イントネーションに関する情報をより多く保持していることと、ASRが追加する遅延を必要としない点だ
      最終的に出力は、より高レベルで効率的に圧縮された情報から合成される

  • とてもクールだ。幻覚問題 を扱っているように見える。冗長性がないときに幻覚が生じ、冗長性で修正される例を見ると面白そうだ

    • パケット損失隠蔽(PLC)も一種の 幻覚 ではないのか？ 悪い意味ではなく、統計的にもっともらしい形で Making Shit Up™ しているわけだが

  • 今回の新しい Opus バージョンが、低ビットレートで優れていたxHE-AACとの差を縮めたのか気になる

    • 音声をエンコードするのか音楽をエンコードするのかによる

  • Opus 1.5が、音声では 16kbps でも事実上透明になり、96kbpsでも192kbps MP3より依然として優れているのがよい
    一方でxHE-AACは96〜256kbps帯で、AAC-LC(Apple, FDK)の約160kbpsより実際には悪く見えるので、相変わらず雑な仕上がりに感じる

  • 既存の損失形式を再エンコードするときに、アーティファクトを増やしすぎないよう助けてくれる プロファイラや設定 があればどうだろうと思う
    大きなコレクションでは、可逆の元データに簡単にアクセスできないとこの問題にぶつかる
    追加の品質低下が最小限だとわかるなら、複数のmp3、aac、vorbisファイルをOpusへ移行することに大いに関心がある