Zoom M3 MicTrak File Recovery: avantura u svijet oporavka podataka

Kako niz neupadljivih događaja vodi do putovanja duboko u binarno kodiranje RIFF datoteka i ovog alata za oporavak podataka

Iako sam dovoljno sretan da razvijam softver za najsuvremenije tvrtke, uvijek sam bio "printer guy", značka koju nosim s ponosom.

I možda je to razlog zašto se više od četvrt stoljeća ljudi pojavljuju s medijima za pohranjivanje za spašavanje. Nikada se time nisam bavio profesionalno, to je samo nešto u čemu uživam i, češće nego ne, mogu pomoći.

Proces

Moj glavni pristup je dvostruk:

• uhvatite što možete iz umirućeg medija

• pokušati ponovno stvoriti podatke

  
  

Ponekad, samo podešavanjem tolerancije čitanja, možete snimiti sve s diska koji Windows ili Mac odbijaju, budući da OS ističe brže nego što umirući medij može odgovoriti. Imam disk zakačen na kutiju 7 mjeseci; 100% uspjeh oporavka!

Ponekad će vam nedostajati dijelovi podataka, ali jedna od tablica dodjele datoteka/glavne tablice datoteka/superbloka spremnika/korijenskog B-stabla je još uvijek tu, tako da se većina podataka može spasiti s nazivima datoteka i lokacijom u stablu.

U krajnjem slučaju, ne ostaje vam ništa osim nekih neobrađenih podataka. Sve što možete učiniti je izrezati ga - u biti čitati svaki bajt s medija, identificirati poznata zaglavlja kao što su JPG ( FF D8 ) ili MKV ( 1A 45 DF A3 ) i nastaviti sa snimanjem svih sekvencijalnih podataka do kraja datoteke. Ako je iz bilo kojeg razloga datoteka fragmentirana, rezbarenje očito neće uspjeti.

Poziv Pierrea Zagoa

Frankie, ovo se prije nije dogodilo, općenito sam oprezan... Ne znam što sam mislio - slučajno sam formatirao SD karticu sa zvukom za cijelu sesiju. Još gore, spremio sam neke datoteke na njega!

Pierre je nevjerojatno talentiran komičar i izvanredan glumac. Iako je njegov rad višestruk, postao je nadaleko poznat po uličnim skicama, od kojih su neki apsolutno univerzalni. Samo provjerite onaj ispod gdje jednostavno kaže "Oprostite."

Jednostavnost i komični šarm ovog skeča stvaraju bezbrižno, ali univerzalno privlačno umjetničko djelo.

Tom jednostavnom radnjom Pierre se pridružio klubu. Svi zabrljaju. Čak i Pixar . Ne brini, rekao sam, dok sam uzimao karticu, prepisani sadržaj je nestao, ali s obzirom na to da je to kartica formatirana za mikrofon, čak i bez FAT tablica, trebali bismo moći izrezati većinu onoga što ste snimili jer će podaci vjerojatno biti sekvencijalni.

Nisam ni znao da će ovo biti jedan od najzanimljivijih projekata igračaka na kojima sam radio u posljednje vrijeme. Posljednji put kad sam se ovako zabavio bilo je obnavljanje hardverskog RAID-0 koji je sadržavao mastere za album ' Os Azeitonas '.

Eho (Eho, Eho)...

Kao što se i očekivalo, jedini način za vraćanje podataka bio je njihovo izrezivanje iz dumpa slike. Možete birati između mnoštva alata, Photorec (otvorenog koda), Recuva (pazite na bundleware), ReclaiMe (plaća se), itd... iako sam sklon R-Studiu (plaća se); njihovi rezultati dosljedno nadmašuju konkurenciju.

U ovom slučaju, svejedno, stvari ne bi bile tako jednostavne. Svaki softver koji je pokušao uspio je izdvojiti wav datoteke, ali nešto nije bilo u redu s podacima jer su svi imali to ponavljanje, neku vrstu jeke.

Malo mi je tup sluh, pa sam ih otvorio u Audacityju da provjerim što se događa. Ovdje možete jasno vidjeti uzorak:

Iako dijelovi imaju prilično sličan valni oblik - ne postoji nikakva vrsta binarne korelacije. Osim toga, bilo je i nešto mutno, svaka wav datoteka imala je nešto što je izgledalo kao 2 uzastopna zaglavlja.

Imajte na umu da je u ovom trenutku moje znanje o wav datotekama bilo da je zaglavlje 52 49 46 46 . Osim što sam koristio mikrofon, nisam pitao Pierrea kako je zapravo zabilježio podatke. Međutim, kada sam vidio oznaku "ZOOM M3" u zaglavlju, nazvao sam autoritet za sve zvukom.

Savršen korak, neka vrsta čarobnjaštva

