Zoom M3 MicTrak ファイルリカバリ: データリカバリの世界への冒険

一連の目立たない出来事が、RIFFファイルのバイナリエンコードとこのデータ回復ツールの奥深くへとつながる

私は最先端の企業向けにソフトウェアを開発できるほど幸運ですが、常に「プリンター担当者」であり、そのことを誇りに感じています。

そして、おそらくそれが、四半世紀以上もの間、人々がストレージ メディアを持ち寄って救出にやって来ている理由です。私はプロとしてそれをやったことはありませんが、単に楽しんでいるだけであり、多くの場合、私は手助けすることができます。

プロセス

私の主なアプローチは 2 つあります。

• 死にゆくメディアからできる限りのものを捉える

• データを再作成してみる

  
  

場合によっては、読み取り許容値を調整するだけで、Windows や Mac が拒否するディスクからすべてをキャプチャできることがあります。これは、OS のタイムアウトが、死にかけのメディアの応答よりも速いためです。私はディスクを 7 か月間ボックスに接続していましたが、100% の回復に成功しました。

場合によっては、データの一部が失われることがあります。ただし、ファイル アロケーション テーブル/マスター ファイル テーブル/コンテナ スーパーブロック/ルート B ツリーのいずれかがまだ残っているため、ファイル名とツリーの場所の両方を使用してほとんどのデータを復旧できます。

極端な場合、生データの一部しか残らないことになります。できるのは切り出すことだけです。つまり、メディアからすべてのバイトを読み取り、JPG ( FF D8 ) や MKV ( 1A 45 DF A3 ) などの既知のヘッダーを識別し、ファイルの最後まですべての連続データをキャプチャするだけです。何らかの理由でファイルが断片化されている場合、当然切り出すことは失敗します。

ピエール・ザーゴからの呼びかけ

フランキー、これは今までに起こったことがありません。私は普段は用心深いのですが... 何を考えていたのかわかりません。セッション全体のオーディオが入った SD カードを誤ってフォーマットしてしまいました。さらに悪いことに、そこにいくつかのファイルを保存してしまいました。

ピエールは、信じられないほど才能のあるコメディアンであり、並外れた俳優です。彼の仕事は多岐にわたりますが、ストリートスケッチで広く知られるようになりました。その中には、まったく普遍的なものもあります。彼がただ「すみません」と言うだけの、下のスケッチを見てください。

このスケッチのシンプルさとコメディー的な魅力は、軽快でありながら普遍的な魅力を持つ芸術作品を生み出しています。

その簡単なアクションで、ピエールはクラブに加わりました。誰でも失敗します。ピクサーでさえも。心配しないでください、と私はカードを取りながら言いました。上書きされたコンテンツは消えていますが、マイクフォーマットのカードなので、FATテーブルがなくても、データはおそらく連続しているため、記録したもののほとんどを切り出すことができるはずです。

当時は知る由もなかったが、これが私が最近取り組んだ最も興味深いおもちゃのプロジェクトの 1 つとなるだろう。これほど楽しかったのは、「 Os Azeitonas 」のアルバムのマスターを含むハードウェア RAID-0 を再構築したときが最後だった。

エコー（エコー、エコー）...

予想通り、データを復元する唯一の方法は、イメージ ダンプからデータを切り出すことでした。Photorec (オープン ソース)、 Recuva (バンドル ウェアに注意)、 ReclaiMe (有料) など、選択できるツールは多数ありますが、私はR-Studio (有料) を好んで使用しています。その結果は、常に競合製品よりも優れています。

しかし、この例では、物事はそれほど単純ではありません。試したすべてのソフトウェアでwavファイルを抽出できましたが、データに何か問題があり、すべてに繰り返し、一種のエコーがありました。

私は聴覚が少し鈍いので、何が起こっているのかを確認するためにAudacityで開いてみました。ここではパターンがはっきりとわかります。

チャンクの波形は非常に似ていますが、バイナリ相関はまったくありません。また、不明瞭な点もあり、すべてのwavファイルに 2 つの連続したヘッダーがあるように見えます。

念のため言っておきますが、この時点では、 wavファイルに関する私の知識は、ヘッダーが52 49 46 46であるということでした。マイクを使用したこと以外、実際にどのようにデータを録音したかについては、ピエールに質問しませんでした。しかし、ヘッダーに「ZOOM M3」タグがあるのを見て、私は音に関するあらゆることの権威に電話しました。

絶対音感、一種の魔法

