リアルタイムメディア | オーディオの基本

On By Rob Hanton1 Min Read
Cisco Hybrid Work Experience Event With Group Tour

リアルタイムメディア入門シリーズの第 2 回では、リアルタイム会議におけるオーディオの基本事項をいくつかご紹介します。

オーディオはアナログの現象ですが、録音する場合にはデジタルの近似値に変換する必要があります。 その際に重要なのが、サンプリングレートビット深度という 2 つの数値です。 サンプリングレートとは、アナログ波形を 1 秒間にサンプリングする回数のことであり、ビット深度とは、取り得る値の範囲を表すために利用できるビット数です。

オーディオのビット深度

ナイキストシャノンの定理(別名標本化定理)では、サンプリングレートは、再現する周波数の最低 2 倍必要だとされています。 通常、人が聞き取れる音域は 22,000Hz 程度までなので、CD など忠実度の高いフォーマットのサンプリングレートの目標は >44,000Hz 超に設定されるのが一般的です。 しかし、人の話し声の周波数は、せいぜい 3,000 ~ 4,000Hz 程度です。そのため、人の声のみに最適化したオーディオコーデックならば、6,000 ~ 8,000Hz のサンプリングレートで十分ということになります。 オーディオコーデックは、多くの場合、次のように分類されます。

  • ナローバンド:人間の話し声を理解できる最低限の音域をサンプリングする。多くの場合、約 300Hz から約 3,400Hz。
  • ワイドバンド:人の話し声の全音域をサンプリングする。50Hz から約 7,000Hz。
  • フルバンド:音楽やその他の可聴音をサンプリングする。50Hz から約 22,000Hz。

サンプリングレートは、コーデックがエンコードできる周波数を決めるものです。一方ビット深度は、どの程度原音に忠実な音になるかを決める重要な要素の 1 つです。特定のポイントにおける波の振幅をエンコードするのに使えるビットが多いほど、(元のアナログの波形に近くなって)コーデックの忠実度が高まりますが、代償としてペイロードのサイズは大きくなります。 サンプルあたり 8 ビットしか使わない特に簡素なコーデックの場合、大半の聞き手が著しく質の悪い音だと感じます。 オーディオ CD は 16 ビットを使用し、多くの聞き手にとってはこれで「十分」ですが、高い忠実度を目指す最新の高精度なコーデックの場合、サンプルあたり 24 ビット、場合によっては 32 ビットを使用するはずです。

サンプリングレートビット深度が同じでも、コーデックが違えば、圧縮の方式が違い、達成できるビットレートも異なります。一般的には、ある一定レベルの品質で帯域幅を低く抑えたければ CPU を追加する必要があります。

オーディオコーデックを選ぶ条件には、他にもサンプリングレートあたりのペイロードサイズがあります。つまり、一定のオーディオパケットに何ミリ秒のオーディオが含まれているかということです。 ペイロードサイズが小さいと、1 秒あたりのパケット数が増えるため遅延は低く抑えられますが、1 秒あたりのパケットオーバーヘッドに多くのビット数を割かなければならないため、帯域幅の効率は低下します。 オーディオコーデックの最も一般的なペイロードサイズは 20ms、つまり 1 秒あたり 50 パケットです。なお、最新のコーデックの場合、複数のオーディオレートに対応している場合もあります。

広くサポートされている 6 つのオーディオコーデック

Webex Calling および Webex Meetings とペアリングしたシスコのコラボレーションデバイスを利用して自宅で仕事をするモールビジネスの経営者

Voice over IP を利用したリアルタイムの通話と会議システムには、長年にわたり、さまざまなオーディオコーデックが搭載されてきました。 通話のプロトコルやユースケースが違うと、コーデックもそれぞれ独自の組み合わせを使っている傾向があります。コーデックの組み合わせは、他のユースケースやプロトコルの場合と一部重なることもあれば、重ならないこともあります。 実装者がどのオーディオコーデックをサポートするか決める際は、事前に対象分野を調べて現時点で広くサポートされている組み合わせを特定しておくとよいでしょう。特に、現時点もしくは将来的に相互運用可能にする計画がある場合には、そうすることを強くおすすめします。

では、特に広くサポートされているビデオ会議のオーディオコーデックをいくつか取り上げ、それぞれの重要ポイントを列挙して紹介していきましょう。

1) G.711

G.711 iは、現存する中で最も基本的なオーディオコーデックの 1 つであり、広くサポートされています。 音の品質は悪く、従来の公衆電話交換網(PSTN)の長距離回線と同程度という意味で、長距離通話品質と呼ばれています。圧縮が一切行われないため、この品質でも 64Kb/秒が必要となります。 しかし、実装が極めて簡単で、CPU 要件も極めて低いため、実装と導入を非常に安価に済ませることができます。

今も PSTN から IP にゲートウェイする際に広く利用されており、最新製品を含む大半の製品でサポートされています(PSTN のそもそもの品質を考えると、多くの場合は G.711 で十分だからです)。 G.711 は、望ましいものではないものの相互運用に活用できる「最小公倍数」的なコーデックの役割を担っているのです。 WebRTC(Web リアルタイム コミュニケーション、ブラウザを使った音声通話やビデオ通話に利用)でさえ、要件が標準化されたのが 2016 年であるにもかかわらず G.711 のサポートを義務付けているのはこのためです。 G.711 は実装しやすく、相互運用性の面でもデバッグの面でも役立つため、実装には G.711 のサポートを含めることをおすすめします。

