MOV Dateien beschädigt, untrunc erkennt Codec nicht

[Philhcks98]

Hallo liebe Recovery Experten
Hab von einem Auftrag ca 5 von 70 korrupte Dateien. Nun ist mindestens eine davon sehr wichtig. Daher hoffe ich auf einen Tipp die wiederherzustellen. Die 5 Dateien sind zwischen anderen funktionierenden Dateien. VLC erkennt die korrupten nicht, ich kann sie auch mit ShutterEncoder nicht encodieren. Hab 1-2 Recovery Tools ausprobiert, die auch nicht funktioniert haben.

Aufnahmeeinstellungen sind wie folgt: UHD, 25fps, ProRes 422.

Ich weiß nicht warum die korrupt sind. Es kann sein, dass 1-2 Dateien wegen fehlendem Stroms abgebrochen wurden, aber eher unwahrscheinlich. Wahrscheinlicher ist, dass durch mein Windows 10 auf 11 Update, meine Sata Config geändert wurde, sodass die SSD (Crucial BX500 1TB) nicht mehr richtig funktionierte.

Ich habe mit untrunc versucht, die Dateien mit einer Referenzdatei zu fixen, aber scheinbar greift der aktuelle untrunc build für windows auf veraltete ffmpeg Libraries (3.3.2 oder so) zurück, obwohl ich wahrscheinlich aktuellere brauche. Laut gpt kann man nicht so einfach diese strikte Nutzung der alten Version austauschen, es sei denn man kompiliert das selber. Aber nach 2 Stunden gestern habe ich aufgegeben, weil ich nach 4-5 Mal Troubleshooting keine Energie mehr hatte. Ich hab auch keine Ahnung davon, wie lange das dauert, bis ich eine aktuelle ffmpeg lib verknüpft habe.

Wenn ich mit der alten Lib untrunc genutzt habe, kommt in etwa der log:


Info: version 'v367-13cafed-dirty' using ffmpeg 'n8.0-3-g08a81b090b' Lavc62.11.100 Info: reading ok.mov Info: parsing healthy moov atom ... Info: special track found (tmcd, 'TimeCodeHandler')

Info: unknown track 'AVdh' found -> fallback to dynamic stats Warning: rel_off(cur_chunk) < pat_size/2 .. AVdh 40, 3641344, 1 Warning: Bad track: 'tmcd' Adding more sophisticated logic for this track could significantly improve the recovered file's quality! Info: using dynamic stats, use '-is' to see them Info: reading mdat from truncated file ... Info: using 64-bit offsets for the broken file Error: unable to find correct codec -> premature end (~0.236%) try '-s' to skip unknown sequences

Info: Found 16905 packets ( AVdh: 9 sowt: 16896 tmcd: 0 ) Info: Duration of AVdh: 360ms (360 ms) Info: Duration of sowt: 352ms (352 ms) C:/msys64/mingw64/include/c++/15.2.0/bits/stl_vector.h:1263: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>:perator [with _Tp = Track::Chunk; _Alloc = std::allocatorTrack::Chunk; reference = Track::Chunk&; size_type = long long unsigned int]: Assertion '__n < this->size()' failed.

Also 360ms werden wiederhergestellt. Müsste aber laut Größe über eine Minute sein

Hat hier jemand eine Idee? Mir gehen scheinbar so langsam die Optionen aus. Vielen Dank schonmal!!

 

[Philhcks98]

mit untrunc bekommst du keine verschwundenen Videodaten zurück

Das ist schon klar. Aber die Daten sind ja da. Sonst wären die ja nicht so groß. Und wenn es ProRes422 nicht erkennt, dann ist es ja ne ziemlich schwache Software. Ich checke auch nicht, wie sowas so einfach unlesbar gemacht werden kann, um ehrlich zu sein.

 

[Alexander2]

Ich checke auch nicht, wie sowas so einfach unlesbar gemacht werden kann, um ehrlich zu sein.

da, eine Möglichkeit:

PS: Die Frage unabhängig davon ist, wie die Dateien korrumpiert wurden. Hier hätte ich zuerst mal den RAM im Verdacht. Am besten mal testen mit memtest86.

 

[Banned]

Aber die Daten sind ja da. Sonst wären die ja nicht so groß.

Du hängst da einer Fehlannahme an. Wenn an verschiedenen Stellen der Datei durch Datenkorruption 1en als 0en gelesen werden oder umgekehrt, dann ändert das nichts an der Größe der Datei. Die Größe kommt durch die Information zustande, wie viele bzw. welche Datenblöcke die Datei umfasst. Diese Blöcke können aber ihren Inhalt ändern, ohne dass sich dadurch die Größe der Datei verändert.

 

[mchawk777]

Das ist schon klar. Aber die Daten sind ja da. Sonst wären die ja nicht so groß.

...und das ist der Denkfehler.
"Daten" im Sinne von "irgendwelchen Bit-Anordnungen" sind natürlich da.
Nur es sind nicht die gewünschten Daten da - sonst wären die Dateien nicht korrupt.

Der Punkt ist schlicht und ergreifend, dass man nichts recovern kann, was nicht da ist.
Und in Deinem Fall lautet die traurige Antwort: Die Daten sind weg.

