Extract videodata van corrupte files?

[WhatsappHack]

Hoi!

Ik wist niet goed welk subforum ik moest pakken, want het is een soort van mengeling tussen datarecovery, videoformaten vanaf camera's (Rs7, Ronin, etc.) en software om het uit te lezen.

Het probleem is als volgt: de RAID-kaart van vrienden had het begeven. Hierdoor is het XFS filesystem dusdanig beschadigd geraakt dat het niet meer mogelijk was om deze te herstellen tot een directory structuur. (Mede de schuld van xfs_repair zelf, maar goed; gedane zaken enzo.) De backup blijkt niet afgerond te zijn, dus dubbel pech voor hun.
Uiteindelijk PhotoRec erop los gelaten om de data terug naar boven te halen. Dat is gelukt met ongeveer 33% van de data. Het probleem is echter dat ik al flink had moeten knutselen om de RAID-kaart überhaupt de RAID weer online te laten geven. Hij spuugt over het algemeen prima data uit, maar er is ook zat willekeurige corruptie. Gewoon een byte hier en een byte daar die geflipt wordt. (Dat doet de RAID-kaart helaas zelf. De data op de schijven zelf lijkt prima in orde, want met nieuwe pogingen of na reboots kan de corruptie bijvoorbeeld opeens heel ergens anders optreden. Zeer f*cked.) In mp4's enzo is dat over 't algemeen niet zo'n ramp want dan heb je een paar frames die corrupt zijn: soit, daar edit je wel omheen. Maar de ruwe data: daar is het een stuk lastiger, want die willen dus niet eens openen.

Nu heb ik allerlei _mdat.mov bestanden. Deze bestanden bevatten nog headers (mediainfo leest ze prima uit), en ik kan precies uitlezen welke codec er gebruikt is en zelfs zien welke camera ervoor gebruikt is; en in de XMF data kan ik de projectnamen zien.

De _mdat.mov bestanden bevatten duidelijk werkbare data. Ik heb ze ook door Treasured heengehaald, en die ziet ze ook als bestand waar zelfs doorheen geskipped kan worden.
Nu is mijn vraag dus: kent iemand een tool (command line ook helemaal prima, graag zelfs!) die de foute headerdata e.d. kan wegsnijden en gewoon de ruwe video en/of audio kan extracten uit het MOV bestand?
Of naar welke data je moet zoeken om het begin van de videodata te herkennen? Dan kan ik namelijk de headers eruit snijden, de file laten beginnen met de videodata, en kijken wat ie wil doen met de ruwe videodata.

De MXF bestanden zijn allen niet te openen. Ik weet wel hoe je corrupte Avid MJPEG containers kan extraheren en vervolgens met LibMXF herschrijven naar een gloednieuwe MXF met nieuwe headers (dd naar raw i.c.m. offset skippen en dan writeavidmxf een bestand laten uitspugen); maar met die DNxHD codec weet ik niet waar ik naar moet zoeken om de corrupte header data eruit te snijden zodat die herschreven kunnen worden. Ik weet dus niet wat daar normaal de offset voor is/hoe je die kan vinden, dat weet ik enkel van de Avid MJPEG. Als iemand toevallig weet hoe je daar de offset voor kan vinden zodat je dd instructies kan geven dat te skippen en vervolgens pogen writeavidmxf de instructie te geven om de ruwe DNxHD data naar MXF te herschrijven?

Thnx!

[ Voor 3% gewijzigd door WhatsappHack op 16-08-2017 18:29 ]

[Ventieldopje]

De data op de schijven zelf lijkt prima in orde, want met nieuwe pogingen of na reboots kan de corruptie bijvoorbeeld opeens heel ergens anders optreden.

Als ik het goed begrijp ga je nu recoveren van data die eigenlijk niet corrupt is maar niet werkt omdat de RAID controller (of kabels?) naar zn gootje is?

Is de partitie nou corrupt omdat het zo is of omdat de data overdracht niet goed gaat?

[WhatsappHack]

Ventieldopje schreef op donderdag 17 augustus 2017 @ 01:37:
[...]


Als ik het goed begrijp ga je nu recoveren van data die eigenlijk niet corrupt is maar niet werkt omdat de RAID controller (of kabels?) naar zn gootje is?

Is de partitie nou corrupt omdat het zo is of omdat de data overdracht niet goed gaat?

Nee het is echt de controller zelf. Zeg maar... heel erg overduidelijk.
Zelfs z'n output tijdens post is soms corrupt. (Comqzoller 1, Unit $ - BBU Stutix: CHURGING.) Een identieke kaart in hetzelfde slot geeft geen problemen. De firmware en BIOS zijn dubbel opnieuw geflasht just in case, maar dat mocht niet baten.


