Beiträge von Skiller

    Ehrlich gesagt, ich kann mich nicht erinnern, dass Gubel mehrmals erwähnt haben soll, dass der ADVC 300 ab 2005/2006 mit der NX identisch sein soll – und ich verfolge das Thema von Anfang an und habe aktiv mitgeholfen. Bitte Quelle zitieren.

    Und die Jitter-Korrektur der NX ist nicht genauso wie beim Panasonic ES10/EH52/EH60 (von Gubel als "alte Wandler" bezeichnet)!
    Sie ist vergleichbar oder etwas besser als die der Geräte ES15/ES20/EH56, sowie alle Modelle mit HDMI (EH65, EH575, usw...). Die haben alle dieselben Wandler ("neue"). Hier, hier und hier nachzulesen.


    Auch Color shift und Color drooping gibt's mit dem 300er nicht

    Wenn man aber auf dem Band schon einen Color-Shift hat, muss man den nachträglich korrigieren – und da ist 4:2:0 ein echtes Problem, sofern der Shift nicht nur horizontal ist. Wurde ein Band von einem anderen überspielt hat man alleine schon durch das PAL-Verfahren einen vertikalen Color-Shift nach unten.

    Ich glaube, mit der Meinung, dass der ADVC 300 besonders gut ist (das bezieht sich auf den vom Hersteller sogenannten TBC und die Filter), stehst du ziemlich alleine da. Vielleicht war er das vor >10 Jahren, verglichen mit dem, was man damals an Alternativen hatte. Aber heute sieht das ganz anders aus.

    Objektiv ist DV generell – insbesondere für Restaurationsarbeiten – eine schlechtere Ausgangsbasis als unkomprimiertes 4:2:2. Wie groß der Unterschied ist, muss jeder für sich selbst entscheiden. Ich sage jedenfalls nicht, dass DV schlecht ist, sondern nur, dass es nicht optimal ist.


    Zum Beispiel dieser DePulse-Filter für Avisynth gegen Fische von schlechtem Sat-Empfang.

    Den gibt's hier. Der ist für alle Fische (auch Kometen oder Drop-Outs genannt) generell geeignet, egal ob von Sat oder analogen Bandaufzeichnungen.

    Ein eben gerade von mir durchgeführter Test mit VirtualDub 1.10.4, Deshaker 3.1 (Motion Smoothness=0, sodass Deshaker praktisch nichts tut) und einem YUY2 Video (Color Depth Settings: Auto und YUY2 getestet) hat mit Subtract(a,b).Tweak(sat=200) gezeigt, dass das YUY2-Video nach Deshaker und dem Abspeichern als uncompressed YUY2 nicht mehr mit dem identisch ist, was am Anfang reingegangen ist. Es muss daran liegen, dass irgendwo in der Kette "heimlich" zu RGB gewandelt wird, auch wenn am Ende wieder YUY2 rauskommt, was das Ganze natürlich verschleiert.

    Überrascht mich aber nicht, denn auf der Seite des Autors findet man auch keinerlei Hinweise darauf, dass YUV mittlerweile unterstützt wird. Aber ich finde das nicht sonderlich schlimm.

    Edit: Führt man denselben Test mit einem RGB32-Video durch, so sind beide Videos (vor und nach Deshaker) laut Subtract exakt identisch – es liegt also wirklich daran, dass Deshaker nur in RGB arbeitet.


    Aber Deshaker für VirtualDub ist meiner Meinung nach der beste Entwackler, da kommt DePanStabilize nicht ran – besonders nicht, wenn man die ganzen hübschen Zusatzoptionen von Deshaker nutzt, die den Rand verschönern, ohne extrem ins Bild zu zoomen. :)

    Also in YV16 arbeitet QTGMC bei mir nicht korrekt, und so weit ich weiß wird auch nach wie vor tatsächlich nur YUY2 (neben YV12) unterstützt – war also zu erwarten.

    Gerade getestet mit "v3.33s (mod) 2016 01 19": YUY2 alles normal; YV16 Chroma völlig fehlerhaft (wie in frank2000s Screenshot), aber keine Fehlermeldung.

    naja, Tonversatz kann man auch in der Nachbearbeitung wieder anpassen, sehe ich daher nicht ganz so krittisch.

    Grob...ja. Ich behaupte mal, wenn man sich Mühe gibt, könnte man es auf etwa 100 Millisekunden genau bekommen, nachdem man minutenlang rumfrickelt und eine geeignete Stelle im Capture gefunden hat, aber genau (also nahezu 0 Millisekunden) kann man das ohne Sync-Test nicht anpassen.

    Und so groß sind die beiden Delays nicht, um die es gerade geht, dass man das "blind" ohne Sync-Test im Capture korrigieren könnte. Dann kannst du es auch ganz ignorieren. Das sind bei mir immer so +50 bis +120 Millisekunden, also meiner Meinung nach – auch weil der Ton voreilt – durchaus bemerkbar. Daher nie ohne Sync-Test.
    Es nachträglich "blind" zu korrigieren ist ungenau und dürfte auch länger dauern als den Sync-Test mitzucapturen und daran den Delay abzulesen.

    Was für Einschränkungen hab ich, wenn ich statt mit MediaExpress nun mit VDub capture?

    Wenn du VirtualDub nimmst, wird empfohlen vor (und optional auch nach) jedem Capture einen Sync-Test ins Capture aufzunehmen, da laut Gubel (und meiner eigenen Erfahrung) bei der Verwendung von VirtualDub mit der Intensity bei jedem Capture am Anfang ein kleiner Delay des Audios auftritt, der bei jedem Capture unterschiedlich ist. Außerdem würdest du mit dem Sync-Test auch den kleinen ebenfalls jedes Mal unterschiedlichen Audio-Delay, der vom DMR selbst erzeugt wird, ausmerzen (letzterer tritt also auch über MediaExpress auf). Beide sind für sich eigentlich zu vernachlässigen, aber können sich in ungünstigeren Fällen addieren.

    Ich selbst benutzte nur VirtualDub und mache bei jedem Capture einen Sync-Test.


    Ich zitiere mal Gubel

    Inzwischen habe ich auch die Sache mit dem Sync-Test weiter perfektioniert:
    Ich stelle einen einfachen DVD-Player mit der Schwarz-Weiß-Test-DVD nebendran (hier benutze ich gerade den ES10 dafür). Dort muss man dann 2x ein Videosignal abgreifen (benutze hier 1x den FBAS-Cinch und einmal den Y-Komponent). Das kommt dann auf die Front-AVs vom VHS-Recorder (1x auf Video und 1x auf Audio). Mit einem Doppelstecker geht es natürlich auch.
    Der VHS wird auf den Front-AV-Eingang gestellt, d.h. bevor ich die Kassette starte, geht das Testsignal vom DVDP automatisch durch auf den EH585.

    Genauso mache ich es auch (allerdings mit Doppelstecker/Y-Kabel am Composite-Ausgang eines beliebigen DVD-Players). Mehraufwand durch den Sync-Test: minimal.

    Ich persönlich verwende zum Herunterskalieren am liebsten den oftmals (wie ich finde) unterschätzten Spline16Resize, weil er arm an Ringing-Artefakten ist und dennoch deutlich schärfer als z.B. Bicubic mit den Standardwerten für b und c.

    In diesem Thread http://forum.gleitz.info/showthread.php…erung-TBC/page6 ,schreibt doch Gubel im letzten Post von internen TBC's der "Kathegorie 3" die auf Jitter-Korrektur speziell ausgelegt sind und das Bild nahezu 100% stabilisieren.

    Das mit der Jitter-Korrektur gilt aber auch (und gerade!) für Line-TBCs. Wenn es um die Jitter-Korrektur geht, reicht ein Line-TBC völlig – eher ist es bei externen Vollbild TBCs nicht selten so, dass sie keine Jitter-Korrektur durchführen, sondern nur die Sync-Impulse komplett neu generieren (dazu muss ein ganzer Frame zwischengespeichert werden, ergo erneuern Line-TBCs diese dagegen nicht). Mit Vollbild TBCs in Videorecordern habe ich aber keine Erfahrung, da fast alle mit TBC eben einen Line-TBC haben.

    Aber wenn du sowieso mit einem Panasonic DMR-EH digitalisierst, wird ein Vollbild TBC gar nichts bringen. Und auch ein interner Line-TBC kann bei Bändern in gutem Zustand abgeschaltet werden, da der Panasonic eine eigene brauchbare Jitter-Korrektur hat.

    Also, meiner Meinung nach brauchst du keinen Vollbild-TBC, weder intern noch extern. Suche dir dein Wiedergabegerät lieber nach anderen Kriterien aus.

    Reinigungskassetten sind nicht sonderlich empfehlenswert. Erstens weil sie nur bei leichten Verschmutzungen helfen und zweitens weil sie (besonders die trockenen) abrasiv wirken. Wenn da wirklich eine schmierige dicke Schicht auf dem Längsspurtonkopf klebt, wirst du mit einer Nassreinigungskassette den Schmutz eher noch im Laufwerk verteilen.

    Wenn du den Längsspurtonkopf mit einem Wattestäbchen reinigst, ist es fast unmöglich die Videoköpfe dabei zu beschädigen, denn die liegen in ein paar Zentimetern Entfernung auf der rotierenden Kopftrommel und müssen dazu nicht angerührt werden.

    Schau dir mal hier die Teile in einem Laufwerk an. Die Nummer 6 ist der Längsspurtonkopf.
    https://de.wikipedia.org/wiki/Videoreko…s_VHS-Laufwerks

    Die eigentlichen Spiele werden nicht mit Kameras von ARD/ZDF gefilmt, sondern mit den dort heimischen (Kanada = 60 Hz/NTSC), ergo sind die Spiele eine Normwandlung.

    Dasselbe war auch bei der Herren-Fußball-WM letzten Sommer in Brasilien der Fall. Ist eigentlich immer so, betrifft nicht nur Fußball.

    Wo soll der subjektiv große Verlust herkommen, wenn ich die 2 zusammengehörigen Halbbilder mit SelectEven() zu einen Vollbild mache?
    Ohne SelectEven() habe ich quasi jedes Vollbild fast doppelt. Ich arbeite nur mit p25 .

    Ich habe mich aber auf die AVCHD Camcorder-Aufnahmen von truthy in 50p bezogen. Mit SelectEven() schmeißt man in dem Fall die Hälfte der Bewegungsauflösung weg um auf 25 fps zu kommen.


    Also bleibt leider eh nur die Lösung mit 25p.

    Was ist mit 720p50? Das läuft überall, wo auch 1080p25 läuft.

    Also bei DVD-2&3 ohne SelectEven()/mit 50fps statt 25fps läuft irgendwas falsch.

    Ja, falsche Field Order. Deine DVDs sind alle TFF (Top Field First). Füge mal vor QTGMC AssumeTFF() ein.
    Ist aber komisch, da DGDecode normalerweise die korrekte Reihenfolge an AviSynth weitergibt.


    Interlaced encodieren und zb einen modernen SmartTV (und keinen BluRayPlayer) deinterlacen & skalieren lassen fällt für mich weg.

    Wieso eigentlich? Die Deinterlacer in Fernsehgeräten sind heute ziemlich gut, oft kann man an der Bildqualität gar nicht mehr erkennen, dass das Video eigentlich interlaced ist und nicht 50p.


    Da muss ich zb unsere sehr guten 1080p50 AVCHD Progressive Aufnahmen wieder nach 25p umwandeln

    Würde ich persönlich nie machen, weil das Weglassen der Hälfte der temporalen Information subjektiv einen größeren Verlust darstellt, als das Weglassen der Hälfte der (wohlgemerkt maximalen aber mit einem normalen Camcorder nicht erreichbaren) spatialen Information – beim Verkleinern von 1080p50 auf 720p50. Ich würde auch 1080i als Option sehen.

    Jedes Sample ist von einem anderen Film - einer anderen DVD.

    Ah, das erklärt es natürlich. :)


    Mit FieldDeinterlace oder TIVTC?

    Weder noch. Du hast hier nur 3 Möglichkeiten.

    1) Deinterlace (z.B. QTGMC) ohne SelectEven, 50 fps Ergebnis und so lassen
    2) Interlaced lassen und während der Wiedergabe zu 50 fps deinterlacen
    3) Wie 1) und anschließend Srestore anwenden.

    Srestore versucht die originalen 23,976 fps wiederherzustellen, indem zunächst die Blends durch Deblending entfernt werden und dann auf die ursprüngliche Framerate dezimiert wird.

    Letzteres kann gut funktionieren, oder auch nicht. Wenn du nicht riskieren willst, dass dir durch Srestore graue Haare wachsen, dann bleibe bei 1) oder 2), aber einen Versuch ist es Wert. ;)


    Das Erste scheint mir zumindest eh schon progressiv zu sein, obwohl die info interlaced anzeigt ... ich seh auf jeden fall keine linien mehr nur starkes Bildrauschen.

    Ja, wenn es um Interlace geht, dann traue immer nur deinen Augen und nicht dem, was Tools sagen. Tools wie MediaInfo zeigen dir nur die Flags des Streams an, können dir aber nicht sagen, was wirklich drin ist. Das erste wurde, obwohl progressiv, einfach als interlaced encoded, was häufig so gemacht wird.

    Sample 2 und 3 sind Normwandlungen eines NTSC-Masters, erkennbar am Fieldblending.

    Das heißt, dass man das NTSC-Master (mit 29,97 fps und Telecine) so zu PAL gewandelt hat, als ob es sich um eine normale Videoaufnahme mit 60 jeweils unterschiedlichen Fields pro Sekunde handelt. Das Ergebnis ist zwar anschaubar (und vor allem billiger, als ein reinrassiges PAL-Master zu erstellen), aber eine qualitativ schlechtere Lösung.

    Interessant, dass Sample 1 dagegen offenbar per Speedup gewandelt wurde. Stammen die Samples alle aus demselben Film oder derselben Episode?