Beiträge von Herbert

Hi Arndt,

OK, dann muss ich mal morgen äh heute wenn ich ausgeschlafen habe mal die Sache nochmal anschauen.

Gruß Herbert

Ja aber mir geht es um die Drift deen Berechnung ich schon eigebaut habe, aber das ist noch ausgegraut mangels an praktischen Beispielen.

Gruß Herbert

Hi Ulrich,

ich warte ja noch, dass einer der 2 Kameras hat mal über mehrere Stunden oder Tage die auf ein bestimmtes Ziel fixiert, was sich gut zur Synchronisationsprüfung eignet. Dann stündlich die beiden Kameras für kurze Zeit einschalteten, mal die eine länger mal die andere mal eine 2mal aus ein während die andere läuft. Einfach total beliebig und chaotisch.
Allerdings die Minimalaufnahmezeit von 3 Sekunden nicht unterschreiten.

Ich hab bloß eine Kamera und müsste erst losziehen und noch eine ausleihen.

Gruß Herbert

Hi Arndt,

also ohne jetzt mal tiefer in die Bits und Bytes einzusteigen habe ich folgendes herausgefunden. (kann sogar mit meiner alten Demo dein Projekt öffnen.)
Das Problem ist vermutlich folgendes:
Deine Timeline ist auf 2h 51min begrenzt.
Laut Liste kommt der letzte Clip aber bei 03:06:14:17 also 3h 6min zu liegen.

Schade, dass EDIUS kein Gesicht hat! Würde mich mal interessieren wie dumm das guckt, wenn dem plötzlich ein Clip hinten von der Timeline fällt.

Also probier mal folgendes:
Schiebe den Clip cam1-0160.avi auf ca. 3h 10 min und speichere das noch mal.
Mal sehen ob Edius dann den Import schluckt.

Theoretisch kannst du aber auch alles von cam1-0135.avi bis cam1-0160.avi löschen weil da fast 3 Tage dazwischen liegen und nur noch mit cam1 gefilmt wurde.
Schade wenn die andern auch noch gefilmt hätten, wäre das gleich ein Fall für die Driftberechnung gewesen.
Aber du wolltest sicher einen Beweis haben ob das Tool nur auf die Uhrzeit schaut. Dann wäre es reingefallen den am 3. Tag wurde vormittags um 11 Uhr gefilmt und sonst nur nachmittags und abends. Aber wie schon gesagt das juckt mein Tool überhaupt nicht – da kannst du auch einen Jahreswechsel mit drin haben.
Hier hat sich das zusammenschieben Feature bewährt weil man sonst ne fast 3 Tage lange Timeline bräuchte. :schal:

Bin gespannt ob dies das Problem war!

Gruß Herbert

Hi Arndt,

nun zu deiner Datei:
Kannst du so was nicht als Anhang verschicken, dass ich das unzensiert bekomme?
Dein Mailer baut da alle 80 Zeichen einen Zeilenumbruch ein und der macht das ganze schwer lesbar und auch in Excel müsste ich erst ein macro schreiben dass ich das Ding verwerten kann.
Also das ganze hat 250 Clips und liegt damit gerade mal auf einem viertel von dem was das Programm kann.

Pack mal bitte die Epj vor und nach MultiCamSync und die Multi.txt in eine Zip-Datei und schick mir die zu.

Ich kann die zwar mit Edius nicht öffnen aber versuchen den Fehler trotzdem zu finden.

Hier noch allgemeine Informationen zur Multi.txt:

Im Block 1 werden alle Clips aufgelistet in der Reihenfolge wie sie bearbeitet wurden.
Also Cam1 und alle zugehörigen Clips mit Zähler, Speicherort, Name, Dateigröße, Frames und framegenauem Datumscode.

Im Block 2 sind die Stellen aufgelistet wo alle Kameras aus waren und diese Pausen geschlossen wurden. (egal wie groß oder klein die Pausen waren)

In Block3 sieht man das Ergebnis der Synchronisation.
Es beginnt mit dem Zähler der die zeitliche Reihenfolge auf der Timeline von links nach recht anzeigt. Danach Datum, Uhrzeit und Frames wie oben. Dann kommt die theoretische Zeit auf der Timeline wo der Clip sitzen würde wenn man die Pausen exakt als Lücken belässt.
In der letzten Spalte sind die Zeiten wie der Clip nach Schließung der Lücken auf die Timeline kommt. (also das Ergebnis wie es dann an EDIUS übertragen wird.)

Gruß Herbert

Hi Dirk,

hast du mal geprüft ob die Verzeichnisse wie in dem vorher erwähnten CSV-Beitrag angegeben existieren?
Also bei XP müsste das gehen!

Gruß Herbert

aber wir haben jetzt eine besser Statistik!

Schick mir mal bitte die Multi.txt zu!

Gruß Herbert

