paint-brush
Zoom M3 MicTrak File Recovery: Una aventura al món de la recuperació de dadesper@wasteofserver
114 lectures Nova Història

Zoom M3 MicTrak File Recovery: Una aventura al món de la recuperació de dades

per Frankie12m2025/03/02
Read on Terminal Reader

Massa Llarg; Per llegir

Una aventura al món de la recuperació de dades. Apreneu com funciona el programari de recuperació de dades i seguiu el procés de com es va crear l'eina de recuperació de fitxers Zoom M3 MicTrak.
featured image - Zoom M3 MicTrak File Recovery: Una aventura al món de la recuperació de dades
Frankie HackerNoon profile picture
0-item


Com una sèrie d'esdeveniments discrets condueixen a un viatge en profunditat a la codificació binària dels fitxers RIFF i aquesta eina de recuperació de dades


Si teniu pressa, aneu directament al repositori de GitHub .


Tot i que tinc la sort de desenvolupar programari per a empreses d'última generació, sempre he estat el "tipo de la impressora", una insígnia que porto amb orgull.

I potser aquesta és la raó per la qual, durant més d'un quart de segle, la gent ha aparegut amb suports d'emmagatzematge per salvar. No ho vaig fer mai professionalment, és una cosa que m'agrada i, la majoria de les vegades, puc ajudar.

El Procés

El meu enfocament principal és doble:

  • captura el que puguis del medi moribund

  • intentar recrear les dades


De vegades, només ajustant la tolerància de lectura, podeu capturar-ho tot des d'un disc rebutjat de Windows o Mac, ja que el sistema operatiu s'esgota més ràpidament del que pot respondre el mitjà moribund. Fa 7 mesos que tinc un disc enganxat a una caixa; 100% d'èxit de recuperació!


De vegades, tindreu trossos de dades que falten, però una de la taula d'assignació de fitxers/taula de fitxers mestra/superbloc del contenidor/arbre B de l'arrel encara hi és, de manera que la majoria de dades es poden recuperar tant amb noms de fitxer com amb la ubicació de l'arbre.


A l'extrem, no et quedes més que algunes de les dades en brut. Tot el que podeu fer és tallar-lo, bàsicament llegint cada byte del mitjà, identificant capçaleres conegudes com JPG ( FF D8 ) o MKV ( 1A 45 DF A3 ) i procedir a capturar totes les dades seqüencials fins al final del fitxer. Si, per qualsevol motiu, el fitxer està fragmentat, el gravat fallarà òbviament.

La trucada de Pierre Zago

Frankie, això no ha passat abans, en general sóc prudent... No sé què estava pensant: he formatat accidentalment una targeta SD amb àudio durant una sessió sencera. Pitjor, hi he desat alguns fitxers!


Pierre és un còmic increïblement talentós i un actor extraordinari. Tot i que la seva obra és polièdrica, es va fer molt conegut pels esbossos de carrer, alguns d'ells absolutament universals. Només cal que comproveu el següent on simplement diu "Perdoneu".

La senzillesa i l'encant còmic d'aquest esbós creen una obra d'art alegre però universalment atractiva.


Amb aquella senzilla acció, Pierre s'havia incorporat al club. Tothom fa malbé. Fins i tot Pixar . No us preocupeu, vaig dir, mentre agafeu la targeta, els continguts sobreescrits han desaparegut, però tenint en compte que és una targeta amb format de micròfon, fins i tot sense taules FAT, hauríem de ser capaços de tallar la major part del que hàgiu gravat ja que probablement les dades seran seqüencials.


No sabia que aquest seria un dels projectes de joguina més interessants en els quals he treballat des de fa temps. L'última vegada que em vaig divertir tant va ser reconstruint un maquinari RAID-0 que contenia els màsters d'un àlbum d' Os Azeitonas .

L'eco (Echo, Echo)...

Com era d'esperar, l'única manera de recuperar les dades era tallant-les de l'abocament d'imatges. Hi ha multitud d'eines per triar, Photorec (codi obert), Recuva (compte amb bundleware), ReclaiMe (de pagament), etc... tot i que sóc partidari de R-Studio (de pagament); els seus resultats superen constantment la competència.


En aquest cas, però, les coses no serien tan senzilles. Cada programari provat va poder extreure els fitxers wav , però hi havia alguna cosa bastant malament amb les dades, ja que tots tenien aquesta repetició, una mena de ressò.


Em sento una mica avorrit, així que els vaig obrir a Audacity per comprovar què estava passant. Podeu veure clarament un patró aquí:


Hi ha una mica de repetició cada ~ 0,7 segons


Tot i que els trossos tenen una forma d'ona força similar, no hi ha cap mena de correlació binària. A més, també hi havia alguna cosa tèrbol, cada fitxer wav tenia el que semblaven ser 2 capçaleres consecutives.


