MP3 が再生できない

MP3 は 1 つのかたまりではありません。小さなMPEG オーディオフレームが連なったもので、各フレームはおよそ 26 ミリ秒ぶんの音を持ちます。すべてのフレームは 4 バイトのヘッダーで始まります。バイト 0 は 0xFF で、バイト 1 の上位 3 ビットが 11 ビットのフレーム同期(0xFFE…)を完成させます。ヘッダーの残りには、MPEG のバージョン(MPEG-1、MPEG-2、または MPEG-2.5)、レイヤー(ほぼ必ず Layer III)、ビットレートインデックス、サンプルレートインデックス、そしてパディングビットが詰め込まれています。デコーダーはビットレートとサンプルレートからフレームのバイト長を計算し — Layer III では floor(144 × bitrate ÷ sample_rate) + padding です — それを使って次の同期へ直接跳びます。仕様上、いくつかのビットの組み合わせは不正です。予約済みのバージョン、予約済みのレイヤー、0(フリー)または 15(不正)のビットレートインデックス、3 のサンプルレートインデックスなどです。デコーダーがたどり着いたヘッダーがこれらのいずれかにデコードされる場合、そこは本物のフレーム境界ではなく、ストリームは行き詰まります。

この跳躍を狂わせる原因は、主に 2 つあります。1 つ目は、ファイルのいちばん先頭にある壊れたID3v2 タグです。ID3v2 タグは、ASCII のバイト列 ID3(0x49 0x44 0x33)、10 バイトのヘッダー、そして 4 バイトに分散された syncsafe な 28 ビットのサイズ値(各バイトは下位 7 ビットだけを持ち寄る)で始まります。このサイズが間違っていると — 大きすぎる、あるいは途中で切れた埋め込みアルバムアートがタグを壊してしまった場合によく起こります — プレーヤーは本物の音声の開始位置を通り越してシークするか、タグを音として解釈しようとしてしまいます。2 つ目は先頭のゴミデータです。ダウンロードの途中終了、誤って .mp3 という名前で保存された HTTP エラーページ、あるいは最初の同期より前にバイトを付け足してしまうバイト順の不具合などです。ID3 タグがまったくないファイルは、単なる「むき出しの MPEG オーディオフレーム同期」でしかなく — これはそもそも一部のプレーヤーが MP3 として認識してくれない弱い手がかりです。

症状がこれほど多様なのはそのためです。ffmpeg は Failed to find two consecutive MPEG audio frames(意味は「連続する 2 つの MPEG オーディオフレームを見つけられませんでした」)や Header missing(「ヘッダーがありません」)を報告します。mpg123 は Illegal Audio-MPEG-Header 0x00000000(「不正な MPEG オーディオヘッダー」)を表示し、フレームのパラメーターがファイルの途中で変化すると Frankenstein stream(つぎはぎだらけのストリーム)について警告します。ブラウザーの <audio> 要素は DEMUXER_ERROR_COULD_NOT_OPEN を投げます。これらはすべて同じことを述べています。フレームのつながりが壊れているのであって、音楽そのものが消えたわけではない、ということです。

この修復は構造的な再同期であり、あなたのタブの中で純粋な TypeScript として動きます。まず、先頭に ID3v2 タグがあれば、その syncsafe なサイズ値(フッターフラグが立っている場合は 10 バイトのフッターも加える)からその大きさを測り、その先へ進みます。次に、本物のヘッダーとして解釈できるバイトパターンを探して前方へスキャンします — 0xFF、0xE0 の同期ビット、予約済みでないバージョンとレイヤー、そしてどちらも範囲内に収まるビットレートインデックスとサンプルレートインデックスです。ここで重要なのは、単独の 0xFF 0xEx は音声データの中にたまたま現れることがある、という点です。そのため、計算したフレーム長のぶんだけ進んだ読み取り位置がちょうど別の有効な同期(あるいはファイルの末尾)に着地したときにのみ、候補を採用します。この 2 フレーム確認こそが、出力にノイズを書き込む代わりに、誤検出をはねのける仕組みです。

そこからはフレームを 1 つずつたどり、確認できた各フレームをそのまま出力へコピーしていきます。最初の正常なフレームより前のバイトは先頭のゴミデータとして数えられ、破棄されます。途中で解釈に失敗した区間は破損したフレーム領域として扱われ、読み取り位置が次のきれいな同期でつながりを拾い直せるように読み飛ばされます。保持される各フレームはバイト単位でそのままコピーされるため、再エンコードは行われず、品質の劣化もありません — 生き残った音声は、あなたが録音したものそのままです。ツールは自分が行ったことを報告します。見つかったフレーム数と保持したフレーム数、先頭のゴミデータを何バイト取り除いたか、そして損傷の分類として clean(問題なく成功)または resynced(ゴミデータや破損フレームを破棄した部分的な成功)を示します。

知っておく価値のある細かい点が 2 つあります。多くの MP3 は、最初のフレームの中に Xing/Info(または VBRI)ヘッダーを持っています。これは可変ビットレートのファイル向けに、総フレーム数とシークテーブルを格納しています。このヘッダー自体が有効な MPEG フレームであるため、それが生き残っていれば再同期はそれを保持します — そして生き残っていなければ、プレーヤーはビットレートから長さを推定する方式にフォールバックします(ffmpeg は文字どおり Estimating duration from bitrate, this may be inaccurate(「ビットレートから再生時間を推定します。正確でない可能性があります」)と警告します)。末尾の ID3v1 タグ — ファイルの最後にある、TAG で始まる固定 128 バイト — はフレームではないため、デコーダーを混乱させる代わりに、単に末尾から切り落とされます。これらのどの処理もネットワークには触れません。「ネットワーク(Network)」タブを開けば、ファイルが 0 バイトも送信されていないことを確認できます。

再同期が役に立つのは、ファイルのどこかに本物の MPEG フレームが生き残っている場合だけです。スキャンでデコード可能なフレームが 1 つも見つからなければ、ツールは、動くふりをする空のファイルを渡す代わりに、処理を止めて正直にそう伝えます(no-frames という結果です)。そうなる場合、たいていはそのバイト列がそもそも MPEG オーディオではありません。.mp3 にリネームされた AAC/.m4a、WMA、あるいは Opus ファイル、または音声の拡張子が付いた保存済みの Web ページやダウンロードの断片などです。食いつくべき 0xFFE のフレームヘッダーが存在せず、どんな再同期もそれを作り出すことはできません。

また、故障しかけたドライブや不良のカードによって物理的に上書きされた、あるいはゼロとして読み出される音声を復元することもできません — それらのフレームはディスク上に存在しないので、まずストレージのレベルで生のバイトを復元し、それからファイルを修復してください。DRM で保護されたトラック(Apple の古い .m4p や保護された AAC)は MP3 ではなく、デコードには鍵が必要です。このツールはそこには手を付けません。そして、破損した領域を破棄せざるを得なかった箇所では、そこに短い無音やプチッというノイズが残ることがあります — 修復は正常なフレームを無劣化でコピーしますが、失われたミリ秒ぶんを合成して作り出すことはしません。確実に取り戻せるのは、無傷だったすべてのフレームが、順序どおりに、プレーヤーが実際に開けるコンテナーに収まった状態です。