Ton ist asynchron (HQ)

[IMJens]

Also, in der Cutlist stehen nur die Schnittpunkte, wo das Video per se geschnitten werden soll.

Das Video ist aber nun ein Container und enthält einen Video-Stream und einen Audio-Stream. Es gibt auch Videos mit mehreren Audio-Streams, aber die werden von OTR nicht angeboten (daher auch gelegentlich die separaten MP3- und AC3-Dateien). Diese werden nun separat – aber mit denselben Schnittpunkten – geschnitten und daher eben auch an der gleichen Stelle. D.h., wenn z.B. ein Schnittpunkt bei 3600 Sekunden (=6 Minuten) gesetzt wird, dann wird je der Video- und der Audio-Stream eben nach 3600 Sekunden Spielzeit geschnitten (eigentlich wird das in Frames gerechnet, aber das führt jetzt zu weit ab).

Das Schnitt-Werkzeug nun (Cutana, ColdCut, etc.) kümmert sich nicht um die getrennten Streams und sieht diese auch nicht. Es setzt einfach die Schnittpunkte und speichert diese in der Cutlist, welche dann an das eigentlich Schnittprogramm übergeben wird. In der Regel ist dies dann VirtualDub oder seltener auch mal AviDemux.

Wenn also so ein Fehler passiert, dann passiert er erst im eigentlichen Schnittprogramm.

Jetzt kann es aber sein, dass mal irgend etwas mit dem Audio-Stream selbst nicht in Ordnung ist. Dafür gibt es unterschiedliche Ursachen. Z.B. kann es bei der Aufnahme oder beim Schneiden einen Verarbeitungs-Stau geben, weil der Arbeitsspeicher gerade mal überlastet ist, weshalb dann der Audio-Stream eine untergeordnete Verarbeitungs-Hierarchie erhält (der Video-Stream ist eben wichtiger in einem Video) und dann an einigen Stellen quasi zeitlich verzerrt wird.

Um diesen Fehler nun einzugrenzen kann man z.B. das Video nochmal (die alte Schnittliste tut es immer noch) neu schneiden oder nochmal komplett herunterladen, dekodieren und schneiden.

An der Stelle kann ich aus eigener Erfahrung nur sagen, dass ich hier gelegentlich Fehler durch einen fehlerhaften Download hatte und erst später beim Anschauen diese Fehler in Bild oder Ton bemerkbar wurden (beim Schneiden achte ich nie auf den Ton). Solche Übertragungsfehler können auch durch die Dekodierprüfung rutschen. Das liegt an der Prüfmethode und ist jetzt etwas komplizierter und sowieso unwichtig.

Nach dem erneuten Schneiden (und vorher ggf. Herunterladen) ließen sich aber solche Fehler beheben, wenn es kein Fehler bei der Aufnahme war. Dies ist mir das letzte mal bei besagter Conan-Aufnahme unter gekommen – also eher unwahrscheinlicher.

In Deinem Fall vermute ich einfach mal ganz stark, dass Deine Ton-Verschiebung beim Schneiden passiert ist und VirtualDub (vermutlich Dein Prog) da einen kleinen Hänger hatte. Vielleicht lief gerade irgend so ein Windows-Dienst im Hintergrund mit 50% oder mehr CPU-Last (die machen das öfters) oder ein anderes Programm hatte im Hintergrund irgend etwas zu daddeln. Vielleicht ist Deine HDD so derbe fragmentiert, dass es vermehrte Frame-Skips/Exceptions beim Auslesen der Datei gab. Passiert halt. Wie gesagt, beim nächsten Mal einfach nochmal schneiden und ggf. vorher neu laden.

So, ich hoffe das war etwas verständlicher und Du weißt nun, worauf Du beim nächsten Mal achten musst.

@OTR:
Bitte korrigiert mich, wenn ich hier irgend wie doch noch etwas irgendwie falsch verstanden oder ungenau erklärt oder vergessen haben sollte.

[predalien]

An der Stelle kann ich aus eigener Erfahrung nur sagen, dass ich hier gelegentlich Fehler durch einen fehlerhaften Download hatte [..] Solche Übertragungsfehler können auch durch die Dekodierprüfung rutschen. Das liegt an der Prüfmethode und ist jetzt etwas komplizierter und sowieso unwichtig.

Ich bin eigentlich immer davon ausgegangen, dass OTR einen Hash-Algorithmus zur Prüfung der Datei vor und nach der Dekodierung verwendet. Wenn das der Fall ist, dann würde jeder Fehler im Download entdeckt (und sei es nur ein einzelnes fehlerhaftes Bit). Hast du da andere Informationen?

[IMJens]

Das mit dem Hash-Wert ist schon richtig. Aber dafür werden nicht alle Bits oder Bytes komplett mit berechnet. Beim Hash-Wert werden verteile Bytes ausgelesen und daraus dann der Hash-Wert errechnet. Das ist zwar nicht 100%ig genau, aber es hat sich in langen Versuchsreihen gezeigt, dass diese Querschnitts-Berechnungen immer eindeutige Werte ergeben, welche dann auch in einem Vergleich ziemlich aussagekräftig sind. Das Problem hierbei ist dann aber, dass die Bereiche zwischen diesen Prüf-Bytes überhaupt nicht berücksichtigt werden und selbst gelegentlich Bit-Fehler in den Berechnungs-Bytes unerkannt bleiben können.

Überleg einfach mal von der praktischen Seite:

Wie lange braucht so eine OTRKEY-Datei, wenn sie z.B. innerhalb Deines Rechners kopiert/verschoben wird? Und wie lange benötigt diese Prüfung?
Diese Prüfung ist weit, weit schneller, als Kopier-Operationen, bei denen auf jeden Fall jedes einzelne Bit ausgelesen wird. Ergo kann niemals in der kurzen Zeit die gesamte Datei ausgelesen (und dann auch berechnet) werden.

Jetzt ist wohl klar, weshalb nicht alle Fehler erkannt werden können. Allerdings ist dies Methode bei massiveren Fehlern wirklich effektiv.