Je vraag kan ik niet helemaal zo beantwoorden; het is iets anders:
de partitie is er namelijk in principe nog, alleen heeft XFS de metadata dusdanig gemold dat hij nog maar 50GB van de 15TB denkt te hebben. XFS vindt de partitie "healthy" en heeft dus definitief de data op deze wijze opgeslagen. Dit is op geen enkele wijze te herstellen. (Aldus de ontwikkelaars van XFS en m'n eigen pogingen.) Een directory structuur zullen we niet meer krijgen, einde verhaal.

Hoe het zit met de gezondheid van de data an sich is discutabel, maar *waarschijnlijk* staat die inderdaad nog healthy op de schijven (op wat spullen na gezien xfs_repair heeft huisgehouden. In principe kan 50GB aan willekeurig reallocated data natuurlijk zelfs op 15TB zorgen voor *enorme* problemen, afhankelijk van waar ie die data weggehaald en herschreven heeft/wat ie daarbij overschreven heeft.): alleen zit die controller te klooien en is daardoor raakt tijdens het kopiëren de data corrupt. Hierdoor wordt PhotoRec waarschijnlijk ook vaak op het verkeerde spoor gezet, wat niet bijdraagt aan de problematiek. (Dubbelop.) We gaan nog pogen om de array om te zetten naar een andere controller (de controller waar nu de recovery naar toe wegschrijft.) in de hoop dat dat 1.) goedgaat en 2.) zorgt voor corruptieloze recovery met PhotoRec, maar nu PhotoRec data aan het uitspugen is van de nu "werkende" array willen we toch eerst veilig stellen wat veilig te stellen valt; zelfs als het corrupt is. En graag weten, vooral ook hobbymatig , of deze bestanden überhaupt te herstellen zijn; en zo ja: hoe. Het is nogal interessante materie. Mocht de array namelijk niet (goed) verplaatsen naar de nieuwe controller dan is er enkel met heel veel mazzel ooit nog data terug te halen. Dus beter iets dan niets op 't moment.
Het is geen megaramp als de data helemaal weg is, maar het zou wel wat tijd en moeite schelen als het er nog is. Maar zowel ik als m'n vrienden houden wel van een uitdaging, en gaan de data dus niet afschrijven voordat we alles geprobeerd hebben.


De stappen zouden hetzelfde moeten zijn als voor het repareren van die mjpeg bestanden, alleen ik weet dus niet wat de offset is voor DNxHD of wat de datastring is voor het begin van de video en/of audiodata.
Zelfde verhaal voor die MOV bestanden; ik zie dat er videodata in zit. Ik kan frames eruit trekken. Maar waar de videodata precies begint (hoe je dat kan vaststellen): dat kan ik nergens goed vinden. Ik kan wel mensen vinden die anderen hulp bieden door de hex uit te lezen, maar zonder uitleg waar ze nu precies naar kijken om vast te stellen wat de offset was (/hoe ze die hebben gevonden op basis van de ruwe hex) schiet ik daar weinig mee op.

[ Voor 6% gewijzigd door WhatsappHack op 17-08-2017 04:04 ]

[Ventieldopje]

Aangezien MOV slechts een container is lijkt me dat lastiger dan met andere formaten maar met 2 seconden googelen kwam ik hier uit: http://www.file-recovery.com/mov-signature-format.htm

Ps, als een 2e controller het ook niet doet kan het je PCI poort of eerder nog je kabels(!) zijn. Geloof het of niet, kabels veroorzaken soms ook nare dingen

[ Voor 30% gewijzigd door Ventieldopje op 17-08-2017 13:26 ]

[WhatsappHack]

Ventieldopje schreef op donderdag 17 augustus 2017 @ 13:24:
Aangezien MOV slechts een container is lijkt me dat lastiger dan met andere formaten maar met 2 seconden googelen kwam ik hier uit: http://www.file-recovery.com/mov-signature-format.htm

Thanks! Raar, die ben ik dus niet tegengekomen. o0 Zal het wel verkeerd geformuleerd hebben.
Maar hier kan ik denk ik zeker wel wat mee; ga straks meteen ff zoeken

Thanks!

Ps, als een 2e controller het ook niet doet kan het je PCI poort of eerder nog je kabels(!) zijn. Geloof het of niet, kabels veroorzaken soms ook nare dingen

I know!
Maar de andere controller werkt naar behoren, ook in de PCI poort van de kapotte controller. Helaas!
Dat was het eerste dat getest is, andere poort, alle schijven omzetten naar de 8 andere trays (en dus 8 andere kabels), een voor een de schijven eruit trekken (je weet maar nooit, misschien is 1 kapotte schijf wel iets dat een bug triggered. Alles uitsluiten.) om te zien of dat verschil maakt, opstarten met helemaal geen schijven daarna flashen en weer rebooten, nada. Hij is helaas echt dood aan het gaan

Ik heb intussen na wat verdere handenarbeid en "de Russische methode" (onder druk zetten en gepast (digitaal) geweld toepassen.) zover gekregen om ruim 90% van de data uit te spugen. Helaas nog steeds met corruptie, maar het is iig een stuk beter dan de ~33% data die er was.

[ Voor 10% gewijzigd door WhatsappHack op 17-08-2017 14:22 ]