Zeitabweichung zwischen Bild- und Tonsample - Was ist die Ursache?

[AB-AndreasBeck]

Hallo Leute,

ein Problem, das nicht direkt etwas mit m.objects zu tun hat - ich hoffe aber, dass ich hier jemanden finde, der mir die Sache erklären kann.

Für ein wissenschaftliches Projekt muss ich aus bestimmten Gründen Videobild und Ton getrennt aufnehmen und später zusammenführen. Als Tonrekorder verwende ich einen FAME HR-4. Der Ton wird als MP3-Datei gespeichert.

Nun muss ich feststellen, dass - obwohl synchron gestartet und gestoppt - Bild- und Tonsequenz unterschiedliche Längen haben. In 60 min. macht der Unterschied 24 Sekunden aus, um die die Tonaufnahme beim Abspielen zu lang ist (verschiedene Player ausprobiert). Die Videoaufnahme ist echtzeitsynchron.

Es geht mir jetzt nicht um die Frage, wie dies nachträglich korrigiert werden kann. Mich interessiert: Wo ist die Ursache dieser Abweichung zu suchen? Im MP3-Verfahren? Oder am Aufnahmegerät? Ein Fehler oder einfach nicht zu vermeiden?

Liebe Grüße

Andreas

[Dirk Rosenthal]

Hallo Andreas,
Ich kann auch nur vermuten.
Mit welchem Daten wurde das Video aufgezeichnet?
Ich denke mal mit 30 o. 60 B/sec., das könnte beim abspielen in unserem Stromnetz mit 50 Herz zu
den von dir beschriebenen Abweichungen in Verbindung mit der externen Tondatei kommen.

Falls tatsächlich mit 30/60 B/sec. aufgezeichnet wurde könnte eine Videoaufzeichnung mit 25 bzw. 50 B/sec. für Abhilfe schaffen.

Bin kein Profi in dieser Sache, wie gesagt, sind so meine ersten Vermutungen.

[AB-AndreasBeck]

Hallo Dirk,

danke für den Erklärungsversuch.

Aber wie schon ausgeführt: Das Problem liegt ganz offensichtlich beim Tonsample:

Bild- und Tonaufzeichnung synchron (rechter Daumen - linker Daumen) gestartet und nach exakt 60 min. ebenso wieder gestoppt.

Länge des Videoclips: 60:00 min
Länge des Tonsamples: 60:24 min (sowohl Angabe in den Dateieigenschaften als auch in der Anzeige in der Zeitleiste diverser Software-Player)

Dass der MP3-Recorder verzögert die Aufzeichnung beendet, kann ich ausschließen - nicht um 24 sec. Bei 1-2 sec. hätte ich den Fehler dort vermutet.

Da die endgültige Aufzeichnung viele Stunden dauern wird, wäre eine Korrektur der Tonlaufzeit in m.objects oder einem anderen Programm zwar möglich, aber hartes Brot.

Noch eine Idee?

Grüßle

Andreas

[mk-will]

Hallo, Andreas,

ist die Aufnahme zu lang oder fängt sie zu früh an?
Hast Du auch die Tonaufnahme von der Kamera?
Mal vergleichen, wo das Problem liegt.

Falls die Aufnahme des Fame zu früh anfängt: sieh mal im Handbuch nach, ob das Fame HR-4 evtl. mit einem Aufnahmepuffer arbeitet.

Gruss
Stephan

[AB-AndreasBeck]

Hallo Stephan,

vielen Dank auch Dir fürs Mitdenken. Der Videoton stimmt natürlich - kann ich aber leider nicht verwenden.

Nein, es ist ganz einfach so: Der externe Ton beginnt synchron und hinkt immer weiter nach, je länger das Abspielen der Aufzeichnung fortgeschritten ist.

Leider habe ich kein anderes Aufnahmegerät, so dass ich den MP3-Recorder nicht mit einem anderen Gerät vergleichen kann. Den Fame HR-4 habe ich bisher immer benutzt, um Originaltöne für Diavorträge einzufangen. Da gab es das Synchronisationsproblem nicht.

Bei der Aufgabe handelt es sich im Prinzip darum, Koinzidenzen zwischen Tonereignissen und Veränderungen im Videobild, die irgendwo über Stunden auftreten können (oder auch nicht) zu finden. Deshalb bin ich auf die Synchronität angewiesen.

Eine Videokamera, die bei stark reduzierter Bildrate (z.B. 1 fps, aus Gründen der resultierenden Dateigröße) trotzdem gleichzeitig den Ton in hoher Qualität aufnehmen kann, wäre natürlich ideal. Habe ich aber leider nicht zur Verfügung.

Immer noch ratlos

Andreas

[mk-will]

Hallo, Andreas,

das Problem ist also, daß die internen Uhren/Taktgeber der beiden Geräte nicht synchron laufen (ein übliches Problem).

Lösen läßt sich das nur, in dem entweder ein externer Taktgeber für beide Geräte zum Einsatz kommt oder daß eines der beiden Geräte als Taktgeber für das andere Gerät verwendet werden kann.

Mußt Du in den Handbüchern nachsehen, ob eine solche Möglichkeit vorgesehen ist.

Frage am Rande:
Weshalb kann der originale Videoton nicht verwendet werden?

Gruß
Stephan

[AB-AndreasBeck]

"das Problem ist also, daß die internen Uhren/Taktgeber der beiden Geräte nicht synchron laufen"

Das ist wohl die einfachste Erklärung für das Problem - und damit nach Ockhams Rasiermesser die vermutlich richtige.

Das Fame ist also nicht konstruiert, um echtzeitsynchrone Tonaufnahmen zu erstellen. Er hat auch keine interne Uhr, Tondateien werden ohne Datum und Uhrzeit gespeichert, was mich schon oft gestört hat. Samples lassen sich nach Tagen und Wochen manchmal kaum mehr einem bestimmten Ereignis zuordnen - ein echtes Manko.

Rest siehe oben ;-)

Herzlichen Dank noch mal.

Andreas

[m.objects]

Hallo Andreas,

die Ursache scheint mir hier ja bereits zutreffend benannt worden zu sein.
Als einfache Abhilfe bietet sich an:

- Audio-Stream mit dem T-Objekt auf 100.67% Geschwindigkeit einstellen (läuft dann 3599.88 statt 3624.00 Sekunden) oder
- Video-Stream mit dem T-Objekt auf 99.34% Geschwindigkeit einstellen (läuft dann 3623.92 statt 3600 Sekunden)

Die Rechnung, die dahinter steckt:
Prozentwert für das T-Objekt = Länge des Streams, der mit dem T-Objekt skaliert werden soll / Länge des anderen Streams * 100
Bsp: 3624s / 3600s * 100 = 100.67% (gerundet auf 2 Nachkommstellen)

Wenn die Bildwiederholrate des Wiedergabegerätes der Framerate des Videos (oder einem Vielfachen davon) entspricht - also z.B. Projektor mit 60 Hz und Video mit 30 fps - empfehle ich die Skalierung des Audiostreams anstelle des Videostreams.

Mit freundlichem Gruß
Steffen Richter

[AB-AndreasBeck]

Hallo Steffen,

vielen Dank - genau so habe ich das schon gemacht.

Aber es ergibt sich eine weitere Schwierigkeit: Das T-Werkzeug ändert zwar die Taktgeschwindigkeit das Audiosamples, nicht aber dessen Länge (nach "Tondatei neu abmischen" und speichern als neue MP3-Datei), d.h. mit einem Korrekturwert <100% wird mit Stille aufgefüllt (weil die Länge sich nach der Hüllkurve richtet).

Gibt es eine Möglichkeit mit m.objects, mit/neben dem T-Werkzeug auch gleichzeitig die Hüllkurve anzupassen? Manuell natürlich schon, aber außer dem Zusatzaufwand besteht dann eine weitere Fehlermöglichkeit, weil meine Audiosamples unterschiedliche Länge haben und meist hauptsächlich aus Stille bestehen (und somit das originale Ende nicht immer aus der Grafik erkennbar ist).

Eine Alternative wäre ein externes Programm, das sich mit den Korrekturparametern aus einer Batchdatei aufrufen ließe. Dann hätte ich ohne viel Klickarbeit die "richtige" MP3-Datei und könnte die dann in MO importieren. Für MP4 hatte ich mal so was - aber MP3s ließen sich damit nicht bearbeiten.

Kennt jemand eine solche externe Lösung?

Andreas

P.S.: Bevor erneut Fragen nach dem "warum" auftauchen: Wie ich eingangs geschrieben habe, geht es mir hier nicht um die Erstellung einer (einmaligen) Show, sondern um eine regelmäßig wiederkehrende Aufgabe, die so weit wie möglich automatisiert werden sollte. Entscheidend ist die Tonaufnahme, der Videoclip dient nur zur Identifizierung bestimmter akustischer Ereignisse.

[m.objects]

Hallo Andreas,

zunächst mal:
Ich hatte die Berechnung weiter oben leider genau falschherum beschrieben (und nun korrigiert). Mit dem T-Werkzeug modifiziert man ja nicht die Dauer, sondern die Geschwindigkeit, also muss die Korrektur genau anders herum erfolgen. Ich bitte um Entschuldigung.

In diesem Fall (da das Video ja offenbar für die Präsentation später nicht entscheidend ist) würde ich in jedem Fall das Video mit dem T-Objekt (also mit einem Wert < 100%) anpassen. Dann können die Audio-Hüllkurven unangetastet bleiben. Falls das Video für Dich wichtige visuelle Merkmale hinter dem ursprünglichen Ende enthält, brauchen lediglich die zwei letzten Anfasser nach rechts gezogen zu werden. Das Ende liegt dann genau dort, wo ein senkrechter roter Balken sichtbar wird.

Mit freundlichem Gruß
Steffen Richter

[AB-AndreasBeck]

Hallo Steffen,

damit würde ich aber gleichzeitig die direkte Zeitreferenz über die Videoframes aufgeben. Nicht ausgeschlossen, dass ich die nachträglich noch brauche.

Zwischenzeitlich habe ich aber die allereinfachste Lösung entdeckt: Samplefrequenz der Audioaufzeichnung von 48 auf 44,1 kHz ändern - und alles passt.

Die Erklärung würde mich noch interessieren.

Ansonsten: Ganz herzlichen Dank an alle, die mitgedacht haben.

Schöne Pfingsten

Andreas