Tingueu en compte que, en aquest punt, el meu coneixement dels fitxers wav era que la capçalera és 52 49 46 46 . A part d'utilitzar un micròfon, no vaig preguntar a Pierre com havia gravat realment les dades. Tanmateix, quan vaig veure l'etiqueta "ZOOM M3" a la capçalera, vaig trucar a l'autoritat sobre tot el so.

Perfect Pitch, una mena de bruixeria

L'Ed ha estat en marcatge ràpid durant la major part d'aquesta vida. Tinc sort així. Més enllà de ser un compositor increïble, només escolteu l'impressionant Best Youth , també és una enciclopèdia sobre el so, viu i respirant, perfecta.


Zoom? Sí, sí. En tinc un. Enregistren tant en wav com en brut. Les dades estan alterades? Ah. Segur. Recuperar-se? Arxius retorçats? Serà una tasca impossible i, encara que no ho sigui, serà més fàcil tornar a gravar.


I allà em tenia. Sens dubte, seria més fàcil tornar a gravar, fins i tot Pierre en un moment va suggerir fer una veu en off, però on seria la diversió en això?

Zoom M3 MicTrak

El número màgic

Ni tan sols vaig apreciar el concepte d'ona raw fins que l'Ed ho va explicar, però ara sabia que el micròfon guarda dos fitxers simultanis, tot va quedar al seu lloc.


És habitual que les càmeres digitals emmagatzemin ambdós formats, però un micròfon és una bèstia diferent. No hi ha manera de determinar per endavant quant de temps gravarà l'usuari, cosa que no seria cap problema si es tractés d'un sol flux. Com que emmagatzema les dues pistes, hi ha una mica més de joc.


Ja veieu, tan bon punt premeu la gravació, el micròfon crea dos fitxers i neteja contínuament les dades capturades d'ambdós a la targeta. Això, es fa en trossos de dades. Un per al RAW, un altre per al WAV, repeteix.


Com que hem d'aïllar aquestes porcions de dades per desenredar-les, hem de conèixer-ne la mida exacta . I aquí rau el nostre número màgic !


El meu primer pensament va ser que els trossos podrien estar alineats amb la mida de la unitat d'assignació exFAT . En aquest cas, 128 KBytes . Anem a provar-ho.


La capçalera, indica clarament que es tracta d'un fitxer estèreo (2 canals), gravat a 32 bits per canal, mostrejat 48k vegades per segon. Si recordeu de la imatge de dalt, els trossos es repeteixen aproximadament 0,7 segons.


Anem a obtenir una aproximació aproximada dels bytes de trossos perquè coneixem l'estadi.


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

Estem analitzant fragments d'uns 268 KBytes.


I així, la idea que les dades es puguin dividir a exFAT AUS de 128 Kbytes es desmenteix a l'instant.


El següent pas obvi seria viatjar cap amunt a la base 2. Atès que 4096 és un bon equilibri per als buffers, avaluem a partir d'aquí:


 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 segons coincideix amb la nostra estimació de 0,7 segons tan perfectament que immediatament vaig saber que 262144 era la constant que buscàvem.

La Reconstrucció

Conceptualment, el problema es va resoldre. Ara, només era qüestió de construir l'eina. Per a això, caldria:


  • Desembolica els fitxers directament des de l'abocament d'imatges. Com que les peces recuperades per un altre programari de talla tindrien la meitat de la mida esperada (el tros de dades conté dos fitxers, de manera que en realitat és el doble de la mida que s'informa).


  • Apreneu a crear una capçalera RIFF .


  • Creeu una capçalera RIFF amb un tros BEXT per fer que els fitxers recuperats siguin compatibles amb el programari "M3 ZOOM Edit & Play".



I estic segur que allà et sentiràs més com a casa.


Tanmateix, pel bé de la indexació de Google, deixo aquí els mètodes que creen tant les capçaleres RIFF com BEXT, cosa que no he pogut trobar i que, malauradament, va fer que el procés trigués més temps del que m'agradaria admetre.


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


Com podeu veure, no es va fer gaire esforç al tros BEXT; Simplement el vaig crear per assegurar-me que "Zoom M3 Edit & Play" fos compatible.

L'eina

Espero que hagis tingut una lectura interessant. Vaig intentar aixecar el teló del procés de pensament mentre mantenia això atractiu. El codi real s'explica per si mateix i el trobareu aquí:


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


El repte no era només recuperar enregistraments perduts, sinó entendre per què fallaven les eines tradicionals i desenvolupar un mètode que funcionés.


Tot i que podria haver estat més fàcil tornar a gravar, l'emoció de resoldre el trencaclosques va fer que l'esforç valgués la pena. Al final, tenim una solució personalitzada que restaura amb èxit els enregistraments de Zoom M3 MicTrak.


Si alguna vegada us trobeu en una situació similar, amb sort, aquest desglossament us ajudi. I si no, bé, almenys heu de gaudir d'una petita aventura al món de la recuperació de dades.


Aquesta història es va publicar per primera vegada a https://wasteofserver.com/zoom-m3-mictrak-file-recovery/ . És possible que vulgueu consultar-lo allà per obtenir les últimes actualitzacions i comentaris.