M4A を AAC に変換

これがこのペアが説明のために存在する区別であり、多くの変換ページが誤解している点です。AAC はコーデックで、1997 年に ISO/IEC 13818-7 として標準化され、MP3 の後継として設計されたもので、実際に音を圧縮しているのはこちらです。M4A はコンテナーです。2003 年に iTunes 4 以降 Apple が使ってきた MP4 ファイルで、通常 AAC の音声トラックを 1 本持ちます。ディスク上のほぼすべての .m4a とほぼすべての .aac は同じコーデックを持っており、2 つのファイルの違いはその周りに包まれているものすべてです。

MP4 のヘッダーは飾りではありません。音声の長さ、チャンネル数、プレイヤーが任意の秒数にシークできるよう各サンプルの開始位置、タイトルやアーティスト、カバー画像のためのメタデータブロックを記録しています。素の .aac ファイルには通常それが何もなく、以下の節はそれを手放すことで得るものと失うものについてです。

素の .aac ファイルは ADTS ストリームです。各フレームが 7 バイトのヘッダーでそのフレーム自身だけを説明する、途切れのないフレームの連続です。設計目標は放送で、受信機がどの瞬間に受信を始めても、フレームの境界を見つけてデコードを開始でき、先頭を一度も見る必要がないようになっています。

これが ADTS に 2 つの本物の性質を与えています。フレームの境界から始まるファイルのどんなバイト範囲も、それ自体で有効なファイルになります。これが HLS が音声を .aac のセグメントの連続として配信できる理由です。そして 2 つの ADTS ファイルは、ヘッダーを書き換えることなく単純に連結するだけでつなげられます。ストリーミングや組み込みシステムがこれを求めるのはこの性質のためで、その代わりにファイルレベルのヘッダーが提供するものすべてを手放しています。

このペアについてのよくある説明は、どちらのファイルも AAC を持っているのだから変換は単なる包み直し——MP4 からフレームを取り出し、それぞれを ADTS ヘッダーで包んで書き出すだけで、何も失われない——というものです。それは実在する技術で、土台となるライブラリはそれに対応しています。

この変換ツールはそれを使いません。圧縮されるすべての変換先に対してエンコーダーへビットレートが渡され、それによってライブラリのストリームコピーの近道が無効になり、音声はサンプルへデコードされて再び符号化されます。実務上の帰結は、すでに一度非可逆だった音声への 2 回目の非可逆な処理です。本物ではあるものの、妥当な設定ならたいてい聞こえず、無視できるほどでもありません。結果が重要なら「高画質」を選んでください。用意されている 3 つの帯域の中でこの経路が出せる最も高いビットレートを書き出します。ビット単位で正確な包み直しが本当に必要なら、ストリームをコピーできるコマンドラインツールが正しい道具です。そう伝えるほうが、できるふりをするより役に立ちます。

ファームウェアと組み込みデコーダーが主な場合です。フレームレベルの AAC デコーダーを持ち MP4 パーサーを持たないチップは、まさにこれを求めます。フレームを渡せば再生できます。DSP 評価ボード、車載や産業用の音声モジュール、多くのセットトップボックスや IP カメラのファームウェアはこの構造で作られています。

それ以外は取り込み処理と古い API です。一部のストリーミング取り込み経路はエレメンタリーストリームを受け取り、独自のパッケージングを行います。古い Android や Java の音声インターフェースは ADTS を直接読みます。エンコーダーのテストハーネスや適合性試験はフレームレベルで動くのが定義そのものです。これらのどれにも当てはまらないなら、すでに持っている M4A のほうが優れたファイルで、この変換は生活を悪化させるだけです。

3 つあり、それぞれすぐに目に見えます。長さが消えます。ADTS にはそれを記すフィールドがないので、プレイヤーはファイルサイズと最初のフレームのビットレートから推測し、エンコーダーの設定が変動していればそのたびに間違えます。サンプルテーブルが消えるので、シークはバイトオフセットを推測して次の同期ワードを探すことになり、それがスクラブが飛んだり進捗バーがずれたりする理由です。

そしてメタデータブロックが消え、カバー画像のための定められた場所もなくなります。代わりになるのは、先頭に取り付けられた ID3v2 ヘッダーです。MP3 が使うのと同じ仕組みですが、AAC の仕様の一部ではなく慣習です。デスクトップのプレイヤーはたいてい読めます。組み込みのデコーダーはしばしば読めず、中には ID3 のバイト列を壊れた音声として扱うものもあります。これが、まさに最初の 1 ファイルを実際の対象機器で試すべき理由です。

画質の設定は「小さいファイル」「バランス」「高画質」の 3 段階で、実際のビットレートはブラウザーが提供するエンコーダーライブラリの内部で解決されます。コード側では数値として持っていないため、このページでは具体的な kbps を挙げません。上位のいくつかの選択肢は用意されておらず、これはコーデックの制約ではなくエンコーダー側の経路の制約です。

このペアでは選択は簡単です。ほとんど常に「高画質」を選んでください。すでに一度圧縮された音声を再符号化しているので、2 回目の処理を聞こえなくする唯一の防御策は、エンコーダーに自分自身の処理をほとんど加えずに済むだけの余裕を与えることです。素のストリームを必要とする理由が容量を節約する理由であることはめったにありません。

レジストリは M4A のコーデックとして AAC と ALAC の両方を挙げており、iTunes で CD からリッピングされたファイルは Apple Lossless を持っていることがあります。ADTS は ALAC をまったく運べません。AAC のフレーム形式だからです。したがって、この変換に可逆なソースを保てる版はありません。

実際に起きるのは、黙ってトランスコードされるのではなく処理が止まることです。ALAC はこのデコード経路で使えるコーデックに含まれていないため、変換は「ファイルの中身を何も変換できませんでした」と報告します。容量を見れば事前にどちらの M4A かわかります。4 分の AAC は 3〜5 メガバイトですが、Apple Lossless は 20〜30 メガバイトです。ALAC だとわかったら、素の AAC ストリームはその行き先として間違っている、というのが正直な答えです。

ADTS のヘッダーはフレームごとにチャンネル構成とサンプリング周波数のインデックスを持つので、モノラルはモノラルのまま、ステレオはステレオのまま、元データのサンプルレートも——組み込み機器が特別に求める珍しい値も含めて——そのまま書かれます。

周波数のインデックスは任意の数値ではなく固定の表なので、機器がレートを指定してくる場合はこの制約に注意してください。標準的な値はカバーされていますが、その表にない特殊なレートは ADTS では表現できません。元データの構成がどうしても符号化できない場合、変換は失敗するのではなく 48,000 Hz の 2 チャンネルへフォールバックします。何かへまとめて書き込む前に、最初の出力を対象機器の期待と照らし合わせて確認してください。

このペアでは試験的な実行がもっとも確実に元を取れます。行き先がたいてい人ではなく機器だからです。1 ファイルを変換し、対象機器に入れて、3 つを確認してください。そもそも再生できるか、途中を飛ばさず最初のフレームから再生されるか、先頭の ID3 ヘッダーがデコーダーを混乱させないか。

それがうまくいけば、あとのバッチは簡単です。フォルダーを置いて ZIP を受け取ります。1 ファイルあたりの上限は 100 MB、1 バッチにつき 100 ファイルまでで、どの段階でもアップロードはありません。デコードは手元の機器のコーデックを使い、AAC のエンコーダーはタブの中で動作します。ブラウザーが持っていればネイティブに、Firefox のように AAC エンコーダーを持たない場合は WebAssembly パッケージとして。ネットワークタブを見れば、音声を運ぶものが一切送信されていないことを確認できます。