Es stellt sich eher die Frage, ob und in wie weit mal ggf. Teile des Videos aus den Dateien irgendwie reparieren kann. Da das Video mit einem proprietären Apple-Codec codiert wurde, sehe ich da allerdings schwarz - es sei denn Apple bietet solche Tools an.

Bing gibt folgende Möglichkeiten an:

Treasured von Aeroquartet: Ein kommerzieller Dienst, der beschädigte ProRes-RAW-Dateien analysieren und reparieren kann. Sie bieten eine kostenlose Vorschau und Diagnose an, bevor man bezahlt.

Grau GmbH Video Repair Tool: Wird gelegentlich erfolgreich bei ProRes-Dateien eingesetzt, auch wenn die Ergebnisse nicht immer vollständig sind.

VirtualDub mit FFmpeg-Import-Plugin: Ein etwas technischer Ansatz, bei dem man versucht, die Rohdaten aus der Datei zu extrahieren, selbst wenn der Header beschädigt ist.

Wondershare Repairit: Unterstützt verschiedene ProRes-Varianten und bietet eine erweiterte Reparaturfunktion für stark beschädigte Dateien.

 

[gymfan]

Mit der Sata SSD nehme ich auf.

Eine BX500 in der Kamera? Kann je keine im ext Gehäuse sein, sonst wären die BIOS-Einstellungen für SATA irrelevant. Oder OBS mit ProRes 422 (wozu auch immer, interessiert mich ja nicht).

Ja, also den konkreten Fehler hab ich nicht gefunden, aber wenn es funktionierende Dateien gibt, sollte es ja damit möglich sein, die kaputten zu fixen.

Nein, weil Du nicht verstehst, welche Fehler es gibt und welche untrunc beheben kann.

. Aber die Daten sind ja da. Sonst wären die ja nicht so groß.

Also hast Du sie Dir mit einem Hexeditor (HxD o.Ä.) angesehen?

Es gibt grundsätzlich zwei Fehler bei solchen Dateien:
(1) Die Aufnahme wurde abgebrochen, warum auch immer. Beliebt sind leere Akkus oder zu frühes Ziehen der Karte, machmal auch grauenhaft unfähige Kamerahersteller, die eine volle Speicherkarte nicht früh genug erkennen.
(2a) Die Aufnahme war mal vollständig, das Aufnahmemedium liefert sie aber fehlerhaft zurück, weil das Medium (Spiecherkarte, bei Dir die SSD) defekt ist.
(2b) Die Aufnahme wurde zwar angeblich abgeschlossen, das Medium war aber schon nicht in der Lage, die Daten korrekt zu schreiben.
(2a)+(2b) sind identisch, die Aufnahme ist hops, kann (mit mir bekannten, frei verfügbaren Tools, ich rede hier nicht von Geheimdiensten oder ggf. sehr guten Datenrettungsdiensten) max bis zum ersten fehlerhaften Block auf der SSD wieder hergestellt werden. Völlig egal, wieviel Daten danach noch kommen werden.

Dafür benötigt man für diesen Fall auch keine Referenzdatei (außer, es wäre exakt der erste Sektor der Datei defekt). Aber natürlich kann man sich noch milliarden von weiteren Möglichkeiten ausdenken.

Untrunc ist für (1) geschrieben, daher heißt es auch so.
Es versucht die genannten Anwender- und Herstellerfehler zu fixen.

Ich habe dieses "Problem" (das ich persönlich nie hatte) vor über einem Jahrzehnt aus Spaß mal mit dem MOV einer Nikon D7000 Aufnahme analysiert, weil ich wissen wollte, was bei einer solchen Falschbedienung der Kamera passiert. Dabei wurde die Karte aus der Kamera entfernt bevor die Aufnahme komplett geschrieben war.

Die Kamera (jedenfalls die Nikon und auch damalige GoPros) schreiben den zwingend nötigen Header des MOV (Aufnahmeformat, Anzahl Bilder, Position des Index) sowie den Index (der bei solchen Aufnahmen immer am MOV-Ende liegt) erst mit Abschluss des Videos. Ist dabei der Akku leer oder zieht man die Karte zu früh, dann ist das Video halt erst einmal hops. Für den Header wird in der Datei bei der Aufnahme einfach nur Platz gelassen.

Exakt hier dürfte untrunc und ein, mit exakt identischen Parametern aufgenommenes Video, ansetzen. Es anayliert die Struktur des MOVs, erstellt daraus einen neuen Index, liest aus dem Referenzvideo den Header, ergänzt diesen um die dynamischen Parameter des deferkten Videos (Länge, Position des Index usw.) und schreibt den Index neu. Danach müsste das MOV wieder lesbar sein.

Trifft es bei der Analyse aber auf einen leeren Dateiblock, ist Schluss. Es gibt einen Strukturbruch in den Metadaten des MOVs und man müsste noch extrem mehr Aufwand investieren, um ggf. ein weiteres Segment dieses Videos zu finden. Sowas dürften Geheimdienste oder auch Datenforensiker mit entsprechendem Auftrag durch ein Gericht machen, untrunc sicher nicht.

Daher der Hinweis, sich das defekte und ein korrektes Video mit dem Hex-Editor anzusehen. Sieht der Header ähnlich aus oder ist er im Fall des nicht abspielbaren Videos nahezu leer. Gibt es in der defekten Videodatei leere Abschnitte (oder welche, die mit einem klar erkennbaren Muster ausgefüllt sind).