freezer hat geschrieben: ↑Mi 08 Apr, 2026 16:09
So ganz kann ich Deine kritische Haltung hier nicht verstehen. Er sagt ja nicht, dass das schon das perfekte, fertige und zu bezahlende Tool ist, sondern dass es eine offene Beta ist.
Ich war nun auf der Startseite, auf dem Converter, und der About-Seite. Mehr gibt die Website nicht her. Nirgends finde ich das Wort "Beta". Auf der About-Seite sehe ich nur viel Buzz, dass das hier die Lösung für dieses nieschige Problem sei.
Davon ab bewerte ich eher den Output, und der ist wie oben beschrieben. Es ist halt Schade, wenn das Ergebnis nur an einer (eher nicht so wichtigen) Stelle besser als das ist, was man ersetzen will.
freezer hat geschrieben: ↑Mi 08 Apr, 2026 16:09
OTIO is eine Sackgasse, ich beobachte die Projektseite schon des längeren und es gibt seit ein paar Jahren kein Fortschritte, selbst die Abstimmungsmeetings sind seit 2 Jahren ausgesetzt.
War mir nicht bekannt, das natürlich schade.
freezer hat geschrieben: ↑Mi 08 Apr, 2026 16:09
CornerCut macht da nichts mit "undurchsichtigen" Methoden - ich habe ein kleines Testprojekt damit konvertiert und analysiert.
Ich vermute, bisher war ein Reverse Engineering von Projektdateien einfach sehr mühselig und zeitaufwändig - weswegen es wohl keiner gemacht hat. Aber mit einer guten LLM wie Claude Opus klappt die Analyse sehr gut, wenn man das systematisch angeht - Mustererkennung ist ja genau die Stärke der Dinger.
"Undurchsichtig" im Sinne von Blackbox - ich schicke ein Projekt hoch, ich lade eins runter. Ich kann zwar die Source und den Output checken, weiß aber effektiv nicht, was gemacht wurde. Und da es einerseits kommunizierte Features ignoriert und andererseits Metadaten meiner Files verändert, habe ich da keine "Durchsicht". Ob ein Log das ändern würde sei mal dahin gestellt.
freezer hat geschrieben: ↑Mi 08 Apr, 2026 16:09
Bei meinen ersten Analysen meiner .pproj Testdatei bin ich auf sehr viele Sonderfälle gestoßen, an die man erstmal denken muss. Die ganzen unterschiedlichen Timecodebasen sind ein Minenfeld, dazu dann alle möglichen Transformationsdaten und unterschiedliche mathematische Herangehensweisen sowie interne Konventionen. Das .pproj Format ist ja nicht über Nacht entstanden, sondern über Jahrzehnte und entsprechend komplex.
Das ist das Schöne an einer XML: sie ist sehr einfach. Es gibt einen Start TC, eine FPS Angabe, und davon ausgehend In- und Outpunkt startend bei 0.
Ich habe letzte Woche ein Tool programmiert, was man mit einer XML (oder einzelnen Dateien) füttern kann, und einem dann die animierten Metadaten die quasi nur die Hersteller-Tools zuverlässig auslesen als Nuke, Fusion, und AE Animation ausgibt, um sie in der Comp getrimmt und an der korrekten Stelle zu haben. Ist halt so radikal simpel, das machts ja auch ganz schön :)
freezer hat geschrieben: ↑Mi 08 Apr, 2026 16:09
Nun, zB kann man die komplette Ordnerstruktur des PPro Projekts inkl. der Clipcolors und Marker mitziehen - das geht auch mit FCP XML nicht.
In meinem Test hatte ich in Premiere keine Ordner angelegt, daher kann ich das nicht beurteilen - alle Clips waren aber blau, in Resolve waren sie dann Pink (also weder Default grün oder blau).
Das ist ein tolles Feature wenn Du das Projekt umziehen willst, um da weiter zu schneiden, wie schon erwähnt. Für einen klassischen Conform brauche ich das Material gar nicht in meinem Projekt
freezer hat geschrieben: ↑Mi 08 Apr, 2026 16:09
Für mich persönlich ist das korrekte Mitziehen von Audio sehr wichtig, ich mache mittlerweile die komplette Audiopost unserer Filme in Fairlight. Wenn da die wichtigsten Settings korrekt konvertiert werden, bin ich mehr als glücklich und spare mir viel Arbeit.
Und wenn der Gain, der einfachste Effekt der drauf liegen kann, nicht mitkommt, ist das halt auch ein Geschmäckle. Aber zu Ton kann ich nichts sagen, wir machen hier nur Bild, Ton kommt als Mix aus dem Studio.
Tatsächlich habe ich vorhin, angespornt durch unsere Unterhaltung, über eine "Man in the Middle"-Lösung nachgedacht. Wo ich quasi eine XML reinwerfen kann, der mit zB RePos für Resolve unter Berücksichtigung der Source-Res bereinigt, und eine neue ausgibt. Die ich dann importiere und alles sitzt, soweit die Theorie. Ich habe dafür die selben Clips wie eben genommen, wo also kein Rohmaterial 16:9 war und die Proxies immer 16:9 mit Letterbox (entweder oben/unten oder links/rechts, je nachdem). Ich wollte dann quasi die XML aus Premiere ausgeben, in Resolve importieren, korrigieren, und wieder ausgeben, dann vergleichen. Um abzuschätzen, was genau der Unterschied ist, unter Berücksichtigung der Source-Res, Timeline-Res, usw.
Der Witz ist, dass das insofern nicht geklappt hat, weil alles gesessen hat. Bei Material was links/rechts abgecached war, war die X-Transformation nicht on-point, Y aber schon. Bei Scope andersrum: Y sitzt nur bei 0, aber X ist fein. Scale hat immer gesessen.
Wo die großen Fragen auftauchen ist dann eher, wenn in Premiere mit "Scale to Timeline" gearbeitet wurde, wenn nicht Proxy-Res der Timeline-Res entspricht. Das kann man mit den Scaling-Funktionen in Resolve aber auch kontern (mache ich aber zugegeben ungern, weil man die nicht Batch-Einfügen kann).
Das macht das Ganze natürlich wenig trivial, und bräuchte dutzende Test-Timelines zum Aufsetzen. Und dann müsste man in so einem Tool viele Variablen reinhacken, die ich in einer normalen Produktion möglicherweise nicht mal kenne (Proxy Res zB), und nicht immer zeitnah erfragen kann. Ich habe aber auch gemerkt, dass der Mehrwert überschaubar ist, weswegen ich meine Zeit dann doch eher für das nutzen muss, worfür ich bezahlt werde :)
ich schreibe hier nur in pausen auf der arbeit.
