Conforming using native Flame Archives (looking for testers)

Hey everyone,

Longtime lurker, lots of respect for this crowd. A lot of what I know about finishing came from threads here.

I’ve been building a tool called conform.tools for converting timelines between NLEs and finishing programs, and I wanted to share the Flame side with you to see how useful it is to those using and conforming in Flame every day.

My approach is pretty straightforward: every NLE already saves its timeline in its own native file. If you can read and write those directly, instead of going through XML or AAF, you’ve got the best shot at a conversion that doesn’t lose anything.

So that’s what I’m doing for Flame, writing straight to a native Flame archive (with an XML and an FCPXML as fallbacks) from any number of input types (.prproj, .avb, .drt, .xml, .aaf, etc.)

I’ve been working on this in a vacuum for a while, and I just don’t get enough projects through it to know how solid it is yet. I’ve learned the long tail is long –– there are so many combinations of things that can happen in a timeline that lots of testing is really the only way forward. So I’d love to have some folks try it. As a conform/finishing artist working mostly in Resolve myself, this tool has saved me so much time coming and going from Resolve, and I’m hoping to extend that to Flame as well.

Exports to free to run, you just need to sign up for an account at conform.tools/timeline-exchange.

Thanks y’all! Excited to have folks try this out.

Stefan

Isn’t OpenTimelineIO supposed to solve all that?

I haven’t found OTIO to be much better. I think part of it is the sizing rules these apps use are different to begin with, so even if an exchange format maintained the work, it wouldn’t necessarily rebase the values to make things match pixel to pixel perfect.