Zoom M3 MicTrak File Recovery: деректерді қалпына келтіру әлеміндегі шытырман оқиға

Бірқатар түсініксіз оқиғалар RIFF файлдарының екілік кодтауына және осы деректерді қалпына келтіру құралына терең саяхатқа қалай әкеледі

Маған заманауи компаниялар үшін бағдарламалық жасақтаманы әзірлеу бақыты бұйырғанымен, мен әрқашан «принтер жігіті» болдым, бұл төсбелгіні мақтанышпен киемін.

Ширек ғасырдан астам уақыт бойы адамдар құтқару үшін сақтау құралдарына жүгінгенінің себебі де осы шығар. Мен мұны ешқашан кәсіби түрде жасамадым, бұл маған ұнайтын нәрсе және жиі көмектесе аламын.

Процесс

Менің негізгі көзқарасым екі жақты:

• өліп жатқан ортадан қолыңыздан келгенді түсіріңіз

• деректерді қайта жасауға тырысыңыз

  
  

Кейде тек оқуға төзімділікті реттеу арқылы сіз Windows немесе Mac қабылдамайтын дискіден барлығын түсіре аласыз, өйткені операциялық жүйе өліп жатқан орта жауап бере алатындан тезірек аяқталады. Менде 7 ай бойы қорапқа диск ілінді; 100% қалпына келтіру сәттілігі!

Кейде сізде деректердің бөліктері жетіспейді, бірақ файлдарды бөлу кестесі/негізгі файл кестесі/контейнер суперблок/түбір B-ағашының бірі әлі де бар, сондықтан деректердің көпшілігін файл атауларымен де, ағаш орналасқан жерімен де құтқаруға болады.

Төтенше жағдайда сізде кейбір бастапқы деректерден басқа ештеңе қалмайды. Сіз жасай алатын нәрсе - оны қиып алу - негізінен ортадан әрбір байтты оқу, JPG ( FF D8 ) немесе MKV ( 1A 45 DF A3 ) сияқты белгілі тақырыптарды анықтау және файлдың соңына дейін барлық дәйекті деректерді түсіруді жалғастырыңыз. Егер қандай да бір себептермен файл үзілген болса, ою сәтсіз аяқталатыны анық.

Пьер Загоның қоңырауы

Фрэнки, мұндай жағдай бұрын болған емес, мен жалпы сақтықпен қараймын... Мен не ойлағанымды білмеймін - мен кездейсоқ бүкіл сеанс үшін аудиосы бар SD картасын пішімдедім. Ең сорақысы, мен оған кейбір файлдарды сақтап қойдым!

Пьер - керемет дарынды комедия және ерекше актер. Оның жұмысы көп қырлы болғанымен, ол көше эскиздерімен кеңінен танымал болды, олардың кейбіреулері мүлдем әмбебап. Ол жай ғана "Кешіріңіз" деп айтатын төмендегіні тексеріңіз.

Бұл эскиздің қарапайымдылығы мен комедиялық тартымдылығы жеңіл, бірақ әмбебап тартымды өнер туындысын жасайды.

Осы қарапайым әрекетімен Пьер клубқа қосылды. Барлығы шатасады. Тіпті Pixar . Уайымдамаңыз, дедім мен картаны алып жатқанда, қайта жазылған мазмұн жоғалып кетті, бірақ бұл микрофонмен пішімделген карта екенін ескерсек, тіпті FAT кестелері болмаса да, біз сіз жазған барлық нәрселердің көпшілігін қиып алуымыз керек, өйткені деректер дәйекті болуы мүмкін.

Бұл мен біраз уақыттан бері жұмыс істеген ең қызықты ойыншық жобаларының бірі болатынын білмедім. Соңғы рет ' Os Azeitonas ' альбомының шеберлері қамтылған RAID-0 аппараттық құралын қайта құру кезінде осынша қызық болдым.

Эхо (жаңғырық, жаңғырық)...

Күтілгендей, деректерді қайтарудың жалғыз жолы оны кескін қоқыстарынан қиып алу болды. Таңдау үшін көптеген құралдар бар, Photorec (ашық бастапқы коды ) , Recuva (топтамалық құралға назар аударыңыз), ReclaiMe (ақылы) және т. олардың нәтижелері бәсекелестерден тұрақты түрде асып түседі.

Бұл жағдайда бәрі оңай болмас еді. Кез келген бағдарламалық жасақтама wav файлдарын шығара алды, бірақ деректерде дұрыс емес нәрсе болды, өйткені олардың барлығында қайталану, жаңғырық болды.