Ed je bio na brzom biranju veći dio svog života. Imam sreće takve. Osim što je nevjerojatan skladatelj - samo poslušajte Best Youth koji oduzima dah - on je također i savršen zvuk, živi i diše, enciklopedija zvuka.

Zum? Da, da. imam jednu. Snimaju i wav i raw. Podaci su iskrivljeni? Ah. Naravno. Oporaviti se? Iskrivljene datoteke? To će biti nemoguć zadatak, a čak i ako nije, bit će lakše samo ponovno snimiti.

I eto mene. Definitivno bi bilo lakše samo presnimiti, čak je i Pierre u jednom trenutku predložio da se napravi voice-over, ali gdje bi u tome bila zabava?

Čarobni broj

Nisam čak ni cijenio koncept raw vala dok ga Ed nije objasnio, ali sada sam znao da mikrofon sprema dvije istovremene datoteke, pa je sve sjelo na svoje mjesto.

Uobičajeno je da digitalni fotoaparati pohranjuju oba formata, ali mikrofon je drugačija zvijer. Ne postoji način da se unaprijed odredi koliko dugo će korisnik snimati, što ne bi bio problem da se radi o jednom streamu. Budući da pohranjuje obje pjesme, uključeno je dosta više igre.

Vidite, čim pritisnete snimanje, mikrofon stvara dvije datoteke i kontinuirano ispire snimljene podatke iz obje na karticu. To se radi u komadima podataka. Jedan za RAW, drugi za WAV, ponovite.

Budući da moramo izolirati te dijelove podataka kako bismo ih raspetljali, moramo znati njihovu točnu veličinu . I tu leži naš čarobni broj !

Moja prva pomisao bila je da bi dijelovi mogli biti usklađeni s veličinom exFAT jedinice za dodjelu. U ovom slučaju, 128 KBytes . Isprobajmo ga.

Zaglavlje jasno kaže da je ovo stereo datoteka (2 kanala), snimljena na 32 bita po kanalu, uzorkovana 48k puta u sekundi. Ako se sjećate s gornje slike, dijelovi se ponavljaju otprilike 0,7 sekundi.

Uzmimo grubu aproksimaciju bajtova komada tako da znamo što je u pitanju.

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

Tražimo dijelove od oko 268 KB.

I upravo tako, ideja da se podaci mogu razdijeliti na exFAT AUS od 128 Kbajta odmah je opovrgnuta.

Sljedeći očiti korak bio bi kretanje prema gore na bazi 2. S obzirom da je 4096 dobra ravnoteža za međuspremnike, procijenimo odatle:

 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 sekunde poklopilo se s našom procjenom od 0,7 sekundi tako savršeno da sam odmah znao da je 262144 konstanta koju tražimo.

Rekonstrukcija

Konceptualno, problem je riješen. Sada je bilo samo pitanje izrade alata. Za to bi bilo potrebno:

• Raspetljajte datoteke izravno iz dumpa slike. Budući da bi komadi koje je izvukao drugi softver za rezbarenje bili upola manji od očekivane veličine (dijel podataka sadrži dvije datoteke, tako da je zapravo dvostruko veći od prijavljenog).

• Naučite kako stvoriti RIFF zaglavlje .

• Napravite RIFF zaglavlje s BEXT dijelom kako bi obnovljene datoteke bile kompatibilne sa softverom "M3 ZOOM Edit & Play".

I prilično sam siguran da ćeš se tamo osjećati više kao kod kuće.

Međutim, zbog Googleovog indeksiranja, ovdje ostavljam metode koje stvaraju i RIFF i BEXT zaglavlja, nešto što nisam mogao pronaći, zbog čega je, nažalost, proces trajao dulje nego što bih želio priznati.

 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 ;"); } }

Kao što možete vidjeti, nije bilo puno truda uloženog u BEXT chunk; Jednostavno sam ga stvorio kako bih osigurao da je "Zoom M3 Edit & Play" kompatibilan.

Alat

Nadam se da ste čitali zanimljivo. Pokušao sam podići zavjesu s procesa razmišljanja, a da pritom ostane zanimljiv. Nadajmo se da je stvarni kod sam po sebi razumljiv i pronaći ćete ga ovdje:

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

Izazov nije bio samo vraćanje izgubljenih snimaka – radilo se o razumijevanju zašto tradicionalni alati nisu uspjeli i razvoju metode koja je funkcionirala.

Iako je možda bilo lakše ponovno snimiti, uzbuđenje rješavanja zagonetke učinilo je trud vrijednim truda. Na kraju smo dobili prilagođeno rješenje koje uspješno vraća Zoom M3 MicTrak snimke.

Ako se ikad nađete u sličnoj situaciji, nadamo se da će vam ovaj kvar pomoći. A ako ne, pa, barem možete uživati u maloj avanturi u svijetu oporavka podataka.