OPUS を AAC に変換

このページが書き出すファイルは Audio Data Transport Stream の形式です。AAC のフレームが次々と並び、それぞれがサンプルレートやチャンネル構成、プロファイルを繰り返す短いヘッダーを持ち、それらを包むものは何もありません。索引も長さのフィールドもメタデータの領域もありません。もう一方の「AAC」と呼ばれるファイルは M4A で、同じ符号化された音声を、その 3 つすべてを運べる MP4 コンテナーに収めたものです。

どちらが必要かは好みの問題ではなく、言葉だけから推測することもできません。ドキュメントが ADTS やエレメンタリーストリーム、.aac という拡張子を名指しているなら、このページが正解です。ドキュメントが単に「AAC 音声」と言い、長さやタイトル、シークバーを期待しているなら、M4A が正解です。間違ったほうを送ることが、この変換でもっともよくある失敗で、たいていはっきりした拒否ではなく、プレイヤーが間違った長さを報告するという形で表面化します。

ADTS は、ストリームがどのフレームからでも始められるように存在します。この性質こそが、セグメンター、放送自動化システム、アナウンスや IVR のプレイヤー、組み込みパーサーが前提にしているものです。音声を断片に切り、途中から再生し始め、参照するコンテナーを持たないデコーダーへ断片を渡します。すべてのフレームにヘッダーがあるからこそ、それが安全にできます。

同じ設計が結合も支えます。サンプルレートとチャンネル数が一致する 2 つの ADTS ファイルは、バイト単位で連結でき、結果は再符号化も追加の劣化もなく 1 つの連続したファイルとして再生されます。プロンプトシステムはまさにこの方法で文章を断片から組み立てます。選べるなら素のストリームを優先する最大の理由であり、それに頼る前に断片が本当にパラメーターを共有しているか確認する価値があります。

Opus は固定の 48,000 Hz のクロックで動作します。デコーダーはファイルが何から符号化されたかにかかわらずそのレートを報告するので、ここで作られる AAC は、元データが 16 kHz の音声録音であっても 48 kHz になります。このページはリサンプリングを行いません。これは意図的なことです。リサンプリングは聞こえる結果を伴う判断であり、それを確認できるツールの中で行うべきものだからです。

これがもっとも重要になるのは、このペアがよく使われる方向です。電話系や IVR、アナウンスシステムはよく 8,000 Hz や 16,000 Hz を指定します。伝送路がそれしか運べないからです。48 kHz のファイルは拒否されるか、取り込み時にリサンプリングされます。変換したあと自分でエディターやバッチツールで行っておけば、本番の回線でプロンプトの音がおかしいと気づくのではなく、事前に確認できます。

この立場に Opus が現れる理由は 3 つあります。メッセージングプラットフォームや音声ボットがそれで録音するのは、リアルタイム音声のために設計され、WebRTC が必須にしているからです。ダウンロードツールがそれを作るのは、再符号化なしで手に入る最良のストリームだからです。そして音声合成やテキスト読み上げサービスも、同じ帯域幅の理由で増えつつあります。

元のビットレートが、そのあとのすべての上限を決めます。十分に高いビットレートで合成されたプロンプトは、「高画質」の AAC に変換すれば誰も文句を言わない仕上がりになります。電話用に低いビットレートで録られたボイスメモは、すでにコーデックの下限にあり、このページのどの帯域でも改善しません。最高設定は 2 回目のエンコーダーが損傷を加えるのを止めるだけです。

画質の設定は「小さいファイル」「バランス」「高画質」の 3 段階で、実際のビットレートはブラウザーのエンコーダーライブラリの内部で解決されます。コードの側では数値を持っていないため、このページでは具体的な kbps を挙げません。この経路には上限があり、AAC の仕様が名指すような最高水準のビットレートは選べないことがあります。これはコーデックではなくエンコーダー側の経路の制約です。

AAC 向けに書かれた要件は、たいてい画質目標というより伝送路が課す上限です。チャンネルが狭い、何年も前に予算が決まった、といった事情で低い値が指定されていることがあります。名指された水準と同じか、少し下の帯域を選んでください。何も指定されていない場合、「高画質」が 2 世代目の符号化にとって正しい既定値です。余裕がある理由は、エンコーダー自身がほとんど何も付け加えずに済むようにするためです。

システム向けに録音されるスピーチは通常もとからモノラルで、そのままであるべきです。同一の 2 チャンネルは、同じ情報を 2 倍のビットレートで伝えるだけで、モノラルを前提とするプロンプトプレイヤーはステレオファイルを予測できない形で拒否したり畳み込んだりすることがあります。ここではモノラルのファイルをステレオへ昇格させることはないので、モノラルの Opus はモノラルの AAC を生みます。

ADTS のヘッダーはすべてのフレームでチャンネル構成を記録しており、これが上で触れた連結の技を安全にしている理由です。モノラルの断片が食い違いに気づかれないままステレオの断片と結合されることはありません。バッチに両方が混在しているなら、その不整合はフレームのストリームの中よりソースのディレクトリの中で見つけるほうがずっと簡単なので、変換の前に解消しておく価値があります。

ADTS ファイルのどこにも長さは記録されていません。長さを必要とするソフトは、すべてのフレームを走査するか、ファイルサイズを想定ビットレートで割るかして推測しますが、可変レートの素材ではその計算が破綻します。これが、プレイヤーが .aac ファイルの長さを間違って報告したり、シークをさせてくれなかったりする理由です。

プロンプトシステムにとってはこれは無関係です。プラットフォームは取り込み時に音声を計測し、自分のデータベースにその数値を保存するからです。人間が進捗バーを見る場面では、これは目に見える欠陥で、素のストリームが正しい納品物ではなかったもっともはっきりした兆候です。M4A はヘッダーに長さを持っており、この問題がありません。

Opus は Vorbis コメント——大文字のキーとテキストの値からなるオープンな一覧——を持つ Ogg コンテナーの中で運ばれ、合成されたプロンプトや書き出された録音には、そこに有用な説明が入っていることがよくあります。ADTS にはメタデータの領域がまったくないので、すべてのフィールドが失われ、結果は音だけを運びます。

この文脈ではそれはたいてい正しいことです。プロンプトはパスとプラットフォーム自身の記録によって識別され、埋め込みタグによってではないからです。説明が重要な場合——ライセンス、帰属表示、プロンプト集のバージョン番号など——変換前にそれをファイル名かマニフェストにコピーしておくか、それらすべてのためのアトムを持ち同じ音声を運べる M4A を変換先にしてください。

ファイルは 1 つあたり 100 MB が上限です。Opus にとってはこれは何時間分ものスピーチに相当します。100 個までまとめて置いて ZIP として受け取れる仕組みは、プロンプト集やボットの録音が実際に届く形に合っています。作業は帯域ではなく手元の機械のプロセッサー時間なので、大きなバッチは始めて放っておく価値があります。

WebRTC が必須にしたため、Opus はすべてのブラウザーでネイティブにデコードできます。Chrome、Edge、Safari はネイティブに AAC も符号化できますが、Firefox はできないため、そこでは WebAssembly のエンコーダーが 1 回だけ取得されます。ネットワークを越えるのはそのパッケージだけです。録音された通話や顧客向けのプロンプト、バッチの中のその他すべては手元の機械に留まり、変換の実行中に開発者ツールで確認できます。