Zoom M3 MicTrak File Recovery: прыгода ў свет аднаўлення даных

Як серыя непрыкметных падзей вядзе да глыбокага падарожжа ў бінарнае кадаванне файлаў RIFF і гэты інструмент аднаўлення даных

Нягледзячы на тое, што мне пашанцавала распрацоўваць праграмнае забеспячэнне для сучасных кампаній, я заўсёды быў "друкаром" - значком, які я нашу з гонарам.

І, магчыма, гэта прычына таго, што на працягу больш чым чвэрці стагоддзя людзі звярталіся з носьбітамі інфармацыі для выратавання. Я ніколі не займаўся гэтым прафесійна, гэта проста тое, што мне падабаецца, і, часцей за ўсё, я магу дапамагчы.

Працэс

Мой асноўны падыход складаецца з двух частак:

• захапіць тое, што вы можаце з паміраючага асяроддзя

• паспрабуйце ўзнавіць дадзеныя

  
  

Часам, проста адрэгуляваўшы допуск да чытання, вы можаце захапіць усё з дыска, адхіленага Windows або Mac, бо АС працуе хутчэй, чым можа адказаць носьбіт, які памірае. У мяне быў дыск падлучаны да скрынкі на працягу 7 месяцаў; 100% поспеху ў аднаўленні!

Часам у вас будуць адсутнічаць кавалкі даных, але адна з табліц размеркавання файлаў/галоўнай табліцы файлаў/кантэйнернага суперблока/каранёвага B-дрэва ўсё яшчэ ёсць, так што большасць даных можна захаваць як з імёнамі файлаў, так і з размяшчэннем у дрэве.

У крайнім выпадку ў вас не застаецца нічога, акрамя неапрацаваных даных. Усё, што вы можаце зрабіць, гэта выразаць яго - па сутнасці, счытваць кожны байт з носьбіта, ідэнтыфікаваць вядомыя загалоўкі, такія як JPG ( FF D8 ) або MKV ( 1A 45 DF A3 ), і працягваць захоп усіх паслядоўных даных да канца файла. Калі па якой-небудзь прычыне файл фрагментаваны, выразанне, відавочна, не атрымаецца.

Званок ад П'ера Заго

Фрэнкі, такога раней не было, я наогул асцярожны... Не ведаю, пра што я думаў - я выпадкова адфармаціраваў SD-карту з аўдыя на ўвесь сеанс. Што яшчэ горш, я захаваў на ім некалькі файлаў!

П'ер - неверагодна таленавіты комік і неардынарны акцёр. Нягледзячы на шматграннасць яго творчасці, шырокую вядомасць яму набылі вулічныя замалёўкі, некаторыя з якіх абсалютна ўніверсальныя. Проста праверце той ніжэй, дзе ён проста кажа "Прабачце".

Прастата і камедыйны шарм гэтага скетча ствараюць лёгкі, але ўніверсальна прывабны твор мастацтва.

Такім простым дзеяннем П'ер далучыўся да клуба. Усе псуюць. Нават Pixar . Не хвалюйцеся, сказаў я, калі браў карту, перазапісанае змесціва знікла, але, улічваючы, што гэта карта ў фармаце мікрафона, нават без табліц FAT, мы зможам выразаць большую частку ўсяго, што вы запісалі, бо дадзеныя, верагодна, будуць паслядоўнымі.

Я і не ведаў, што гэта будзе адзін з самых цікавых праектаў цацак, над якімі я працаваў за апошні час. Апошні раз мне было так весела аднаўляць апаратны RAID-0, які ўтрымліваў майстры для альбома « Os Azeitonas ».

Рэха (Рэха, Рэха)...

Як і чакалася, адзіным спосабам вярнуць дадзеныя было выразанне іх з дампа выявы. Ёсць мноства інструментаў на выбар, Photorec (з адкрытым зыходным кодам), Recuva (сачыце за камплектным праграмным забеспячэннем), ReclaiMe (платны), і г.д.... хаця я неабыякавы да R-Studio (платны); іх вынікі стабільна пераўзыходзяць канкурэнтаў.

У гэтым выпадку, тым не менш, усё было б не так проста. Кожнае праграмнае забеспячэнне, якое спрабавала, магло здабываць файлы wav , але нешта было не так з дадзенымі, бо ўсе яны паўтараліся, свайго роду рэха.

Я крыху дрэнна чую, таму я адкрыў іх у Audacity, каб праверыць, што адбываецца. Вы можаце выразна ўбачыць шаблон тут:

Нягледзячы на тое, што кавалкі маюць даволі падобную форму сігналу - няма ніякай двайковай карэляцыі. Акрамя таго, было таксама нешта цьмянае, кожны файл wav меў тое, што выглядала як 2 паслядоўныя загалоўкі.

Майце на ўвазе, што на дадзены момант я ведаў пра файлы wav , што загаловак 52 49 46 46 . Акрамя выкарыстання мікрафона, я не пытаўся ў П'ера, як ён насамрэч запісваў дадзеныя. Аднак, калі я ўбачыў у загалоўку тэг "ZOOM M3", я назваў орган па ўсім гуку.

Ідэальны крок, свайго роду чараўніцтва

Большую частку гэтага жыцця Эд карыстаўся хуткім наборам. Мне так пашанцавала. Акрамя таго, што ён неверагодны кампазітар - проста паслухайце ашаламляльны Best Youth - ён яшчэ і бездакорны гук, жывы і дыхаючы, энцыклапедыя гуку.

Павялічыць? Так, так. У мяне ёсць адзін. Яны запісваюць як wav, так і raw. Дадзеныя сапсаваныя? Ах Вядома. Ачуняць? Скручаныя файлы? Гэта будзе невыканальная задача, і нават калі гэта не так, будзе прасцей проста перазапісаць.

І вось ён меў мяне. Безумоўна, прасцей было б проста перазапісаць, нават П'ер аднойчы прапанаваў зрабіць агучку, але што ў гэтым цікавага?

Чароўны лік

Я нават не цаніў канцэпцыю raw хвалі, пакуль Эд не растлумачыў яе, але цяпер я ведаў, што мікрафон захоўвае два файлы адначасова, і ўсё стала на свае месцы.

Лічбавыя камеры звычайна захоўваюць абодва фарматы, але мікрафон - гэта іншы звер. Няма магчымасці загадзя вызначыць, як доўга карыстальнік будзе запісваць, што не было б праблемай, калі б гэта быў адзін паток. Паколькі ў ім захоўваюцца абодва трэка, патрабуецца даволі шмат гульні.

Вы бачыце, як толькі вы націснеце запіс, мікрафон стварае два файлы і бесперапынна скідае атрыманыя дадзеныя з абодвух на карту. Гэта робіцца ў кавалках дадзеных. Адзін для RAW, іншы для WAV, паўтор.

Паколькі нам трэба ізаляваць гэтыя зрэзы дадзеных, каб разблытаць іх, мы павінны ведаць іх дакладны памер . І вось наша чароўная лічба !

Маёй першай думкай было тое, што кавалкі могуць быць узгоднены з памерам адзінкі размеркавання exFAT . У дадзеным выпадку 128 KBytes . Давайце праверым.

У загалоўку ясна пазначана, што гэта стэрэафайл (2 канала), запісаны з 32 бітамі на канал, з частатой выбаркі 48 тыс. раз у секунду. Калі вы памятаеце з малюнка вышэй, кавалкі паўтараюцца прыблізна з 0,7 секунды.

Давайце атрымаем прыблізную ацэнку байтаў кавалкаў, каб мы ведалі, што адбываецца.

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

Мы разглядаем фрагменты памерам каля 268 Кбайт.

І проста так, ідэя аб тым, што дадзеныя могуць быць разбіты на кавалкі exFAT AUS памерам 128 Кбайт, імгненна аспрэчваецца.

Наступным відавочным крокам будзе рух уверх па базе 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 - гэта канстанта, якую мы шукалі.

Рэканструкцыя

Канцэптуальна праблема была вырашана. Цяпер заставалася толькі стварыць інструмент. Для гэтага неабходна было б:

• Разблытайце файлы непасрэдна з дампа выявы. Паколькі кавалкі, адноўленыя іншым праграмным забеспячэннем для разьбы, будуць мець палову чаканага памеру (фрагмент даных утрымлівае два файлы, таму насамрэч ён удвая перавышае заяўлены памер).

• Даведайцеся, як стварыць загаловак RIFF .

• Стварыце загаловак RIFF з часткай BEXT, каб зрабіць адноўленыя файлы сумяшчальнымі з праграмным забеспячэннем "M3 ZOOM Edit & Play".

І я ўпэўнены, што там вы будзеце адчуваць сябе як дома.

Аднак, дзеля індэксацыі 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.

Спадзяюся, калі вы апынецеся ў падобнай сітуацыі, гэтая паломка дапаможа вам. А калі не, то, прынамсі, вы атрымаеце асалоду ад невялікіх прыгод у свеце аднаўлення дадзеных.