エドは、この人生の大半をスピードダイヤルに登録してきました。私はその点で幸運です。息を呑むようなベストユースを聴いていただければわかるように、彼は信じられないほどの作曲家であるだけでなく、音の完璧な、生き生きとした、音に関する百科事典でもあります。

Zoom? はい、あります。持っています。wav と raw の両方を録音できます。データが壊れている? ああ、もちろんです。回復? ファイルが壊れている? それは不可能な作業になりますし、たとえ不可能でなかったとしても、再録音する方が簡単です。

そして、私はそこにいました。単に再録音する方が間違いなく簡単です。ピエールは一度、ナレーションをすることを提案しましたが、それでは面白くないですよね。

魔法の数字

Ed が説明するまで、私はraw波形の概念を理解していませんでした。しかし、マイクが 2 つのファイルを同時に保存することを知った今、すべてがうまくいきました。

デジタルカメラでは両方のフォーマットを保存するのが一般的ですが、マイクの場合は事情が異なります。ユーザーが録音する時間を事前に決定する方法はありません。これは、単一のストリームであれば問題になりません。両方のトラックを保存するため、かなりの処理が必要になります。

録音ボタンを押すとすぐに、マイクは 2 つのファイルを作成し、両方からキャプチャしたデータをカードに連続的にフラッシュします。これは、データのチャンクで行われます。1 つは RAW 用、もう 1 つは WAV 用、という繰り返しです。

それらを解きほぐすには、データのスライスを分離する必要があるため、その正確なサイズを知る必要があります。そして、そこに魔法の数字があります。

最初に考えたのは、チャンクがexFAT割り当て単位のサイズに揃っているのではないかということでした。この場合、 128 KBytes 。テストしてみましょう。

ヘッダーには、これがステレオ ファイル (2 チャンネル) であり、チャンネルあたり 32 ビットで録音され、1 秒あたり 48k 回サンプリングされていることが明記されています。上の画像を覚えているなら、チャンクは約 0.7 秒ごとに繰り返されます。

大まかな範囲を把握するために、チャンク バイトの大まかな概算を取得してみましょう。

 1 second of data = 2 channels * 32 bits * 48000 samples 1 second of data = 384000 bytes 0.7 seconds ~ 268800 bytes

約 268 KB のチャンクを調べています。

そして、このようにして、データが 128 KB の exFAT AUS にチャンク化される可能性があるという考えは即座に反証されます。

次の明らかなステップは、基数 2 で上方向に移動することです。4096 がバッファーの適切なバランスであることを考えると、そこから評価してみましょう。

 4096 * 32 = 131072 (falls short by about 1/2) 4096 * 64 = 262144 (is in the ballpark of what we're expecting) 262144/384000 ~ 0.682 seconds of data

0.682 秒は私たちの推定値 0.7 秒と完全に一致したので、 262144 が私たちが求めていた定数であることがすぐにわかりました。

復興

概念的には、問題は解決しました。あとはツールを構築するだけです。そのためには、次のことが必要です。

• イメージ ダンプから直接ファイルを解凍します。他のカービング ソフトウェアによって復元された断片は、予想されるサイズの半分になります (データ チャンクには 2 つのファイルが含まれているため、実際には報告されたサイズの 2 倍になります)。

• RIFF ヘッダーを作成する方法を学びます。

• 復元したファイルを「M3 ZOOM Edit & Play」ソフトウェアと互換性のあるものにするために、BEXT チャンクを含む RIFF ヘッダーを作成します。

そして、きっとそこではもっとくつろげると思います。

ただし、Google のインデックス作成のために、RIFF ヘッダーと BEXT ヘッダーの両方を作成する方法をここに残しておきます。この方法は見つけられなかったため、残念ながら、このプロセスには思ったよりも長い時間がかかりました。

 public class RiffFile { /** * Creates a RIFF header with BEXT and fmt chunks * * @param sampleRate the sample rate of the audio (8000Hz, 44100Hz, 48000Hz, etc) times per second the audio is sampled * @param bitsPerSample the bits per sample (8bits, 16bits, 32bits, etc) * @param channels the number of channels (1 mono, 2 stereo, etc) * @param audioDataSize the size of the audio data in bytes * @return the RIFF header * @throws IOException if an I/O error occurs */ public static byte[] createRiffHeader(int sampleRate, short bitsPerSample, short channels, int audioDataSize) throws IOException { // calculate the byte rate, block align and file size int byteRate = sampleRate * channels * bitsPerSample / 8; short blockAlign = (short) (bitsPerSample * channels / 8); // stream that will carry the new RIFF file ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream(); DataOutputStream out = new DataOutputStream(byteArrayOutputStream); // riff header out.writeBytes("RIFF"); out.writeInt(Integer.reverseBytes(0)); out.writeBytes("WAVE"); // 9-12 Format always WAVE // bext chunk writeBextChunk(out); // fmt chunk out.writeBytes("fmt "); // 13-16 chunkID is "fmt " with trailing whitespace out.writeInt(Integer.reverseBytes(16)); // 17-20 size of this chunk, is 16 byts out.writeShort(Short.reverseBytes((short) 3)); // 21-22 (2 bytes) audioFormat (1 PCM integer, 3 IEEE 754 float) out.writeShort(Short.reverseBytes(channels)); // 23-24 (2 bytes) numChannels (1 mono, 2 stereo, 4, etc) out.writeInt(Integer.reverseBytes(sampleRate)); // 25-28 (4 bytes) sampleRate (8000, 44100, 48000, etc) out.writeInt(Integer.reverseBytes(byteRate)); // 29-32 (4 bytes) byteRate (sampleRate * numChannels * bitsPerSample/8) out.writeShort(Short.reverseBytes(blockAlign)); // 33-34 (2 bytes) blockAlign (numChannels * bitsPerSample/8) out.writeShort(Short.reverseBytes(bitsPerSample)); // 35-36 (2 bytes) bitsPerSample (8bits, 16bits, 32bits, etc) // data chunk out.writeBytes("data"); // 37-40 chunkID ID is "data" out.writeInt(Integer.reverseBytes(audioDataSize)); // 41-44 size of this chunk varies out.close(); // write the full size of the file on the 4-8 bytes byte[] outArr = byteArrayOutputStream.toByteArray(); int size = outArr.length - 8; ByteBuffer.wrap(outArr, 4, 4).order(ByteOrder.LITTLE_ENDIAN).putInt(size); return outArr; } private static void writeBextChunk(DataOutputStream out) throws IOException { // bext chunk out.writeBytes("bext"); out.writeInt(Integer.reverseBytes(256 + 32 + 32 + 10 + 8 + 8 + 8 + 2 + 180 + 4 + 4 + 4 + 4 + 4 + 180)); // bext chunk size (fixed size for BWF) // description 256 bytes writeToArray(out, 256, ""); // 256 bytes description writeToArray(out, 32, "ZOOM M3"); // 32 bytes originator writeToArray(out, 32, ""); // 32 bytes originator reference writeToArray(out, 10, "2023-10-01"); // 10 bytes origination date writeToArray(out, 8, "12:00:00"); // 8 bytes origination time writeToArray(out, 8, "12:00:00"); // 8 bytes time reference out.writeLong(Long.reverseBytes(0L)); // 8 bytes time reference out.writeShort(Short.reverseBytes((short) 0)); // 2 bytes version out.write(new byte[180]); // 180 bytes UMID out.writeFloat(0.0f); // 4 bytes loudness value out.writeFloat(0.0f); // 4 bytes loudness range out.writeFloat(0.0f); // 4 bytes max true peak level out.writeFloat(0.0f); // 4 bytes max momentary loudness out.writeFloat(0.0f); // 4 bytes max short term loudness // zoom m3 needs this bit to allow file to be read from "zoom m3 edit & play" writeToArray(out, 180, "A=PCM,F=48000,W=32,M=stereo,T=M3;VERSION=1.00;MSRAW=ON ;"); } }

ご覧のとおり、BEXT チャンクにはあまり労力がかかっていません。単に「Zoom M3 Edit & Play」の互換性を確保するために作成しただけです。

ツール

興味深い記事だったと思います。読者の興味を引きつつ、思考過程を明かそうと努めました。実際のコードは、おそらく説明不要でしょう。以下でご覧いただけます。

https://github.com/wasteofserver/zoom_m3_mic_wav_data_recover/

課題は、失われた録音を回復することだけではありません。従来のツールが失敗した理由を理解し、機能する方法を開発することでした。

再録音する方が簡単だったかもしれませんが、パズルを解くスリルは努力する価値がありました。最終的に、Zoom M3 MicTrak 録音を正常に復元するカスタム構築ソリューションを手に入れました。

同じような状況に陥った場合は、この説明が役に立つことを願います。役に立たない場合でも、少なくともデータ復旧の世界へのちょっとした冒険を楽しむことができました。