Fehlerhafte Aufnahmen reparieren

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Fehlerhafte Aufnahmen reparieren

      Anzeige
      Kann eine Aufnahme nicht abgespielt oder im Schnittprogramm eingelesen werden, könnte es an einem fehlendem AVI-Header liegen, was besonders gerne beim MSI Afterburner passiert, wenn zB. eine Aufnahme länger als 30 Minuten andauert.

      Manchmal hilft es, den seit der Aufnahme noch nicht geschlossenen Afterburner eine neue Aufnahme anfangen zu lassen, wodurch die alte Aufnahme erst korrekt abgeschlossen wird.
      Ansonsten gibt es Reparatur-Tools, zB: divfix.org/
      Wer Dxtory besitzt, kann das interne Tool versuchen: abload.de/img/2016-06-12_0654fuuug.png

      EInen manuellen Weg zeige ich nun schön mit Bildern, anhand dieses Videos (für alle, die diese Methode nur alle paar Monate anwenden müssen und nur kurz die Schritte nachsehen möchten): Ungeschlossene AVI (fehlender Header, index, keyframes) reparieren


      Benötigt:
      1x kaputte Aufnahmedatei
      1x heile Aufnahmedatei (als Referenz, benötigt identische Aufnahmeeinstellungen wie die kaputte Datei, muss aber nicht länger als wenige Sekunden Länge besitzen.)
      1x HexEditor: mh-nexus.de/downloads/HxDSetupDE.zip
      1x VirtualDub: sourceforge.net/projects/virtu…est/download?source=files (Auch in SSM enthalten).

      Vorgehen:
      1. Beide Dateien (1x kaputte, 1x heile Testaufnahme) in den HexEditor reinschieben.
      In der heilen Testdatei: STRG+F und Suche nach "movi00" durchführen:


      movi00 und alles bis ganz nach oben in der Datei markieren und kopieren.
      In der kaputten Datei nun ebenfalls nach movi00 suchen und movi00 und alles bis ganz nach oben markieren und durch den kopierten Teil aus der heilen Testdatei ersetzen.
      Die kaputte Datei nun unter "Datei - Speichern unter" neu speichern (neuen Dateinamen vergeben zur Sicherheit).

      2. Neue VideoDatei in VirtualDub öffnen:

      Haken setzen bei "Ask for extendet Options after this Dialog" und "Re-derive Keyframe Flags".

      Die nun erscheinende Warnung wegen fehlendem Index wegklicken.
      "Direct Stream Copy" muss jedes Mal aufs Neue ausgewählt werden:


      Bei mehr als 1 Audiospur muss die 2. und ggf. folgende einzeln ausgewählt und unabhängig vom Video via "File - Save WAV" exportiert werden:


      Das Video kann nun mit der 1. Audiospur über "File - Save as AVI" repariert gespeichert werden.
    • Wichtiger Hinweis

      Niemals die kaputte AVI Datei löschen nachdem man eine neue mit dem Hexeditor erstellt hat.

      Wieso?

      Die Methode einfach einen neuen Header in die kaputte Datei zu kopieren und auf gut Glück durch Virtual Dub indexieren zu lassen ist sehr unsicher und kann im Zweifelsfall dem Video noch mehr Schaden zufügen als vorher, sodass es komplett unabspielbar ist.
      Das Problem an der ganzen Sache ist, dass nicht jede kaputte AVI gleich ist und ganz verschiedene Gründe haben, warum sie nicht abspielbar sind. Bei manchen fehlt der Header komplett, bei anderen nur ein Teil oder es liegt ein ganz anderes Problem vor.

      Wo sind die Nachteile an der von De-M-oN/Sem erstellten Methode?
      1. Wenn man z.B. eine fehlerfreie 10sek Aufnahme nimmt, um dort den Header in die kaputte 1-2h Aufnahme zu kopieren kann es sein, dass der Header gar nicht zu der Aufnahme passt. Ab einer gewissen Dateigröße kann ein anderer Headertyp genutzt werden, was bedeutet dass das kaputte Video nichts mit dem neuen, nicht passenden Header anfangen kann.
      2. Die Zeit kann ebenfalls falsch sein und kann auch nicht durch VirtualDub wieder aus dem Stream-Header herausgelesen werden. Wenn man also einen Header von einer 30min Aufnahme in ein 1h Video reinsetzt, dann indexieren Programme wie VirtualDub nur bis 30min und erkennen das restliche Video nicht.
      3. Wenn man richtig Pech hat, dann sind die Indexverweise durch den neuen Header durcheinander gekommen. Dann kann kein Programm mehr die Datei rekonstruieren. Wenn man das technische Wissen dahinter hat, kann man den AVI-Header/Container im Hexeditor entschlüsseln und versuchen dort die Daten manuell zu reparieren. Wenn man aber auch der codecinterne Videoheader fehlerhaft ist, dann ist das die Suche nach der Nadel im Heuhaufen.
      Was ich damit sagen will ist nur, dass diese "Standardmethode" nicht immer funktioniert und dass man, wenn man sich mit der Materie nicht auskennt, vielleicht eher zu weniger radikalen Methoden greift und einen Profi über die defekte Aufnahme drüberschauen lässt.
      Erspart einem sehr viel Arbeit und Nerven...
      ~ Let's plays, Animes, Cinematics, Zeichnungen ~ :D
    • Mein Tipp: wenn alles fehlschlägt - so lange VLC es abspielen kann, kann man es mit diesem auch neu kodieren (z.B. x264 lossles)

      Ansonsten kann man sehr schnell mit ffmpeg neu muxen

      ffmpeg -i input.avi -c:v copy -c:a copy output.avi

      der Container wird durch die endungen bestimmt so kann z.B. auch mov in mp4 gemuxt werden oder so:

      ffmpeg -i input.mov -c:v copy -c:a copy output.mp4
    • VLC, MPC-HC, AviSynth, ffmpeg, VirtualDub, WMP und Mencoder konnten die Datei nicht einlesen.

      Um neu zu muxen muss man erst die Video und Audiostreams extrahieren, wofür das Programm die Streamheader einlesen muss.
      Wenn diese beschädigt sind, dann kann kein Programm was mit dem Video anfangen :/
      ~ Let's plays, Animes, Cinematics, Zeichnungen ~ :D
    • Anzeige
      @GrandFiredust
      Die Struktur konnte ich schon wiederherstellen. Nur der Video Stream war nicht in Ordnung.

      Sprich ich konnte den Videostream nicht dekodieren, da hat er sich aufgehangen. Entweder war es der falsche Farbraum, falsche Einstellungen des Codecs oder whatever.

      Weil alle Angeben zur Dekodierung des Videos im VideoStream Header stehen in der AVI.

      Mit anderen Worten bei dir hat der ULH2 Codec von UTVideo vllt. gar nicht gestimmt.

      Ich kann mir jetzt 3 Sachen vorstellen.
      1. Entweder hat der UTVideo Header nicht gepasst zwecks falscher Farbraum, Farbmatrix, Encodierungsmethode
      2. oder die Indextabelle war so beschädigt am Ende das der Video Datenblock nicht decodiert werden konnte und es halt falsche Adressen gab dadurch.
      3. Der Video Datenblock war beschädigt und die Indextabelle in Ordnung. Was dann halt auch zum Crash führt, da auch hier falsche Adressen von der Indextabelle zum Video Datenblock zugeordnet sind.


      Eine Indexrekonstruktion von AVI Files geht nur, wenn bestimmte Angaben noch vorhanden sind. Entweder im Header oder in eines der Index Tabellen am Ende der Datei.

      Bei einem Lossless Video geht meist der Austausch des Headers, da die Frames meist alle I-Frames sind. Halt Schlüsselbilder und diese somit auch gleiche Index Muster auch haben.


      Wie gesagt, Audio war ja bei dir noch komplett Intakt gewesen bei dem File. Nur der Videostream nicht. Entweder beschädigter Datenblock oder falsche Indextabelle schon.

      Daher: Wenn eine Datei Defekt sein sollte, nicht einfach blöd den Header austauschen. Wenn, dann macht lieber eine Sicherheitskopie des Headers den ihr überschreibt. Weil wenn es nicht gehen sollte, kann man die Ursprüngliche Datei wiederherstellen und das Problem anders angehen.

      Ansonsten ist das wirklich wie eine Nadel im Heuhaufen.

      PCM Audio auszulesen ist z.B. kein Ding. Das Teil ist unkomprimiert und hat somit eine feste Größe. Aber UTVideo ist ein Kompressionscodec. Und wenn da bestimmte Infos fehlen, aber zum Video notwendig sind, dann kann man nur raten.
    • GrandFiredust schrieb:

      Niemals die kaputte AVI Datei löschen nachdem man eine neue mit dem Hexeditor erstellt hat.

      Wieso?

      Die Methode einfach einen neuen Header in die kaputte Datei zu kopieren und auf gut Glück durch Virtual Dub indexieren zu lassen ist sehr unsicher und kann im Zweifelsfall dem Video noch mehr Schaden zufügen als vorher, sodass es komplett unabspielbar ist.
      Das Problem an der ganzen Sache ist, dass nicht jede kaputte AVI gleich ist und ganz verschiedene Gründe haben, warum sie nicht abspielbar sind. Bei manchen fehlt der Header komplett, bei anderen nur ein Teil oder es liegt ein ganz anderes Problem vor.

      Wo sind die Nachteile an der von De-M-oN/Sem erstellten Methode?
      1. Wenn man z.B. eine fehlerfreie 10sek Aufnahme nimmt, um dort den Header in die kaputte 1-2h Aufnahme zu kopieren kann es sein, dass der Header gar nicht zu der Aufnahme passt. Ab einer gewissen Dateigröße kann ein anderer Headertyp genutzt werden, was bedeutet dass das kaputte Video nichts mit dem neuen, nicht passenden Header anfangen kann.
      2. Die Zeit kann ebenfalls falsch sein und kann auch nicht durch VirtualDub wieder aus dem Stream-Header herausgelesen werden. Wenn man also einen Header von einer 30min Aufnahme in ein 1h Video reinsetzt, dann indexieren Programme wie VirtualDub nur bis 30min und erkennen das restliche Video nicht.
      3. Wenn man richtig Pech hat, dann sind die Indexverweise durch den neuen Header durcheinander gekommen. Dann kann kein Programm mehr die Datei rekonstruieren. Wenn man das technische Wissen dahinter hat, kann man den AVI-Header/Container im Hexeditor entschlüsseln und versuchen dort die Daten manuell zu reparieren. Wenn man aber auch der codecinterne Videoheader fehlerhaft ist, dann ist das die Suche nach der Nadel im Heuhaufen.
      Was ich damit sagen will ist nur, dass diese "Standardmethode" nicht immer funktioniert und dass man, wenn man sich mit der Materie nicht auskennt, vielleicht eher zu weniger radikalen Methoden greift und einen Profi über die defekte Aufnahme drüberschauen lässt.
      Erspart einem sehr viel Arbeit und Nerven...
      Virtualdub findet bei weitem weniger als l-smash oder ffmpeg/ffms2. Aber das wäre für den Laien deutlich schwieriger.

      Punkt 2 kann ich dir allerdings in keinsterweise zustimmen. Ich nahm als Reperaturdatei meist nur wenige Sekunden und das ging.

      Und selbstverständlich sollte der Header nicht überschrieben werden, wenn einer existent ist. Das ist eig. klar.
      Aktuelle Projekte/Videos




      Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
      Notdürftig die Liste was aktuell läuft: Unreal | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt Rally | Dirt 4 | WRC 7
    • GrandFiredust schrieb:

      Laut SagaraS lag das daran dass im neuen Header nicht genug Bits zur Verfügung standen für eine große Zeitangabe - wenn ich mich richtig erinnere.
      Nein. Da habe ich es nur geschätzt, weil ich mich gewundert habe das nicht mehr zur Verfügung stand, aber die AVI arbeitet ja ganz anders.

      Funktionieren tut es wie folgt:

      Segment1 - ca. 1GB
      Segment2 - ca. 2GB
      Segment3 - ca. 2GB
      usw. mit 2GB


      2GB = 2147483648 Byte = 8000 0000 Hex

      Und dann passt das schon mit jeweils 4 Byte für die Größenangabe.

      Jedes Segment steht für sich selbst, bezieht aber seine Infos aus einem Header.

      Das heißt du kannst die Segmente mit den jeweiligen allgemeinen Header auch so aufspalten.
    • Hmm... Ist das normal?

      Ich hab ein kaputtes Video. Ich weiß nicht, wie es passiert ist. Ich hab die Aufnahme beendet, dann ist beim Schließen das Spiel abgesoffen. Irgendwie lässt sich nun die Datei nicht öffnen (war MSI AB).

      Ich hab es jetzt in den Hex Editor gepackt, aber die fehlerhafte Videodatei scheint eine Million Zeilen Kode zu haben, bis movi00 kommt! Kann das sein? Mir tun die Finger weh...