Hallo Marco,

nein, es gibt überhaupt keine Vorschriften wie lang und oft eine Kamera laufen muss.
Nur dass man pro Kamera eine Spur braucht (nicht mehr und nicht weniger).
Die zweite Bedingung ist, dass die Position des 1. Clips jeder Spur für die Berechnung verwendet wird.

Gruß Herbert

Wenn man einen Händler zur Aussage nötigt bekommt man nur die Zusage: Für I/O geht die Storm. Ob ich mir so viel Snobismus, und das noch fern der Öffentlichkeit leisten kann?

Wenn das wirklich das Ende der Skalierbarkeit ist, dann werde ich mich wohl von einem der beiden trennen müssen.

Gruß Herbert

So nun hab ich den Fehler korrigiert und die Suchlogik noch mal verbessert.

Bitte die 0.9.3 runterladen!

Gruß Herbert

Hi,

habe tatsächlich die Timecodeerkennung verbessert, so dass der Timecodefehler der in einem meiner Clips aufgetreten ist korrigiert werden konnte. Andererseits habe ich dafür die Abbruchbedingen verschärft.
Muss ich dann doch wieder lockern.

Gruß Herbert

Hi Arndt,

hab eben eine neue Version hochgeladen. Die alte hat tätsächlich was im Header der epj - Datei zerschossen - ob dies dein Problem war kann ich nicht sagen.
Gib du die Antwort!

@all
Bitte nur noch die neue Version verwenden!

Gruß Herbert

Hi Dirk,

die Fehlermeldung ist nicht gerade aussagekräftig. In meinem Thread Edius in CSV gab es bei manchen Anwendern auch ähnliche Probleme. Lies mal dort nach.
Mein Verdacht ist, dass dem User die Rechte für die Installation der DLLs fehlen also bitte 1x als Administrator das Programm starten - dann müsste es auch normal laufen.

Welches Betriebssystem verwendest du?

Gruß Herbert

Hallo Arndt,

hatte deinen Beitrag auf der 2. Seite übersehen und daher auf den anderen geantwortet.

Also das hört sich schon gut an. :schal: :schal:

Wir sind also auf dem richtigen Weg.

Werde bald eine neue Version zum Download bereitstellen wo man noch detailierter sehen kann wie die Clips sortiert werden.
Auch den Gedanken mit dem Backup habe ich weiterverfolgt und mache jetzt eine entsprechende Backupkopie der alten Projektdatei.

Prizipiell gibt es unter 1000 Clips eigentlich keine Sperre im Programm aber es könnte sich ja ein Fehler eingeschlichen haben. Ich mache mich mal auf die Suche.
Ist halt doch noch eine Beta Version.

Aber wie ist so dein Eindruck bezüglich der Genauigkeit bei den 20 Clips?

Gruß Herbert

Hallo Arndt.

Zitat

so, ich hab jetzt erstmal von 3.5 auf 3.61 + hotfix und localize upgedatet. keine änderung mit dem alten projekt. dann unter neuem namen abgespeichert, auch keine änderung. habe dann aus dem bin die dateien neu in die timeline gezogen, nchadem ich nach datum sortieren ließ. keine änderung.

hätte ich nicht glauben können wenn da was anderes dabei rausgekommen wäre weil ich ja ein noch ältere Version benutzte. Also wenn das Problem an den unterschiedlichen EDIUS Versionen liegt, dann müsste es eher schlechter werden.

Zitat

ich werde jetzt die ersten 20 clips reinschmeissen. mal sehen,w as passiert.

Aber bitte erst nachdem du bei EDIUS über den Button Neues Projekt ein total leeres Projekt angelegt hast. (Nicht die alte Projektleiche unter neuem Namen verkaufen!)
(wir können es auch mit je 5 Clips probieren)

Zitat

übrigens, vielleicht nicht ganz unwichtig: alle clips wurden mit scenalizer live gecaptured (benutze ich immer).

Spielt keine Rolle. Wie man in Multi.txt erkennen kann steht hinter jedem Dateinamen ein gültiger und auch vernünftig aussehender Zeitcode.

MultiCamSync selbst arbeitet auch ordentlich. Nur beim zurückschreiben in die Projektdatei passiert noch ein unerklärlicher Fehler.

Deshalb müssen wir das Problem in eine handliche Größe bringen. Wenn es bei 5 Dateien je Spur auch noch existiert, dann packe bitte die EPJ und EWS- vor und nach MultiCamSync und auch multi.txt und multi.log in eine Zip- Datei und schicke sie mir zu.

Gruß Herbert

Hallo Arndt,

Zitat

übrigens wärs gut, wenn du das neue projekt mit einem neuen namen generieren würdest, damit man bei unlesbaren erzeugten projekten nicht mit leeren händen da steht. gottseidank hatte ich ein backup von dem epj, sonst hätte ich wieder ne stunde alles umfrickln müssen...

