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 (төлбөртэй) гэх мэт олон хэрэгслүүдээс сонгох боломжтой... Хэдийгээр би R-Studio (төлбөртэй); Тэдний үр дүн нь өрсөлдөөнөөс байнга давж гардаг.

Гэсэн хэдий ч энэ тохиолдолд бүх зүйл тийм ч хялбар биш байх болно. Оролдсон бүх программ хангамж 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 Edit & Play" программтай нийцүүлэхийн тулд 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 бичлэгийг амжилттай сэргээдэг тусгайлан бүтээсэн шийдлийг олж авлаа.

Хэрэв та үүнтэй төстэй нөхцөл байдалтай тулгарвал энэ эвдрэл танд туслах болно гэж найдаж байна. Хэрэв үгүй бол ядаж та өгөгдөл сэргээх ертөнцөд бага зэрэг адал явдалтай байх хэрэгтэй.