V4 Capture Tool sehr sensibel

    Hallo zusammen,


    auch wenn es nach den aktuellen SoFo/Sony News nicht mehr so relevant zu sein scheint (jedenfalls mit der Hoffnung auf eine baldige Korrektur) hier noch ein Hinweis, der sich aus meinen Test bezüglich des Preview/Loop-Selection Phänomens ergeben hat.


    Um der Sache, die ich ursprünglich auf den Einsatz des ScLive bezogen hatte weiter nachzugehen, habe ich einige Tapes mit dem V4 Capture Tool eingelesen. Bei einem Band sprang die Anzeige der captured location nach einem Clip wieder auf 00:00:00;00. Auch in den folgenden Clips konnte V4 nicht wieder synchronisieren. Man kann dann den Einleseprozess nicht mehr mit Stop beenden, sondern muß das Programm abschießen, da es nicht mehr reagiert. (habe ich bei V4 sonst noch nicht erlebt)


    Die Clips wurden zwar bis zum Abschuß auch weiter auf die Platte gezogen, da aber das Programm abgebrochen wurde konnte der Logging Prozess nicht mehr durchgeführt werden, bei dem V4 offensichtlich die Date/Time Stamps in die AVIs bringt. Diese Info ist normalerweise im MediaPool sichtbar - nicht aber bei diesen Clips (auch nicht bei denen vor dem SynchronisationsProblem).


    Dabei ist mir auch aufgefallen, daß die von V4 erzeugten Files ca. 50kB größer sind als die mit ScLive aufgenommenen. ScLive hat die Date/Time Info aber nicht im entspechenden Feld im MediaPool sondern nur optional im file Namen.


    Das Band bei dem V4 oben beschiebenes Problem hatte, kann mit ScLive völlig ohne Beanstandung eingelesen werden. Möglicherweise, wurde es mal aus dem Camcorder genommen und hat eine kleine Inkonsistenz im TimeStamp ??? die aber nur V4 zum 'Erliegen' bringt. Es ist absolut reproduzierbar - habe es schon 3 mal versucht, da es ganz zu Begin des Tapes auftritt.

    Kann es Sein, daß Du ein Timecodeloch auf dem Band hast? Dann springt der Timecode im Camcorder auf die 0 zurück. Das nimmt die Software begreiflicherweise übel. Wenn Du dem Band ab diesem Punkt einen neuen Bandnamen zuweist, geht es vielleicht besser. Also such das Loch und fang von dort neu an.
    ScLive verwendet nicht den Timecode, sondern den Datastamp auf dem Band, das sind 2 völlig unterschiedliche Bereiche.

    Zitat

    Original von AlexB
    Kann es Sein, daß Du ein Timecodeloch auf dem Band hast? Dann springt der Timecode im Camcorder auf die 0 zurück.


    Das könnte sein, aber da sollte V4 eigentlich nicht dran hängen bleiben. Ich würde mir wünschen, daß es entweder wie ScLive stabil weiter arbeitet oder aber wenigstens die Arbeit geordnet einstellt und den User informiert. Das ist softwaremäßig keine Heckerei. Was wenn so ein Loch nach 58 Minuten auftritt - alles für die Katz!

    Zitat

    Ich würde mir wünschen, daß es entweder wie ScLive stabil weiter arbeitet oder aber wenigstens die Arbeit geordnet einstellt und den User informiert. Das ist softwaremäßig keine Heckerei. Was wenn so ein Loch nach 58 Minuten auftritt - alles für die Katz!


    Das lässt sich in den Capture-Preferences einstellen.


    Die AVIs sind bei Vegas deswegen größer, weil Vegas nach AVI Type 2 captured. Da wird ein zusätzlicher Audiostream benutzt.

    Hallo Marco,


    Das lässt sich in den Capture-Preferences einstellen.
    Hab' ich noch nicht gefunden, steht das auf Euerer neuen Site?


    Die AVIs sind bei Vegas deswegen größer, weil Vegas nach AVI Type 2 captured. Da wird ein zusätzlicher Audiostream benutzt.
    ist bei ScLive einstellbar, ich habe da auch Type 2 eingelesen. Darin liegt der Unterschied also nicht, aber V4 bringt dort wohl Information unter, wie TapeName und Date/Time die dann im Media Pool genutzt wird.

    Das lässt sich in den Capture-Preferences einstellen.


    Zu finden unter Preferences "Advanced Capture" -> Enable DV Start Frame Verification


    Die AVIs sind bei Vegas deswegen größer, weil Vegas nach AVI Type 2 captured. Da wird ein zusätzlicher Audiostream benutzt.


    Auch der Scenalyzer erlaubt die Aufnahme von Typ2-Dateien. Bei nur 50Kb Dateigrößenunterschied glaube ich eher an unterschiedliche Header und Zusatzinformationen.


    hs

    Zitat

    Auch der Scenalyzer erlaubt die Aufnahme von Typ2-Dateien. Bei nur 50Kb Dateigrößenunterschied glaube ich eher an unterschiedliche Header und Zusatzinformationen.


    Äh, ja.


    Ist noch zu früh am Morgen, als das ich schon rechnen könnte ... ;-)))

    Holger,


    Enable DV Start Frame Verification ... for recaptures


    Bist Du da sicher, daß das beim ersten Einlesen eines Bandes genutzt werden kann?


    Für ein normales Capturing sind diese hier gezeigten Optionen nicht von Bedeutung.
    lese ich auf der neuen Vagas Site zum Advanced Capture.

    Enable DV Start Frame Verification ... for recaptures


    Nein du hast recht, das ist erst für das Batch-Capturing. Damit ist es möglich, über Timecodelöcher hinweg aufzunehmen, auf das normale Capturing hat das wohl keinen Einfluß.
    Ich habe übrigens gerade mal ein Band mit Löchern erzeugt, aber mein Vegas stürzt dabei nicht ab? Merkwürdig


    hs

    Die Lösung könte in diesem Fenster zu finden sein. Dort die Einstellung "Stop capture on dropped frames".


    Denn wenn ein Timecodesprung vorhanden ist, wird Vegas diese Datenlücke womöglich als "dropped frame" interpretieren.


    Check doch mal, ob diese Einstellung bei Dir aktiviert ist und deaktiviere sie in diesem Fall.

    Einmal editiert, zuletzt von Avalon ()

    Ja , so hab ich das auch bisher erlebt. Wenn an einem frame irgendwas fishy ist, kleiner Dropout oder so, fängt Vegas Capture normalerweise sofort eine neue Szene an - mit einem verpixelten ersten Frame. ScLive ist da zugegebenerweise friedlicher und fährt einfach drüber.

    Ich habe übrigens gerade mal ein Band mit Löchern erzeugt, aber mein Vegas stürzt dabei nicht ab? Merkwürdig
    Ich bin ja auch nicht sicher, ob das Problem durch Timecodelöcher entsteht, das hat Alex vermutet.
    Als Absturz würde ich es auch nicht bezeichnen, mehr als Hang - bei dem die Stopfunktion nicht mehr tut und das Programm dann nicht mehr reagiert.


    Was passiert denn bei Deinem Band mit der 'captured location'? Bleibt die nach dem Loch auf 0?

    Marco,
    'stop capture on dropped frames' war und ist bei mir an. Hat aber nicht angehalten und hatte auch keine dropped frames in der weiter laufenden Anzeige.


    Alex,
    ne neue Szene wäre ja toll, aber gerade das hat V4 ja nicht gemacht sondern hat beständig von da ab die 'captured location' auf 0 gehalten.

    Cutty,
    wir sind ja aufopferungsvoll am Wohle der Vegas-User interessiert, es ist aber fast unmöglich, jeden eigenartigen Fehler nachzubauen. Kommt das denn regelmäßig bei Dir vor oder nur bei dem einen Band?
    Was ist, wenn Du weiter hinten mit dem Capturen beginnst? Geht's dann, oder ist der Timecode überhaupt unterbrochen?

    Einmal editiert, zuletzt von AlexB ()

    Alex,
    hinter dieser Stelle funktioniert das Capturen auch mit V4. Und ich habe ja auch die Möglichkeit es mit ScLive ohne Probleme komplett einzulesen. Wenn ein solches Problem aber gegen Ende des Tapes auftritt wäre es doch recht angenehm dies im Vorfeld zu unterdrücken - wenn's denn mit einer Einstellung möglich wäre. Danke für Deine Aufopferung :wink:


    holger
    Ich habe übrigens gerade mal ein Band mit Löchern erzeugt,
    an der betreffenden Stelle hatte ich wohl (vor einiger Zeit) das Tape ohne IC aus der TRV900 genommen, um ein anderes anzusehen. Beim erneuten Einlegen benutze ich dann immer die END SEARCH Funktions, die normalerweise kein Timecodelöcher entstehen läßt. Also kein echtes provoziertes Timecodeloch. Kannst Du das nachvollziehen?

    Cutty,
    heißt das, daß die vorherigen Captures dann bei Dir verloren sind? Das ist lästig, müßte sich aber mit irgendeiner Einstellung im Capture ändern lassen. Bei mir reagiert es wie gesagt mit Abbruch des Files und Neuanfang.
    Um solche Scherze zu verhindern, spiel ich gerne ein paar Sekunden Schwarzbild hinter die aktuelle letzte Bandposition, bevor ich das Tape aus der Camera nehme. Nachdem das "End search" bei mir immer ein paar frames abschneidet, um ordentlich zu synchronisieren, hab ich mir das angewöhnt.
    Ich hatte aber gestern genau soein Band mit Loch, hab es für ganz andere Zwecke mit Szenenerkennung nochmal eingelesen (wollte schauen, ob ich mit 10sekunden min.cliplength capturen kann, und hab danach die Gegenprobe gemacht, ob es ohne cliplength überhaupt noch geht). Obwohl Bildsignal und Timecode zwischendurch komplett weg waren, wurden die Szenen danach wieder ganz normal gelesen, kein freeze, kein Programmabbruch, alles in einem Rutsch.

    Einmal editiert, zuletzt von AlexB ()

    Das sieht für mich dann aber so aus, als wenn das Problem nicht durch ein Loch entsteht. Leider habe ich z.Zt keine leeren Tapes ohne IC, werde mir ein frisches kaufen und es dann noch mal mit dem EDIT SEARCH zu rekonsturiren versuchen.


    Generell wäre es schon gut zu wissen, welchen Vorteil man bei Verwendung des V4 Capture Tools hat, wenn doch ScLive so brav alles einliest und man bei V4 Gefahr läuft am Ende das Programm abschießen zu müssen - ohne das abschließende Logging.

    Zitat

    'stop capture on dropped frames' war und ist bei mir an.


    Das meinte ich ja gerade. Schalte es doch mal ab, nur testweise.

    Hallo Marco,


    hab's natürlich sofort probiert. Merkwürdigerweise klemmt es jetzt ein paar Clips später, was mich vermuten läß, daß es nichts mit der Entnahme des Tapes zu tun hat. Zu Beginn wird die Current Location brav höchgezählt und wird dann plötzlich auf 0 (siehe Bild) gesetzt und das Capture Programm hängt. Der Refresh des Capture Duration Zählers erfolgt nur noch zäh.

    Mmh, sehr seltsam. Wobei mir gerade einfällt, dass diese Anzeige zu "Capture Duration" bei mir noch nie funktioniert hat, weder in der Version 3, noch in irgendeiner 4er-Version und unabhängig vom OS. Ich hab mich daran nie gestört, weil das Capturing selbst immer problem- und fehlerlos funktionierte.