音声エンコードの概要

音声エンコードとは音声データを格納および送信する方法のことです。この後のドキュメントでは、このエンコーディングの仕組みを説明します。アプリケーションに最適なエンコードを選択する際のガイドラインについては、ベスト プラクティスをご覧ください。

デジタル音声エンコードは複雑なトピックですが、通常は Speech API で音声を処理するために詳細まで知っている必要はありません。ここで説明する概念は、あくまで概要にすぎません。この背景情報は、API の動作の仕組みや、アプリケーションで音声を構成して処理する方法を理解するために便利となる場合があります。

音声形式と音声エンコード

音声形式と音声エンコードは同じものではありません。たとえば、.WAV のような一般的なファイル形式は、音声ファイルのヘッダー形式を定義するものであり、それ自体は音声エンコードではありません。必ずというわけではありませんが、多くの場合、.WAV 音声ファイルでは、リニア PCM エンコードが使用されます。ただし、実際に使用されているエンコードは .WAV ファイルのヘッダーを調べてみるまでわかりません。

一方、FLAC はファイル形式とエンコード両方の名前です。そのため、混乱が生じる場合があります。Speech-to-Text API では、音声データにヘッダーを設定する必要があるエンコードは FLAC のみです。その他の音声エンコードはいずれもヘッダーのない音声データを指定します。Speech-to-Text API においては、FLAC とはコーデックの種類を指します。FLAC ファイル形式を指す場合は「.FLAC ファイル」と表記します。

WAV または FLAC ファイルのエンコードとサンプルレートを指定する必要はありません。省略した場合、Cloud Speech-to-Text により、ファイル ヘッダーに基づいて WAV または FLAC ファイルのエンコードとサンプルレートが自動的に決定されます。ファイル ヘッダーの値と一致しないエンコードまたはサンプルレートの値を指定すると、Cloud Speech-to-Text からエラーが返されます。

サポートされている音声エンコーディング

Speech-to-Text API は、さまざまなエンコードをサポートしています。次の表に、サポートされているオーディオ コーデックをリスト表示します。

コーデック 名前 ロスレス 使用上の注意
FLAC Free Lossless Audio Codec ストリームには 16 ビットまたは 24 ビットが必要
LINEAR16 Linear PCM
MULAW μ-law ×
AMR Adaptive Multi-Rate Narrowband × サンプルレートは 8,000 Hz にする必要があります
AMR_WB Adaptive Multi-Rate Wideband × サンプルレートは 16,000 Hz にする必要があります
OGG_OPUS Ogg コンテナ内の Opus でエンコードされた音声フレーム × サンプルレートは 8,000 Hz、12,000 Hz、16,000 Hz、24,000 Hz、48,000 Hz のいずれかにする必要があります
SPEEX_WITH_HEADER_BYTE Speex ワイドバンド × サンプルレートは 16,000 Hz にする必要があります

Cloud Speech-to-Text のオーディオ コーデックの詳細については、AudioEncoding リファレンス ドキュメントをご覧ください。

ソース マテリアルのエンコード時に選択できる場合は、音声認識向上のために、FLACLINEAR16 などのロスレス エンコードを使用してください。タスクに適切なコーデック選択のガイドラインについては、ベスト プラクティスをご覧ください。

エンコードを行う理由

音声は波形で構成されていて、さまざまな周波数や振幅の波が介在します。デジタル メディアでこれらの波形を表すには、(少なくとも)複製する音のうち最高の周波数の音を表すレートで波形をサンプリングする必要があります。また、音声サンプル全体で波形の所定の振幅(大きな音と静かな音)を表せるだけのビット深度が波形に必要です。

音声処理デバイスが周波数を再作成する能力は周波数応答と呼ばれ、大きな音や静かな音を適切に作成する能力はダイナミック レンジと呼ばれています。これらを総称して音声デバイスの忠実度と呼ぶことも多くあります。エンコードを最も簡単に表現すると、これらの 2 つの基本原理を使用して音声を再構築し、これらのデータを効率的に保存および転送する手段です。

サンプリング レート

音声はアナログ波形として存在します。デジタル音声のセグメントは、アナログ波形本来の周波数を再現するために十分な速度で波形の振幅をサンプリングし、アナログ波を再現します。デジタル音声セグメントのサンプルレートは、音声のソース マテリアルから 1 秒間に取得するサンプルの数を表します。サンプルレートを高くすると、デジタル音声は高い周波数を忠実に再現できるようになります。

ナイキスト・シャノンの定理により、一般的にデジタル形式で取得する音声の最高周波数の少なくとも 2 倍の周波数でサンプリングする必要があります。たとえば、人間の可聴音域(20~20,000 Hz)の音声を再現するには、デジタル音声形式で 1 秒間に少なくとも 40,000 回のサンプリングが必要です(CD オーディオでサンプルレートが 44,100 Hz である理由のひとつ)。

ビット深度

ビット深度は特定の音声サンプルのダイナミック レンジに影響します。ビット深度が高いほど、振幅を正確に再現できます。同じ音声サンプルで大きな音と静かな音が大量に存在する場合に、このような音声を正確に再現するには、ビット深度を高くする必要があります。

ビット深度が高くなると、音声サンプル内の信号対雑音比が小さくなります。CD 音楽オーディオではビット深度は 16 ビットです。DVD オーディオのビット深度は 24 ビットで、大部分の電話機のビット深度は 8 ビットです(一部の圧縮技術ではビット深度の小ささを補うこともできるが、損失が多くなる傾向がある)。

非圧縮音声

