Cómo una serie de eventos discretos conducen a un viaje a las profundidades de la codificación binaria de los archivos RIFF y a esta herramienta de recuperación de datos  Si tienes prisa, dirígete   . directamente al repositorio de GitHub  Si bien tengo la suerte de desarrollar software para empresas de última generación, siempre he sido el "chico de la impresora", una insignia que llevo con orgullo.  Y tal vez esa sea la razón por la que, durante más de un cuarto de siglo, la gente ha venido a rescatar medios de almacenamiento. Nunca lo hice profesionalmente, es simplemente algo que disfruto y, la mayoría de las veces, puedo ayudar.  El proceso  Mi enfoque principal es doble:  Captura lo que puedas del medio moribundo.  Intente recrear los datos  A veces, con solo ajustar la tolerancia de lectura, se puede capturar todo lo que contiene un disco que Windows o Mac rechazan, ya que el sistema operativo se agota más rápido de lo que puede responder el medio que está muriendo. Tuve un disco conectado a una caja durante 7 meses; ¡recuperación 100 % exitosa!  A veces, faltarán fragmentos de datos, pero uno de los superbloques de la tabla de asignación de archivos/tabla maestra de archivos/contenedor/árbol B raíz aún estará allí, por lo que la mayoría de los datos se pueden recuperar con los nombres de archivo y la ubicación del árbol.  En el extremo, no te queda nada más que algunos de los datos sin procesar. Todo lo que puedes hacer es extraerlos, básicamente leer cada byte del medio, identificar encabezados conocidos como JPG (   ) o MKV (   ) y proceder a capturar todos los datos secuenciales hasta el final del archivo. Si por alguna razón, el archivo está fragmentado, la extracción obviamente fallará. FF D8 1A 45 DF A3  El llamado de Pierre Zago  Frankie, esto nunca me había pasado antes, por lo general soy cauteloso... No sé en qué estaba pensando: accidentalmente formateé una tarjeta SD con audio para una sesión completa. ¡Peor aún, guardé algunos archivos en ella!  Pierre es un comediante increíblemente talentoso y un actor extraordinario. Si bien su trabajo es multifacético, se hizo muy conocido por sus sketches callejeros, algunos de ellos absolutamente universales. Solo mira el que aparece a continuación, donde simplemente dice "Disculpe".   https://www.youtube.com/watch?v=JC-yra6dtzw&embedable=true  La sencillez y el encanto cómico de este boceto crean una obra de arte alegre pero universalmente atractiva.  Con esa simple acción, Pierre se había unido al club. Todo el mundo comete errores.   . No te preocupes, dije mientras tomaba la tarjeta, el contenido sobrescrito desapareció, pero dado que es una tarjeta con formato de micrófono, incluso sin tablas FAT, deberíamos poder extraer la mayor parte de lo que hayas grabado, ya que los datos probablemente serán secuenciales. Hasta Pixar  No sabía que este sería uno de los proyectos de juguetes más interesantes en los que he trabajado en mucho tiempo. La última vez que me divertí tanto fue reconstruyendo un RAID-0 de hardware que contenía los masters de un álbum de '   '. Os Azeitonas  El Eco (Eco, Eco)...  Como era de esperar, la única forma de recuperar los datos era extraerlos del volcado de imagen. Hay una multitud de herramientas para elegir:   (código abierto),   (cuidado con los paquetes de software),   (pago), etc., aunque me decanto por   (pago); sus resultados superan constantemente a los de la competencia. Photorec Recuva ReclaiMe R-Studio  En este caso, sin embargo, las cosas no serían tan sencillas. Todos los programas que probamos lograron extraer los archivos   , pero había algo bastante erróneo con los datos, ya que todos tenían una repetición, una especie de eco. wav  Soy un poco sordo, así que los abrí en   para comprobar qué estaba pasando. Aquí se puede ver claramente un patrón:  Audacity  Si bien los fragmentos tienen una forma de onda bastante similar, no hay ningún tipo de correlación binaria. Además, también había algo turbio: cada archivo   tenía lo que parecían ser dos encabezados consecutivos.  wav  Tenga en cuenta que, en ese momento, mi conocimiento sobre los archivos   era que el encabezado es   Aparte de usar un micrófono, no le pregunté a Pierre cómo había grabado realmente los datos. Sin embargo, cuando vi la etiqueta "ZOOM M3" en el encabezado, llamé a la autoridad en todo lo relacionado con el sonido. wav 52 49 46 46  El tono perfecto, una especie de magia  Ed ha estado en el marcado rápido durante la mayor parte de su vida. Soy afortunado en ese sentido. Además de ser un compositor increíble (solo escuchen el impresionante   ), también es una enciclopedia del sonido perfecta, viva y palpitante. Best Youth   https://www.youtube.com/watch?v=ZGtOOPJKfYA&embedable=true  ¿Zoom? Sí, sí. Tengo uno. Graban tanto en formato wav como en formato raw. ¿Los datos están alterados? Ah, claro. ¿Recuperar? ¿Archivos alterados? Será una tarea imposible y, aunque no lo sea, será más fácil simplemente volver a grabar.  Y ahí estaba yo. Definitivamente sería más fácil volver a grabar, incluso Pierre en un momento sugirió hacer una voz en off, pero ¿dónde estaría la diversión en eso?   El número mágico  Ni siquiera apreciaba el concepto de una onda   hasta que Ed lo explicó, pero ahora que sabía que el micrófono guarda dos archivos simultáneos, todo encajó. raw  Es habitual que las cámaras digitales almacenen ambos formatos, pero un micrófono es algo distinto. No hay forma de determinar de antemano cuánto tiempo grabará el usuario, lo que no sería un problema si se tratara de una sola transmisión. Como se almacenan ambas pistas, hay mucho más juego involucrado.  Verás, tan pronto como pulsas el botón de grabación, el micrófono crea dos archivos y vacía continuamente los datos capturados de ambos en la tarjeta. Eso se hace en fragmentos de datos: uno para el formato RAW, otro para el formato WAV, y así sucesivamente.  Como necesitamos aislar esos fragmentos de datos para desenredarlos,   . ¡Y ahí está   ! debemos conocer su tamaño exacto nuestro número mágico  Mi primer pensamiento fue que los fragmentos podrían estar alineados con el tamaño de la unidad de asignación   . En este caso,   . Vamos a probarlo. exFAT 128 KBytes  El encabezado indica claramente que se trata de un archivo estéreo (2 canales), grabado a 32 bits por canal, muestreado 48k veces por segundo. Si recuerdas la imagen de arriba, los fragmentos se repiten aproximadamente a 0,7 segundos.  Obtengamos una aproximación aproximada de los bytes del fragmento para saber una idea aproximada.   1 second of data = 2 channels * 32 bits * 48000 samples 1 second of data = 384000 bytes 0.7 seconds ~ 268800 bytes  Estamos analizando fragmentos de alrededor de 268 KBytes.  Y así, la idea de que los datos pueden ser divididos en exFAT AUS de 128 Kbytes queda instantáneamente desmentida.  El siguiente paso obvio sería viajar hacia arriba en la base 2. Dado que 4096 es un buen equilibrio para los buffers, evaluemos desde allí:   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 segundos coincidieron tan perfectamente con nuestra estimación de 0,7 segundos que supe de inmediato   era la constante que buscábamos. que 262144  La reconstrucción  Conceptualmente, el problema estaba resuelto. Ahora, sólo quedaba construir la herramienta. Para ello, sería necesario:    directamente del volcado de imagen. Dado que las piezas recuperadas por otro software de tallado tendrían la mitad del tamaño esperado (el fragmento de datos contiene dos archivos, por lo que en realidad es el doble del tamaño informado). Desenrede los archivos    . Aprenda a crear un encabezado RIFF    para que los archivos recuperados sean compatibles con el software "M3 ZOOM Edit & Play". Cree un encabezado RIFF con un fragmento BEXT    ! ¡Todo el código está en GitHub  Y estoy bastante seguro de que allí te sentirás más a gusto.  Sin embargo, por el bien de la indexación de Google, dejo aquí los métodos que crean los encabezados RIFF y BEXT, algo que no pude encontrar, lo que desafortunadamente hizo que el proceso tomara más tiempo del que me gustaría admitir.   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 ;"); } }  Como puedes ver, no se puso mucho esfuerzo en el fragmento BEXT; simplemente lo creé para asegurar que "Zoom M3 Edit & Play" fuera compatible.  La herramienta  Espero que hayas tenido una lectura interesante. He intentado mostrar el proceso de pensamiento sin dejar de ser interesante. Espero que el código real se explique por sí solo y lo encontrarás aquí:   https://github.com/wasteofserver/zoom_m3_mic_wav_data_recover/  El desafío no era sólo recuperar grabaciones perdidas: se trataba de comprender por qué fallaban las herramientas tradicionales y desarrollar un método que funcionara.  Si bien podría haber sido más fácil volver a grabar, la emoción de resolver el rompecabezas hizo que el esfuerzo valiera la pena. Al final, obtuvimos una solución personalizada que restaura con éxito las grabaciones de Zoom M3 MicTrak.  Si alguna vez te encuentras en una situación similar, con suerte, este resumen te ayudará. Y si no, bueno, al menos pudiste disfrutar de una pequeña aventura en el mundo de la recuperación de datos.  Esta historia se publicó por primera vez en   . Puede que desee consultarla allí para ver las últimas actualizaciones y comentarios. https://wasteofserver.com/zoom-m3-mictrak-file-recovery/

This story contains new, firsthand information uncovered by the writer.

Read My Stories

Este audio es producido en el idioma original de la historia!

Recuperación de archivos de Zoom M3 MicTrak: una aventura en el mundo de la recuperación de datos

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Telegram: el puente de Crypto Island hacia el continente

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Navegando por las aguas: desarrollo de aplicaciones RAG de nivel de producción con lagos de datos

Telegram: el puente de Crypto Island hacia el continente

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps