Hallo, da sich hier doch einige klassische Videospezialisten tummel, möchte ich ein aktuelles Problem schildern, mit der Bitte um Hilfestellung: Immer mal wieder möchte ich von meinen alten Video-Kassetten einige Szenen digitalisieren. Auf Empfehlung habe ich mir mal einen rel. preiswerten USB-Grabber zugelegt, der wider Erwarten ein sehr gutes Bild liefert. Der Grabber liest das Bildsignal über 3 Cinch-Buchsen ein (1x Video, 2x Ton l/r, alternativ Bild auch über S-Video) und erzeugt als Ausgabeformat *.avi, Codec YUV2, 720x576 mit 25 Frames. Eine Minute grabben erzeugt so ca. 1 GB. Zum Nachbearbeiten (deinterlance + Ränder abschneiden) und schneiden nutze ich VirtualDub (ein super Programm). Scheinbar erzeugt der USB-Grabber (oder die Software) einen zeitlichen Versatz zwischen Bild und Ton, im konkreten Fall sind es 12 Frames oder 480ms, s. Bild. Das ist eine halbe Sekunde, der Versatz fällt im Bild sofort auf. Trotz mehrtägiger Beschäftigung mit VitualDub finde ich keine Möglichkeit, wie ich den Versatz manuell korrigieren könnte. In der Beschreibung beim Download von VirtualDub finde ich jedoch den Hinweis, "kann den Ton synchronisieren..." Dass das Programm in englischer Sprache gehalten ist, macht die Problemlösung nicht einfacher. Wobei ich mich auch frage, wie VirtualDub überhaupt erkennen kann, dass Bild und Ton nicht synchron sind. Arbeitet jemand mit VirtualDub und kann mir auf die Sprünge helfen? Download: http://www.chip.de/downloads/VirtualDub-32-Bit_12994844.html Gustav
Gustav K. schrieb: > Wobei ich mich auch frage, wie VirtualDub überhaupt erkennen kann, dass > Bild und Ton nicht synchron sind. Du bist der Erkenner und Korrigierer. Audio -> Interleaving -> Audio skew correction Übrigens weißt Du nun, warum die USB Grabber doch nicht so toll sind... (lustig wird es, wenn der Versatz im Wert wandert)
Man kann doch irgendwo im Audiomenü die Zeit in ms direkt eingeben. Je nach Versatz positiver oder negativer Wert.
Crazy H. schrieb: > Man kann doch irgendwo im Audiomenü die Zeit in ms direkt > eingeben. Je nach Versatz positiver oder negativer Wert. Wie Mhh schon schrieb: > Audio -> Interleaving -> Audio skew correction
Michael Bauer schrieb: > Gustav K. schrieb: >> Eine Minute >> grabben erzeugt so ca. 1 GB. > > Nicht Dein Ernst, für VHS-Qualität! Doch, er schrieb doch: Gustav K. schrieb: > erzeugt als > Ausgabeformat *.avi, Codec YUV2, 720x576 mit 25 Frames. Das ist normales AVI, hier werden also keinerlei Kompressionen angewandt. Kann schon hinkommen... Ließe sich aber mit einem Code beheben. Und grabben kann man auch sehr gut mit VirtualDub. Und zwar mit Codec. Ich habe den Verdacht, daß Gustav mit einem anderen Programm gegrabbt hat.
Der Mhh schrieb: > Audio -> Interleaving -> Audio skew correction Grmpf, ich sah wohl den Wald vor Bäumen nicht - oder das Programm hat so viele Einstellmöglichkeiten, dass man den Überblick verliert. Bei der Gelegenheit: Was macht die Einstellmöglichkeit darüber (Audio block placement), hier kann ich einstellen was ich will, es ändert sich am Tonversatz gar nichts > Übrigens weißt Du nun, warum die USB Grabber doch nicht so toll sind... > (lustig wird es, wenn der Versatz im Wert wandert) Habe mal 10min. einen laufenden Plotter aufgenommen, der Versatz wandert zum Glück nicht. An den Fahrgeräuschen und dem Absetzen des Stiftes kann man das gut sehen. Immerhin weiss ich jetzt, wieso die Filmemacher eine Klappe im Bild schlagen... > Ich habe den Verdacht, daß Gustav mit einem anderen Programm > gegrabbt hat. Stimmt, das Grabben in VirtualDub mit 720x576 ist hier etwas fummelig, oft kippt das Bild um, eine notierte Einstellung geht mal, mal geht sie nicht. Ein anderes Programm grabbt da zuverlässiger. Allerdings ist auch beim Grabben in VirtualDub ein Zeitversatz vorhanden, es entfällt nur die Fehlermeldung. Der Zeitversatz ist übrigens nicht konstant, bei verschiedenen Aufnahmen habe ich Werte zwischen 3 und 12 Frames gesehen. Das ist dumm, ich hatte gehofft, einen konstanten Wert ermitteln zu können, damit wäre das Problem mit dem Versatz aus der Welt gewesen. Ich werde also die einzelnen Szenen vom Band auch einzeln korrigieren müssen. Das wird fummelig. Mit was grabben die Profis? Gustav
Bernd S. schrieb: > Das ist normales AVI, hier werden also keinerlei Kompressionen > angewandt. AVI ist zunächst nur ein Containerformat für A/V Streams. Die Streams können dabei sehr wohl komprimiert sein.
Gustav K. schrieb: > Wobei ich mich auch frage, wie VirtualDub überhaupt erkennen kann, dass > Bild und Ton nicht synchron sind. Ist eher dein Job, der Versatz zu spezifizieren. Wobei eigentlich erst mit der Kombination aus VirtualDub und Avisynth die volle Leistungsfähigkeit erreicht wird.
A. K. schrieb: > Ist eher dein Job, der Versatz zu spezifizieren. Sicher, wurde ja auch schon genannt. Aber VirtualDub gibt ja eine Fehlermeldung aus (s. mein 1. Beitrag), die Zahl 12 muss ja irgendwoher kommen. Gustav
Gustav K. schrieb: > Sicher, wurde ja auch schon genannt. Aber VirtualDub gibt ja eine > Fehlermeldung aus (s. mein 1. Beitrag), die Zahl 12 muss ja irgendwoher > kommen. Es gibt 2 Startlinien, welche um 12 Frames versetzt sind. Diesen Umstand findet VD albern und moniert deswegen. (Es wird also nicht der Versatz im Filmchen angezeigt, sondern nur die ungleichen Startpunkte erkannt.)
A. K. schrieb: > Bernd S. schrieb: >> Das ist normales AVI, hier werden also keinerlei Kompressionen >> angewandt. > > AVI ist zunächst nur ein Containerformat für A/V Streams. Die Streams > können dabei sehr wohl komprimiert sein. Das weiß ich schon. Wie man eber an der Filegröße sehen kann, ist das hier umkomprimiertes AVI, also jedes einzelne Bild ohne Komprimierung auf die Platte geschrieben. Ich denke, wenn man das nachrechnet, kommt die Größe schon in etwa hin. Ich hatte mich nur etwas unglücklich ausgedrückt.
Bernd S. schrieb: > Wie man eber an der Filegröße sehen kann, ist das > hier umkomprimiertes AVI, also jedes einzelne Bild ohne Komprimierung > auf die Platte geschrieben. Habe mal wo gelesen, dass man beim Grabben möglichst unveränderte Einzelbilder einlesen soll, dann nacharbeiten und wenn das Filmchen fertig ist, einmal möglichst optimal komprimieren soll. Bei den 10 min. Plotterlauf hatte ich 13 GB auf der Platte, nach dem Konvertieren nach mp4 waren es gerade noch 42 MB, das ist ein Faktor von 310 - und das ohne sichtbaren Qualitätsverlust im Bild. Habe eben meine Szene von Videokassette gegrabbt und Glück gehabt, VirtualDub meckert nur 2 Frames an. Da am Anfang einer die Heckklappe zuschlägt, habe ich eine Klappe im Bild - und die passt perfekt. Scheint offensichtlich auch an der Signalquelle zu liegen, wie gross der Versatz beim Grabben wird. Die Signale der ersten Versuche (erster Beitag) habe ich direkt meiner analogen Videokamera entnommen. Aber noch was: Ich sehe im digitalisierten Bild, dass das Bild leicht gestaucht ist. Es ist höher als breit. Das damalige 4:3 TV entspricht ja einem Verhältnis von 1.33. Habe hier eine Videokassette mit Testbild drauf (damals aus dem TV aufgenommen) wenn ich nun das Testbild nach 640x480 digitalisiere (640/480=1.33), dann ist der Kreis im Testbild nicht rund, sondern ein Ei. Bei beiden Formaten ist das Seitenverhältnis 1.33, das digitale Bild ist jedoch gestaucht. Wie kann das sein? Gustav
Gustav K. schrieb: > Scheint > offensichtlich auch an der Signalquelle zu liegen, wie gross der Versatz > beim Grabben wird. Nein, liegt es nicht. Es liegt an den Ablenkungsmanövern von auf dem Rechner laufenden Prozessen. Gustav K. schrieb: > Habe hier > eine Videokassette mit Testbild drauf (damals aus dem TV aufgenommen) > wenn ich nun das Testbild nach 640x480 digitalisiere (640/480=1.33), > dann ist der Kreis im Testbild nicht rund, sondern ein Ei. Bei beiden > Formaten ist das Seitenverhältnis 1.33, das digitale Bild ist jedoch > gestaucht. Wie kann das sein? Weil das Bild eigentlich 768*576 Pixel beträgt. Wegen dem bei damaligen TV Geräten notwendigem Overscan musst Du mit 720*576 für ein rundes Ei aufnehmen. Damit bist Du aber wieder schon am Rande des Datenkollaps am USB Anschluss mit entsprechenden Nebenwirkungen... Die Reduzierung auf 640*480 kann durchaus hässliche Ergebnisse produzieren. Da könnte 360*288 das homogenere Bild ergeben (oder einer internen Lösung mit Vollbild den Vorzug geben).
Der Mhh schrieb: > Weil das Bild eigentlich 768*576 Pixel beträgt. Wegen dem bei damaligen > TV Geräten notwendigem Overscan musst Du mit 720*576 für ein rundes Ei > aufnehmen. Das erstaunt, sind dann alle digitalisierten Aufnahmen gestaucht? Ich überlege, ob ich meine Aufnahmen "entstauche". Dazu haben ich ein Testbild mit 768*576 mit einer analogen Kamera aufgenommen. Dann mit meiner Nachbearbungssoftware links und rechts so lange Pixel abgeschnitten (bei gleichem Bildformat von 720x576), bis ich im digitalisierten Bild einen runden Kreis habe. Allerdings lese ich nun was von "nicht quadratischen Pixeln" ... ?? Deshalb mal zwei Testbilder, beim rechten Bild sehe ich hier einen runden Kreis. Bei einem Display mit rechteckigen Pixeln ist möglicherweise der Kreis im linken Bild rund. Was seht ihr? Was macht Sinn? Gustav
:
Bearbeitet durch User
Gustav K. schrieb: > Was seht ihr? Was macht Sinn? Ich kann da nur für mich sprechen. Ich digitalisiere in 720*576 und egal ob das Ergebnis über Röhre oder LCD ausgegeben wird - Eier gibts nur aus dem Kühlschrank.
Habe es jetzt auch hinbekommen, das Testbild mit VirtualDub in 768x576 mit rundem Kreis zu erzeugen, obwohl das Eingangsformat nur 720x576 war, s. Bild. Es ist also alles möglich. Die Frage ist nur, welchen Weg schlägt man am Besten ein. Auf einer Röhre werden die digitalisierten Videos nicht mehr laufen, da keine mehr vorhanden ist. Ist es eigentlich normal, dass man am unteren Bildrand statt dem Bild einige flimmernde Linien sieht? Bei allen Kassetten mit Videoaufnhamen aus verschiedenen Quellen ist das so. Wobei die originalen Bänder der Kameras stehts einmal auf Kassette überspielt wurden. Der Mhh schrieb: > Nein, liegt es nicht. Es liegt an den Ablenkungsmanövern von auf dem > Rechner laufenden Prozessen. Habe jetzt von einigen Bändern einige Szenen gegrabbt, VirtualDub meldete immer einen Versatz von 2 Frames. Am Signalausgang der analogen Sony-Kamera war der Versatz bei sehr vielen Versuchen immer 12 Frames. Gustav
:
Bearbeitet durch User
Leider wird ein weiteres Problem sichtbar: Ein Band zeigt bei der Wiedergabe ein gutes Bild, das Ergebnis ist nach dem Grabben ebenfalls ein recht gutes Bild. Ein anderes Band ist in der Qualität vergleichbar, nach dem Grabben habe ich bei den Farben ein deutlich sichtbares Muster, vergleichbar mit einer 30° Kreuzrändel: http://ww3.cad.de/foren/ubb/uploads/weimerv/raendeltest.jpg Wenn ich versuche, dem Muster mit irgendwelchen Filtern zu Leibe zu rücken (z.B. blur), erhalte ich ein starkes Farbenflimmern. Alle Versuche, die Bildqualiät zu verbessern, gehen nach hinten los. Hat jemand eine Erklärung für dieses 30° Muster in dem Farben? Gustav
Gustav K. schrieb: > Ist es eigentlich normal, dass man am unteren Bildrand statt dem Bild > einige flimmernde Linien sieht? Leider ja. Ich lege beim umrechnen einen schwarz gefüllten Streifen darüber. (Video - Filters - fill) Gustav K. schrieb: > VirtualDub > meldete immer einen Versatz von 2 Frames. Am Signalausgang der analogen > Sony-Kamera war der Versatz bei sehr vielen Versuchen immer 12 Frames. Interne Lösung. Egal welche Quelle und Auflösung - null Versatz.
Gustav K. schrieb: > Ein Band zeigt bei der Wiedergabe ein gutes Bild, das Ergebnis ist nach > dem Grabben ebenfalls ein recht gutes Bild. Ein anderes Band ist in der > Qualität vergleichbar, nach dem Grabben habe ich bei den Farben ein > deutlich sichtbares Muster, Aufnahme beendet, anderes Band rein und Aufnahme wieder gestartet? Wenn ja, Rechnerneustart oder wenigstens Aufnahmeanwendung beenden und neu starten.
Das Muster siehr irgendwie nach Farbträger aus, der sollte eigentlich besser rausgefiltert werden. Ist dieses Muster auch in nicht farbigen Bereichen (Schwarz, Grau, Weiß), beim selben Band? Stammt diese Band von der selben Aufzeichnungs-Maschine, wie das Andere, das funktioniert? Vielleicht hilft das ja bei der Fehhlersuche. Mit freundlichen Grüßen - Martin
Gustav K. schrieb: > Ist es eigentlich normal, dass man am unteren Bildrand statt dem Bild > einige flimmernde Linien sieht? Bei allen Kassetten mit Videoaufnhamen > aus verschiedenen Quellen ist das so. Einige Zeilen vor dem vertikalen Synchronsignal schalten alle 2-Kopf Videosysteme die Köpfe um, das V-Sync Signal kommt dann vom gerade eingeschalteten Kopf. Durch das Umschalten entsteht ein leichter 'Skew' (Zeitversatz), auf den die meisten Grabber nicht schnell genug einrasten. Hilfe bringt hier nur eine Zeitbasiskorrektur, die vor dem Grabben das Signal zwischenspeichert und mit quarzgenauer Zeitbasis wieder ausgibt oder ein richtig hochwertiger Player.
Die flimmernden Zeilen kommen aber daher, dass der "noch aktuelle" Kopf bei 180Grad Umschlingung schon langsam den Kontakt zum Band verliert bzw. das schon bei der Aufnahme passiert ist. Eine Zeitbasiskorrektur braucht es beim Grabben eigentlich nicht, weil der billige Grabber genau das ist, was die sündteure TBC früher gemacht hat ;)
Der Mhh schrieb: > Ich lege beim umrechnen einen schwarz gefüllten Streifen darüber. > (Video - Filters - fill) Das wäre auch eine Lösung, ich mache mit Cropping den Rand an allen 4 Seiten ab (oben nur ganz wenig )und strecke dann mit resize wieder auf das ursprüngliche Format. Dabei darauf achten, dass ein Kreis rund bleibt. > Interne Lösung. Egal welche Quelle und Auflösung - null Versatz. Was heisst das jetzt genau? Andere Hardware, wenn ja welche? Das mit dem Versatz bleibt mir weiterhin ein Rätsel, denn VirtualDub meldet den Versatz weiterhin, selbst wenn ich am Anfang einigen Sekunden abgeschnitten und die Datei neu abgespeichert habe. Leienhaft beschrieben: da sind zwei Papierstreifen (Bild/Ton), am Anfang ist ein Streifen etwas kürzer als der andere. Nun schneide ich mit einer Schere den Anfang bündig ab, wie kann man immer noch erkennen, dass die beiden Steifen einen Versatz haben? Die Bilder könnte man theoretisch durchnummerieren, wie nummeriert man den Ton? > Aufnahme beendet, anderes Band rein und Aufnahme wieder gestartet? > Wenn ja, Rechnerneustart oder wenigstens Aufnahmeanwendung beenden und > neu starten. Zwischen den beiden Aufnahmen lagen Tage, der Aufbau war der gleiche. Martin Schlüter schrieb: > Ist dieses Muster auch in nicht farbigen Bereichen (Schwarz, Grau, > Weiß), beim selben Band? Ja, aber nur ca. halb so stark ausgeprägt. Richtig heftig wird es erst bei den Farben. > Stammt diese Band von der selben Aufzeichnungs-Maschine, wie das > Andere, das funktioniert? Vielleicht hilft das ja bei der Fehhlersuche. Also die Aufnahmen hat ein damiger Schulfreund mir seiner riesen Videokamera (Schultergerät) gemacht. Danach hat er das Band aus der Kamera auf eine seiner Kassette überspielt und das Kameraband gelöscht, um es für weitere Aufnahmen zu verwenden. Von seinem Videorecorder haben wir es dann auf meinen Videorecorder kopiert. Also eine Kopie einer Kopie. Zusätzlich wurde das Band nun auf einem anderen Videorecorder abgespielt. Trotzdem war das Bild noch rel. gut, wenngleich die Farben etwas nach rechts und unten "verrutscht" waren. Ein leichtes Farbenflimmern war bereits auf dem Band zu sehen. Sicher nicht die optimalste Ausgangssituation, es gibt aber leider keine andere. Georg A. schrieb: > Die flimmernden Zeilen kommen aber daher, dass der "noch aktuelle" Kopf > bei 180Grad Umschlingung schon langsam den Kontakt zum Band verliert > bzw. das schon bei der Aufnahme passiert ist. Diese Erklärung wäre für mich zumindest nachvollziehbar Gustav
Gustav K. schrieb: > Das wäre auch eine Lösung, ich mache mit Cropping den Rand an allen 4 > Seiten ab (oben nur ganz wenig )und strecke dann mit resize wieder auf > das ursprüngliche Format. Dabei darauf achten, dass ein Kreis rund > bleibt. Das macht das Ergebnis schlechter als "fill", da ein "resize" sich prinzipbedingt Bildinformationen ausdenken muss. Gustav K. schrieb: >> Interne Lösung. Egal welche Quelle und Auflösung - null Versatz. > Was heisst das jetzt genau? > Andere Hardware, wenn ja welche? Alter Rechner (Sockel A), alte Grafikkarte mit Videoeingang (Riva TNT2) und 2 große Festplatten (eine Quelle und andere Ziel beim umrechnen). Damals wurde die Videofunktion mit mehr Liebe behandelt. Gustav K. schrieb: > Das mit dem Versatz bleibt mir weiterhin ein Rätsel, denn VirtualDub > meldet den Versatz weiterhin, selbst wenn ich am Anfang einigen Sekunden > abgeschnitten und die Datei neu abgespeichert habe. Das ist ein "feature" der USB Lösungen. Gustav K. schrieb: > Also eine Kopie einer > Kopie. Zusätzlich wurde das Band nun auf einem anderen Videorecorder > abgespielt. Trotzdem war das Bild noch rel. gut, wenngleich die Farben > etwas nach rechts und unten "verrutscht" waren. Ein leichtes > Farbenflimmern war bereits auf dem Band zu sehen. Sicher nicht die > optimalste Ausgangssituation, es gibt aber leider keine andere. Dann liegt es leider an der schlechten Vorlage mit den Störungen, wenn sich sogar schon Laufzeitunterschiede von chroma und lumina über die Kopien aufaddiert haben.
Der Mhh schrieb: > Das macht das Ergebnis schlechter als "fill", da ein "resize" sich > prinzipbedingt Bildinformationen ausdenken muss. Stimmt, um einen Kreis rund zu halten, muss man sogar noch etwas mehr links und rechts abknapsen. Wenn ich allerdings die Input/Output-Fenster nebeneinander setze, kann ich keinen sichtbaren Unterschied erkennen. > Dann liegt es leider an der schlechten Vorlage mit den Störungen, wenn > sich sogar schon Laufzeitunterschiede von chroma und lumina über die > Kopien aufaddiert haben. OK, dann kann man nichts machen. Ich habe bei der Bearbeitung der Aufnahmen kein Filter aktiviert, starkes Farbenflimmern macht keine Freude. Habe mich mal zu "adaptivem Deinterlacing" etwas eingelesen, bei VirtualDub heisst das wohl "temporal smoother". Leider wird dabei der Ton unbrauchbar, gibt es eine Lösung, den Ton zu retten? Gustav
Gustav K. schrieb: > Habe mich mal zu "adaptivem Deinterlacing" etwas eingelesen, bei > VirtualDub heisst das wohl "temporal smoother". Welchen Filter ich verwende, kann ich im Moment nicht nachsehen (ich verwende den Rechner ausschließlich zum digitalisieren, daher steht er bei Nichtnutzung zugebuddelt im Schrank), dieser genannte ist es aber definitiv nicht. Gustav K. schrieb: > Leider wird dabei der > Ton unbrauchbar, gibt es eine Lösung, den Ton zu retten? Ich nehme den Ton im 48 kHz Format auf und bei jeder Berechnung (bis auf den Schluß, wo eine DVD draus wird) steht Audio auf "direct stream copy". Daher kann ich den Fehler auch gedanklich nicht nachvollziehen. Was bedeutet unbrauchbar in Deinem Fall?
Der Mhh schrieb: > dieser genannte ist es aber definitiv nicht. Also bei "temporal smoother" werden die letzten 1-8 Bilder mit die Berechnung den neuen Bildes miteinbezogen. Eine Einstellung auf 4 macht sich leicht positiv bemerkbar. Zwischen In- und Output Fenster wird zusätzlich ein zeitlicher Versatz sichtbar. Der Mhh schrieb: > Was bedeutet unbrauchbar in Deinem Fall? Der Ton macht schrapp-schrapp-schrapp ... Audio steht ebenfalls auf "direct stream copy" Gustav
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.