deshab habe ich in meinen 1. Beitrag geschrieben:

Zitat

In Edius das Projekt speichern. (Am besten noch einmal zusätzlich mit einem
anderen Namen mit dem Befehl Speichern unter )

Das ist dann das Backup! Warum das besser ist wie wenn ich eine neue Datei anlege erkläre ich mal wenn ich Zeit habe.

Muss jetzt weg. Habe daher nicht viel Zeit zum antworten.

Mach mal bitte ein neues ganz einfaches Projekt wo du nur die ersten 20 Clips von Cam 1 und die ersten 20 von Cam 2 nimmst
Damit erkennen wir dann ob es ein prinzipielles Problem von Edius ist.

Das geh doch ratz fatz.
Neues Projekt
Dann im BIN Clip 1 bis 20 markieren und auf die Timeline ziehen
Das selbe mit den ersten 20 von Cam2

Dann Clip 1 ausrichten

Speichern
und Speichern unter (als Backup)

Dann MultCamsync ausführen

Wenn alles OK dann Clips von Cam 3 dazunehmen.

Gruß Herbert

Hallo Arndt,

nein den ersten clip auch nicht schneiden. Der Clip der Kamera die zuerst eingeschaltet wurde liegt auf 0 (oder auch weg von null - falls du links ne Lücke möchtest).
Der Clip der Kamera die als 2. eingeschaltet wurde liegt aber auf jedenfall weg von Null

Schau dir noch mal mein Beispiel von oben an:
Kamera 2 wurde 49 Sek und 5 Frames vor Kamera 1 eingeschalte (kann man so genau auf der Skala nicht ablesen) deshalb beginnt VA1 mit einer Lücke von 1230 Frames (oder eben 49Sek und 5 Frames)
Es wird nichts geschnitten.

Würde Kamera 2 bei 1 minute beginnen, dann wäre der Start von Kamera1 bei 1 min 49sek und 5 Frames.

Der erste clip ist und bleibt auch fest (die Lücke links vom ersten Clip wird auch nicht aufgefüllt) alle andern Clips richten sich nach dem aus.

Gruß Herbert

Hallo Arndt,

jetzt liegt der Fehler im schwierigsten Bereich nämlich, das die Projektdatei geändert wurde, aber EDIUS sie nicht versteht.

Ich hoffe mal, dass dies nicht im Versionsunterschied zwischen unseren beiden EDUIS Versionen begründet ist.

Also jetzt kommt das anfangs von mir erwähnte Problem zum tragen, wenn zB die Reihenfolge der Clips nicht stimmt.
Das kannst du aber in der Multi.txt prüfen ob alle Zeiten pro Kamera ansteigen.

Ich hoffe mal, dass du keine anderen Elemente wie jpg oder dergl. auf der Timeline hast, weil wenn man die einen Elemente verschiebt, die anderen aber nicht, dann könnten die sich überlappen.
Oder wenn du kein neues Projekt genommen hast, sondern ein altes, in dem Clips bereits getrimmt sind. Dann liegt der Trimmpunkt evtl. außerhalb des Frames und dann versteht Edius (mit Recht) die Welt nicht mehr.

Daher mein dringender Hinweis: Nur ungeschnittene unveränderte Clips verwenden. Also nur ein neues Projekt wo die Clips nur hintereinander auf der Timeline liegen.

Bin aber eben dabei die Fehlerbehandlung und Ausgabe noch etwas zu verfeinern.

Gruß Herbert

Hallo Arndt,

wenn eine AVI-Datei hier mehrfach auftaucht bedeutet dies, dass mehrere Frames mit defektem Datumscode gefunden wurden. Andersrum gesagt die beiden oberen Dateien sind unproblematisch weil der Fehler nur bei einem Frame aufgetreten ist. Es könnte aber zu einer Fehllage um einen Frame kommen, deshalb wird jeder Fehler hier protokolliert.
Bei den 10 Fehlern von cam2 ist das schon übler, da muss ich nachschaun ob dies nicht schon als Abbruchkriterium definiert habe.

Du kannst mal in der .txt Datei nachschaun welche AVI-Dateien dort aufgeführt sind und mit welchem Datums/Zeitcode.

Kann mich erst morgen oder heute spät abends wieder melden.

Gruß Herbert

Hallo Arndt,

hier habe ich es mit einer AVI zu tun, die irgendwie anders aufgebaut ist. Aus irgendwelchen Gründen findet das Programm keinen Videoframe.
Hatte das Problem auch mal bei VEGAS.
Da ich keinen Codec benutze kann es schon mal vorkommen, dass wenn ich auf eine AVI-Datei treffe deren Aufbau von dem mir bekannten abweicht irgendwelche Merkmale nicht gefunden werden.

Schick mir mal bitte die LOG-Datei zu.

Gruß Herbert