G.726

G.726
40、32、24、16 kbit/s 適応差分パルス符号変調 (ADPCM)
状態	有効
開始年	1990
最新バージョン	(05/06) ; 2006年5月
組織	国際電気通信連合
基本基準	G.721
ドメイン	オーディオ圧縮
ライセンス	無料で利用可能
Webサイト	https://www.itu.int/rec/T-REC-G.726

G.726 は、16、24、32、40 kbit /sの速度での音声伝送をカバーするITU-T ADPCM 音声コーデック規格です。これは、32 kbit/s の ADPCM をカバーする G.721 と、24 および 40 kbit/s の ADPCM を規定するG.723の両方に取って代わるために導入されました。G.726 では、新しい 16 kbit/s の速度も導入されました。G.726 に関連付けられている 4 つのビットレートは、サンプルのビットサイズで参照されることが多く、それぞれ 2、3、4、5 ビットです。同じテクノロジに基づく対応する広帯域コーデックはG.722です。

最も一般的に使用されるモードは 32 kbit/s で、これはG.711の半分の速度を使用して使用可能なネットワーク容量を 2 倍にします。これは主に電話ネットワークの国際トランクで使用され、 DECTワイヤレス電話システムで使用される標準コーデックです。24 および 16 kbit/s チャネルの主な用途は、デジタル回線多重装置(DCME)で音声を伝送するオーバーロードチャネルです。40 kbit/s チャネルの主な用途は、DCME でデータモデム信号を伝送することです。特に、4800 bit/s を超える速度で動作するモデムで使用されます。

歴史

G.721 は 1984 年に導入され、G.723は 1988 年に導入されました。これらは 1990 年に G.726 に統合されました。

G.727 はG.726 と同時に導入され、同じビットレートを含みますが、パケット回線多重化装置 (PCME) 環境向けに最適化されています。これは、2 ビット量子化器を3 ビット量子化器に埋め込み、さらに上位モードにも同じことを行うことで実現されます。これにより、音声信号に悪影響を与えることなく、ビットストリームから最下位ビットを削除できます。

特徴

サンプリング周波数 8 kHz
16 kbit/s、24 kbit/s、32 kbit/s、40 kbit/s のビットレートが利用可能
ビットストリームを生成するため、フレームの長さはパケット化時間によって決まります（通常、10 ms のフレームサイズの場合は 80 サンプル）
典型的なアルゴリズム遅延は0.125ミリ秒で、先読み遅延はありません。
G.726は、適応差分パルス符号変調（ ADPCM）を使用する波形音声符号化器である。
理想的な条件下でのPSQMテストでは、G.726 (32 kbit/s) の平均オピニオンスコアは4.30 であるのに対し、 G.711 ( μ-law )では 4.45 である^{[引用が必要]}
ネットワークストレス下でのPSQMテストでは、G.726（32 kbit/s）の平均オピニオンスコアは3.79で、G.711（μ-law）では4.13でした。
40 kbit/s G.726 は 12000 bit/s およびそれより遅いモデム信号を伝送できますが、32 kbit/s G.726 は 2400 bit/s およびそれより遅いモデム信号を適切に伝送でき、クリアチャネルコーデックよりも多少の劣化はありますが 4800 bit/s を伝送できます。

エンディアンとペイロードタイプ

インターネットのコンテキストにおけるデータプロトコルのバイトオーダーは、一般にビッグエンディアンとして定義され、廃止された RFC 1700 などで述べられているように、単にネットワークバイトオーダーと呼ばれていたため、廃止された RFC 1890 では、RTP における G.726 の前身である G.721 のエンディアンも明示的に定義されていませんでした。その代わりに、廃止された RFC 1890 では、ネットワークバイトオーダーという用語によるビッグエンディアンの使用が、言及されているすべてのコーデックに対して一般に再度述べられました。

「マルチオクテットエンコーディングの場合、オクテットはネットワークバイト順（つまり、最も重要なオクテットが最初）で送信されます。」
— IETF、廃止された RFC 1890、セクション 4.2

G.721 のペイロードタイプは、廃止された RFC 1890 で2と定義されているため、ですa=rtpmap:2 G721/8000。この RFC の新しいバージョンのドラフトでは、 G.726 に再利用されましたa=rtpmap:2 G726-32/8000。

それとは対照的に、ITU は G.726 または ADPCM に関する勧告でバイト順序を明示的に定義しましたが、2 つの異なる方法で定義しました。勧告X.420では、勧告I.366.2 付録 E を尊重するために、ビッグエンディアンであるべきであると規定されています。これにより、一部のメーカーはリトルエンディアンを選択し、他のメーカーはビッグエンディアンを選択したため、さまざまな実装で矛盾した決定が下されました。その結果、これらの実装は互換性がなくなり、間違ったバイト順序を使用してデコードすると、オーディオ信号がひどく歪んでしまいます。そのため、この不明瞭な定義は、RFC 1890 に代わる RFC 3551 によって修正されました。RFC 3551 のセクション 4.5.4 では、従来の MIME タイプ G726-16、24、32、40 をリトルエンディアンとして定義し、ビッグエンディアン用の新しい MIME タイプとして AAL2-G726-16、24、32、40 を導入しています。ペイロードタイプは、混乱を避けるために動的に変更されました。ペイロードタイプ2の代わりに、96 から 127 の範囲の動的ペイロードを使用する必要があります。

「ここで指定されている G726-16、-24、-32、-40 ペイロードフォーマットでサンプルがオクテットにパックされる「リトルエンディアン」方向は、ITU-T 勧告 X.420 と一致していますが、ATM AAL2 トランスポートの ITU-T 勧告 I.366.2 付録 E で指定されているものとは逆です。I.366.2 付録 E のパケット化と一致し、MIME サブタイプ AAL2-G726-16、-24、-32、-40 で識別される 2 番目の RTP ペイロードフォーマットのセットは、別のドキュメントで指定されます。」
— IETF、RFC 3551、セクション 4.5.4

「ペイロードタイプ 2 は、RFC 1890 では G721 に割り当てられ、この仕様のドラフトバージョンでは同等の後継である G726-32 に割り当てられましたが、現在ではその使用は非推奨であり、その静的ペイロードタイプは、ペイロード形式 G726-32 と AAL2-G726-32 の使用が競合するため予約済みとしてマークされています (セクション 4.5.4 を参照)」
— IETF、RFC 3551、セクション 6

新しい実装は RFC 3551 を尊重し、G726-xx (リトルエンディアン) と AAL2-G726-xx (ビッグエンディアン) を明確に区別します。たとえば、Gigaset C610 IP DECT 電話は、SIP INVITE で次のコードを生成します。

a=rtpmap:96 G726-32/8000→ X.420 に従った動的ペイロードタイプ96および G.726 (RFC 3551 で定義されるように、リトルエンディアン) → I.366.2 付録 E に従った
a=rtpmap:97 AAL2-G726-32/8000動的ペイロードタイプ97
a=rtpmap:2 G726-32/8000および G.726 (RFC 3551 で定義されるように、ビッグエンディアン) → 廃止された RFC 1890 に従った G.721 のような予測不可能なエンディアンを持つ静的ペイロードタイプ2および G.726

参照

外部リンク

ITU-T G.726 ページ
G.726 C コードを含む音声およびオーディオコーディング用の ITU-T G.191 ソフトウェアツール
RFC 3551 - 最小限の制御による音声およびビデオ会議の RTP プロファイル、G726-40、G726-32、G726-24、および G726-16