大部分のデジタル音声処理では、サンプリング レートとビット深度の 2 種類の手法を使用して音声データを直接保存しています。最も一般的なデジタル音声手法のひとつとして、パルス符号変調(PCM)が挙げられます(CD で用いられています)。音声は設定された間隔でサンプリングされ、その時点でサンプリングされた波の振幅はサンプルのビット深度を使用してデジタル値として保存されます。

リニア PCM(振幅応答がサンプル全体で線形に均一であることを表す)は、CD と Speech-to-Text API の LINEAR16 エンコードで使用される標準です。どちらのエンコードでも音声データに直接対応するバイトの非圧縮ストリームが生成され、どちらの標準でもビット深度は 16 ビットです。リニア PCM では、CD で 44,100 Hz のサンプルレートを使用しています。これは音楽の再構成には適していますが、音声の再構成には 16,000 Hz のサンプルレートのほうが適しています。

リニア PCM(LINEAR16)は、デジタルデータが上記の標準に従って格納されるため、非圧縮音声の一例とされます。リニア PCM を使用してエンコードされたバイトの 1 チャンネル ストリームを読み取る際に、たとえば 16 ビット(2 バイト)ごとに読み取り、波形の別の振幅値を取得することができます。ほぼすべてのデバイスでこのようなデジタルデータをネイティブに操作できます。リニア PCM 音声ファイルでテキスト エディタによる切り抜きを行うこともできます。しかし、当然ながら非圧縮音声はデジタル音声の転送や保存のための最も効率的な方法ではありません。そのため、ほとんどの音声ではデジタル圧縮手法を使用しています。

圧縮音声

音声データは他のすべてのデータと同様に、保存や転送がしやすいように圧縮されることがあります。音声エンコード内での圧縮はロスレス(ロスがない)圧縮とロッシー(ロスが多い)圧縮があります。ロスレス圧縮の場合、デジタルデータを展開して元の形式に復元することができます。ロッシー圧縮では必然的に圧縮中や展開中に情報の一部が削除され、圧縮手法においてどの程度のデータ削除が許容されるかを示すためにパラメータ化されます。

ロスレス圧縮

ロスレス圧縮では、デジタル音声データの圧縮のために、保存されたデータを複雑に再構成していますが、元のデジタル サンプルの品質が劣化することはありません。ロスレス圧縮の場合、データを展開して元のデジタル形式に復元しても、情報は失われません。

では、ロスレス圧縮手法に最適化パラメータが設定されていることがあるのはなぜでしょうか。これらのパラメータでは、圧縮ファイルのサイズと展開時間の関係が設定されます。たとえば、FLAC では圧縮レベル パラメータが 0(最高速)から 8(ファイルサイズが最小)まであります。低レベルの圧縮に比べて、FLAC 圧縮のレベルが高い場合には情報が失われません。一方、元のデジタル音声の構成時や分解時に、圧縮アルゴリズムによる計算量が増加します。

Speech-to-Text API では、FLACLINEAR16 の 2 種類のロスレス エンコードがサポートされています。技術的には、LINEAR16 では最初の段階で圧縮が行われることはないため、「ロスレス圧縮」とは言えません。ファイルサイズやデータ送信が重要である場合は、音声エンコードとして FLAC を選択します。

ロッシー圧縮

一方、ロッシー圧縮による音声データの圧縮では、圧縮データの構成時に特定のタイプの情報が削除されるか減少します。Speech-to-Text API では一部のロッシー形式がサポートされていますが、データのロスが認識精度に影響する場合があるため、音声を管理する場合はこの形式を避けるべきです。

ロッシー エンコード手法の例として、一般的な MP3 コーデックが挙げられます。どの MP3 圧縮手法でも、通常の人間の可聴域にない音声が削除されます。また、MP3 コーデックの有効なビットレート(1 秒あたりのビット数)を調整して音声データを保存することにより、圧縮データが保存されます。

たとえば、16 ビットのリニア PCM を使用するステレオ CD の有効ビットレートは次のようになります。

44100 * 2 channels * 16 bits = 1411200 bits per second (bps) = 1411 kbps

MP3 圧縮では 320 kbps、128 kbps、96 kbps などのビットレートを使用してデジタルデータを削除するため、音声品質が劣化します。MP3 では可変ビットレートもサポートされているため、音声をさらに大幅に圧縮することができます。どちらの手法でも情報の損失が発生し、品質に影響が生じます。たとえば、96 kbps でエンコードした場合と 128 kbps でエンコードした場合では、MP3 音楽の違いがほとんどの人が認識できるほど大きくなります。

その他の圧縮形式では、別の制約がパラメータ化されることがあります。

MULAW は 8 ビットの PCM エンコードで、これを使用するとサンプルの振幅が線形ではなく対数的に変調されます。その結果、uLaw が音声のダイナミック レンジを縮小し、音声が圧縮されます。uLaw は他の音声と比較して話声のエンコードが最適化されるようにするため導入された手法ですが、16 ビットの LINEAR16(非圧縮 PCM)のほうが 8 ビットの uLaw 圧縮音声よりはるかに高品質です。

AMRAMR_WB は、ソース音声サンプルに可変ビットレートを導入することで、エンコードされた音声サンプルを変調します。

Speech-to-Text API では一部のロッシー形式がサポートされていますが、ソースの音声を管理する場合はこの形式を避けるべきです。これらのデータをロッシー圧縮で削除しても、人間の耳に聞こえる音声には影響がほとんどありませんが、音声認識エンジンではこれらのデータが欠落していると精度が大幅に低下する場合があります。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。