Менің естуім нашар, сондықтан мен не болып жатқанын тексеру үшін оларды Audacity бағдарламасында аштым. Үлгіні мына жерден анық көруге болады:

Бөлшектердің толқын пішіні өте ұқсас болғанымен - екілік корреляцияның ешқандай түрі жоқ. Сонымен қатар, бұлыңғыр нәрсе болды, әрбір wav файлында қатарынан 2 тақырып болды.

Есіңізде болсын, осы уақытта wav файлдары туралы менің білімім тақырып 52 49 46 46 болды. Микрофонды пайдаланудан басқа, мен Пьерден деректерді қалай жазғаны туралы сұрамадым. Дегенмен, тақырыпта «ZOOM M3» тегін көргенде, мен дыбыстың бәрі бойынша уәкілетті органға қоңырау шалдым.

Perfect Pitch, сиқырдың бір түрі

Эд осы өмірінің жақсы бөлігін жылдам теруде болды. Мен осылай бақыттымын. Таңғажайып композитор болудан басқа - ең керемет жасты тыңдаңыз - ол сондай-ақ мінсіз, тірі және тыныс алатын, дыбыс туралы энциклопедия.

Масштабтау? Иә, иә. Менде біреуі бар. Олар wav және raw форматтарын жазады. Деректер бұзылған ба? Ах. Әрине. Қалпына келтіру керек пе? Бұралған файлдар? Бұл мүмкін емес тапсырма болады және олай болмаса да, қайта жазу оңайырақ болады.

Сол жерде ол мені ұстады. Қайта жазу оңайырақ болар еді, тіпті Пьер бір сәтте дауыс беруді ұсынды, бірақ мұның қызығы қай жерде болады?

Сиқырлы сан

Эд оны түсіндірмейінше, мен raw толқын түсінігін тіпті бағаламадым, бірақ енді мен микрофонның бір мезгілде екі файлды сақтайтынын білдім, бәрі орнына түсті.

Сандық камералар екі пішімді де сақтайды, бірақ микрофон - бұл басқа жануар. Пайдаланушы қанша уақыт жазатынын алдын ала анықтаудың ешқандай жолы жоқ, егер бұл бір ағын болса, бұл мәселе болмайды. Ол екі тректі де сақтайтындықтан, одан да көп ойнау бар.

Көрдіңіз бе, сіз жазбаны басқан кезде микрофон екі файл жасайды және түсірілген деректерді екеуінен де картаға үздіксіз өшіреді. Бұл деректер бөліктерінде жасалады. Біреуі RAW үшін, екіншісі WAV үшін, қайталаңыз.

Біз оны шешу үшін деректердің сол бөліктерін оқшаулауымыз керек болғандықтан, олардың нақты өлшемін білуіміз керек . Міне, біздің сиқырлы санымыз !

Менің бірінші ойым, бөліктер exFAT бөлу бірлігі өлшеміне сәйкес келуі мүмкін. Бұл жағдайда 128 KBytes . Оны сынап көрейік.

Тақырыпта бұл бір арнаға 32 битпен жазылған, секундына 48 мың рет таңдалған стерео файл (2 арна) екені анық көрсетілген. Жоғарыдағы суреттен есіңізде болса, бөліктер шамамен 0,7 секундта қайталанады.

Келіңіздер, доп алаңын білу үшін данк байттары бойынша шамамен жуықтауды алайық.

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

Біз шамамен 268 Кбайт болатын бөліктерді қарастырамыз.

Дәл сол сияқты, деректерді 128 Кбайт болатын 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 тұрақты мән екенін бірден білдім.

Қайта құру

Концептуалды түрде мәселе шешілді. Енді бұл құралды құрастыру мәселесі болды. Ол үшін мыналар қажет болады:

• Файлдарды тікелей кескін демпінен шешіңіз . Басқа ою бағдарламалық құралы арқылы қалпына келтірілген бөліктер күтілетін өлшемнің жартысы болатындықтан (деректер бөлігінде екі файл бар, сондықтан ол шын мәнінде хабарланған өлшемнен екі есе көп).

• RIFF тақырыбын жасау жолын үйреніңіз .

• Қалпына келтірілген файлдарды "M3 ZOOM өңдеу және ойнату" бағдарламалық құралымен үйлесімді ету үшін 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 жазбаларын сәтті қалпына келтіретін арнайы құрастырылған шешім алдық.

Егер сіз де осындай жағдайға тап болсаңыз, бұл бұзылу сізге көмектеседі деп үміттенеміз. Егер жоқ болса, кем дегенде, деректерді қалпына келтіру әлемінде кішкене шытырман оқиғадан ләззат алуыңыз керек.