壊れたボイスレコーダーの録音を修復する

WAVファイルはRIFFコンテナです。オフセット0にASCIIバイト列RIFF、オフセット4に32ビットのリトルエンディアンのサイズ、オフセット8にフォームタイプWAVEで始まります。その後にチャンクが続き、それぞれが4バイトのタグと32ビットのサイズで構成されます。重要なのは2つ、fmt （末尾のスペースに注意——4文字のタグです）とdataです。fmt チャンクは、レコーダーがサンプルの解釈方法を記録する場所です。16ビットのオーディオフォーマットコード（1＝リニアPCM）、チャンネル数、Hz単位のサンプルレート、バイトレート、ブロックアライン、そしてビット/サンプルが入ります。これらを読めば、バイト列をどうデコードすればよいかが正確に分かります。逆に失えば、生のPCMはただの匿名の数値の羅列にすぎません。dataチャンクは音声そのものです。4バイトのタグ、32ビットの長さ、そしてインターリーブされたサンプルが続きます。

落とし穴は、最上位のRIFFサイズとdataチャンクの長さの両方が最後に書き込まれるという点です。録音中、機器はそのテイクがどれだけ長くなるかをまだ知らないため、サンプルをカードへ流し込み、停止したときにこの2つのサイズフィールドを後から書き換えます。MP3で保存するレコーダーは、その代わりに自己完結したMPEGオーディオフレームの連なりを書き込みます。各フレームは11ビットのフレーム同期——バイト0xFFに続いて、上位3ビットが1になっているバイト（0xFFE…）——で始まり、その手前にはしばしばID3v2タグが置かれます。いずれにせよ、実データはフレームごと、あるいはサンプルごとにカードへ書き込まれていきます。それらを束ねるフレーム構造だけが、いちばん最後に確定するのです。

サイズフィールドはStopのときに書き込まれるため、録音を壊す中断は、ファイルが閉じられるべきその瞬間にすべて集中します。

録音中にバッテリーが切れた。 その瞬間までのサンプルはカードに残っていますが、オフセット4のRIFFサイズとdataの長さはプレースホルダーのまま——多くの場合0か、ファイルが事前確保されたときの古い値——になっています。プレーヤーは長さフィールドを信用し、音声を0バイト（あるいは途方もなく誤った数のバイト）だけ読み込み、0:00や「破損」と表示します。

書き込み中にカードが抜かれた、あるいはレコーダーがリセットされた。 これはファイルを途中で切り詰めます。dataチャンクはレコーダーが意図した完全な長さを依然として宣言しているのに、ディスク上のファイルはそれより短いため、宣言されたサイズが実際に存在するバイト数より大きくなります。メディアプレーヤーは、そのファイルを拒否するか、実データの末尾まで再生してからエラーを出すかのどちらかです。

MP3のテイクが一度も確定されなかった。 フレームの連なりは無傷なのに、途中で切れた、あるいは壊れたID3タグや、先頭のゴミデータのせいで、デコーダーが最初の0xFF 0xEx同期を見失います——つまり録音はそこにあるのに、プレーヤーはどこから始まるのかを見つけられません。可変ビットレートのファイルでは、総フレーム数を保持するXing/Infoヘッダーが欠けていることがあり、そうなると再生できたとしてもシークバーと再生時間が誤って表示されます。

これらのいずれの場合も、音声サンプルそのものはすでにストレージへ書き込まれていました。生き残らなかったのは、ほんの一握りのサイズフィールドとフレーム構造のバイトだけです——それこそがまさに修復できるケースなのです。二度と戻らないのは、中断より後の音声です。そのサンプルは、そもそも一度も書き込まれていません。

WAVの場合、修復はあなたのタブ内で純粋なTypeScriptとして動くヘッダーの再構築です。まずfmt タグを走査し、そこからフォーマットを直接読み取ります。オーディオフォーマットコード、チャンネル数、サンプルレート、ビット/サンプルです。これらの中核となるパラメータがすべて妥当（どれもゼロでない）なら、ヘッダーが必要とする2つの導出フィールドを計算し直します——blockAlign = チャンネル数 × (ビット/サンプル ÷ 8)とbyteRate = サンプルレート × blockAlign——こうすることで、ディスク上の壊れているかもしれない値を信用せずに済みます。次にdataタグを見つけ、それが宣言する長さと、実際に存在するバイト数とを比べます。宣言されたサイズが残っているバイト数より大きいときは、そのファイルをtruncated（切り詰め）と判定し、生き残ったすべてのバイトを保持します。dataヘッダーがまったくない場合は、fmt より後ろのすべてをPCMとして扱います。最後に、サンプルデータをフレームの整数個ぶんに切りそろえ（pcm.length % blockAlignにあたる末尾のバイトを捨て）、復元したサンプルの前に、きれいで正規の44バイトのWAVヘッダー——RIFF、正しいサイズ、WAVE、16バイトのfmt チャンク、そして本当の長さを持つdata——を書き込みます。PCMはそのまま丸ごとコピーされるため、デコードも再エンコードも一切ありません。音声は、あなたが録音したものとビット単位でまったく同じです。

ツールは、何をしたかを短いレポートで伝えます。damageClassがheader（サイズだけが誤っていた——きれいな成功）、truncated-dataまたはno-data-header（末尾が欠けていた部分的な結果）といった値と、復元されたサンプルレート、チャンネル数、ビット/サンプル、PCMのバイト数が示されるので、結果を確かめられます。MP3の録音は、代わりに兄弟分のMP3ルートが処理します。先頭の壊れたID3タグやゴミデータを取り除き、最初の本物のフレームで再同期します——ある候補を受け入れるのは、そこから計算したフレーム長がちょうど別の有効な同期の上に着地したときだけで、これにより音声の内部で起きる誤検出をはねつけます——そして生き残ったフレームを無劣化で書き出します。この処理はどれもネットワークに触れません。ブラウザのネットワーク（Network）タブを開けば、録音が0バイトも送信されていないことを確認できます。

ヘッダーの再構築が届くのは、カードにたどり着いた音声だけです。fmt チャンクそのものが失われている場合、ツールは推測するのではなく正直に失敗します——フォーマットコード、チャンネル数、サンプルレート、ビット深度がなければ、そのバイト列が48 kHzの16ビットステレオなのか、96 kHzの24ビットモノラルなのかを知る術はなく、それらの数値をでっち上げればノイズを生むだけです。44バイト未満のファイル（有効なヘッダー1つ分よりも小さい）や、切りそろえるとサンプルフレームが整数個ぶんも残らないファイルは、同じ理由で復元不能と報告されます。中にデコードできるものが何もないからです。

また、不良のカードが物理的に上書きした、あるいはゼロとして返したものは復元できません——中断によって音声の領域が空白のまま残されたなら、そのサンプルはディスク上に存在せず、どんなヘッダーもそれを直せません。まずストレージのレベルで生のバイトを復元してから、ファイルを修復してください。暗号化された録音やDRMで包まれた録音（一部の企業向けの口述筆記機器や会議用機器は、ファイルを鍵で包みます）は、そのままのPCMやMPEGオーディオではないため、鍵がなければ再構築すべきヘッダーそのものがありません。そして、MP3のある領域を捨てざるを得なかった場所には、短い無音やプチッというノイズが残ることがあります——修復は良好なフレームを保持しますが、失われたミリ秒ぶんを合成することはありません。確実に取り戻せるのは、書き込まれたすべてのサンプルとすべてのフレームであり、しかもプレーヤーが開けるコンテナに収められた状態で返ります。