なお、G.711 には、μ-law(ASCII 表記では u-law)と A-law という 2 つのバリエーションがあります。 この 2 つのバリエーションでは、使用するコンパンディング(ダイナミックレンジをまず「compress(圧縮)」し、その後「expand(伸張)」すること)の方式が若干異なります。 A-law に比べて μ-law がサポートするダイナミックレンジはやや広いものの、小さい音の信号を処理した場合の音質が若干落ちます。 北米と日本では μ-law がよく使用されていますが、その他の地域では A-law が一般的です。 実装では、μ-law と A-law の両方をサポートするようにしましょう。

2) G.729

G.729 は比較的古いコーデックで、G.711 と同等の音質を数分の 1 のビットレートで実現しようとするものです。 サンプリングレートは G.711 と同じ、ビット深度は G.711 より大きいのですが、非可逆圧縮のため、実際の音質は G.711 にやや劣ります。一方、ビットレートは大幅に低くなります。 最新のコーデックなら同じビットレートではるかに高い品質を実現できるため、G.729 は、主に旧式のシステムか計算能力が極めて限られているシステムで使用されています。

基本的な G.729 コーデックにはさまざまな拡張が行われてきました。主要な拡張は Annex A(品質はわずかに低下するが計算費用を低減)と Annex B(無音を検出すると送信を停止)です。このため、G.729 ストリームといっても、G.729 だけでなく、G.729A、G.729B、G.729AB の場合があります。 なお、Annex A は元の実装と互換性があるためネゴシエートする必要はありませんが、Annex B の場合には必要です。 送信元と送信先の双方が使用如何について合意している必要があります。 これは、コーデックの SDP(Session Description Protocol)ネゴシエーションに含まれます。G.729 を提供する最新の実装の場合、Annex B をサポートしているものがほとんどです。

3) G.722

G.722 は比較的古いワイドバンドコーデックです。G.729 が G.711 と同等のオーディオ品質ではるかに高い圧縮率を実現しようとするものであるのに対し、G.722 は、G.711 と同じビットレートではるかに高い品質を実現しようとするものです。 G.722 は、忠実度の高いオーディオを目指す古いシステムで主に使われています。なお、新しいコーデックを使えばより低い帯域幅での品質をより高くすることができるため、G.722 は主に相互運用性への配慮として実装されています。

4) iLBC

iLBC オーディオコーデックの詳細:名前、タイプ、サンプリングレート、ビット深度、ビットレート、ペイロードサイズ

インターネット低ビットレートコーデックiLBC)は、G.729 を最新版に引き継ぐために設計されたコーデックです。CPU 要件は同等、ビットレートもわずかに高くなるだけで、著しく高い品質を実現します。 パケット損失に対応する機能が組み込まれており、その名の通り、信頼性が比較的高い企業内ネットワークではなく、公共のインターネット上で動作することを想定した設計となっています。 ただ、Web の音声アプリケーションではサポートされているものの、他の分野ではあまり採用されていません。

5) AAC

Advanced オーディオコーデックの詳細:名前、タイプ、サンプリングレート、ビット深度、ビットレート、ペイロードサイズ

Advanced Audio CodecAAC)は、現代のさまざまなアプリケーションで使われている MP3 の後継として、録音済みのオーディオ向けに設計されたコーデックです。 AAC には、実際には多様なツールセットや動作モードが存在しており、そのうちの 1 つが Advanced Audio Coding-Low Delay(AAC-LD)です。LD とは、「低遅延(Low Delay)」のことです。 AAC-LD はリアルタイムの用途に最適化された AAC のバリエーションです。Session Initiation Protocol(SIP)に準拠したものや独自仕様の数多くのビデオ会議で、高品質のオーディオを実現できる最新のワイドバンドまたはフルバンドコーデックとしてサポートされています。 AAC は非常に複雑なフォーマットであり、特許の問題もあるので、AAC-LD をサポートする大半のビデオ会議ソフトウェアは、Fraunhoffer など別の団体からライセンスの供与を受けた実装を通じて提供されています。

6) Opus

Opus は最新のオーディオコーデックです。非常に低い帯域幅から忠実度の高いフルバンドまで幅広いリアルタイムユースケースに対応できる「万能」のコーデックとして設計されたものであり、特許フリーのオープンソースです。 エンコード時に有効にできるツールも多数搭載されています。損失を防止する前方誤り訂正(FEC)(後日掲載するメディア復元力に関するブログ記事を参照)が標準で搭載されているほか、無音時の帯域幅を大幅に削減するモードも備えています。

さまざまな帯域幅やその他の機能をサポートしている AAC-LD などの他のコーデックとは違い、Opus の利用に際しては、動作点や使用するツールのネゴシエーションは不要です。その代わり、受信側は「指針」を提供できます。送信側は動作点とツールを自由に選ぶことができ、受信側はそれらを処理するよう要求されます。 このため、Opus のデコーダには、要件に準拠するよう、ツールセットすべてを実装する必要があります。 実装者は、Opus のエンコードとデコードの両方に、オープンソースの libopus ライブラリを使用するよう強くおすすめします。 Opus は WebRTC で使用されているほか、その他の最新のリアルタイムメディア会議ソリューションでますます広く使用されるようになっています。

その他の記事:

About The Author

Rob Hanton
Rob Hanton Principal Engineer and Architect Cisco
Rob Hanton is a Principal Engineer and architect for Webex.
Learn more

Topics


More like this