trying to import some XMLs created in Resolve but things are getting a bit screwy.
4 out of the 5 XMLs sent refuse to open and show a “Could not import…” box with no useful troubleshooting info.
The other opens fine, and lets me reconnect to media on my drive. A few shots are missing and they show up as missing but do retain all the timecode, metadata etc
I have opened up the problem XMLs in Resolve, linked to the folders with the media and then resaved out a new xml.
When i open these using Flames conform page, all the red raw files are connecting correctly, but the few missing files (AE exported .movs and mp4s that the vendor has yet to send) are now importing as black colour files, with the TAPE heading set to COLOUR, no timecode info and no way to unlink this black colour file. Flame is convinced they are colour sources.
I have tried resaving the one xml that works, and when i try conform, Flame assumes any clip that was missing needs to be filled with a black colour source. I cannot see a way to stop this happening or a way to retain the metadata to allow me to manually reconnect the files when i get them.
It looks like the second resave/export as xml might be where the issue is occuring but i might be totally wrong…
Is this a Flame issue or Resolve or something else entirely?
I don’t do much conforming, but i have never had this issue happen before.
The two variations of the same xml - one after being relinked and saved out in Resolve, now shows the missing files as colour sources and loses the timecodes! and are impossible to Unlink.
This is (in my experience) almost always a timecode issue.
Is it possible that the after effects/.mov material is at a different frame rate (23.98 vs 24, or DF instead of non-drop, or something similar)?
I’m not in front of a machine right now, but I vaguely remember there being an option when loading edls, xmls, and aafs to convert all timecode to one rate, but since I usually just kick bad edls back to editorial, I don’t remember much more detail.
You can also manually edit edls, but I’ve never tried that with xmls and to be honest it sounds scary.
I could have been more clear, let me try again. Flame doesn’t like edls/xmls/aafs (hereafter referred to as just edls) that contain multiple flavors of timecode.
Specifically, I think, flame wants all the footage in an edl to be at the same frame rate as the sequence itself.
My solutions are usually 1) scold assistant editor and ask for the non-base-rate footage to be removed from the sequence, and have a second edl exported for each flavor of timecode, or
edit an edl manually, strip out non-base clips, and eyematch nonconforming clips, or
maybe use a different edl format? Now that I think about it, I may have gotten around this by using aafs instead of xmls, but I could also be imagining that.
we have solved it!
seems the original xmls were saved in an older format (1.5)and when re-exported from the original project using xml 1.8, they open up fine in Flame.
thanks Kirk - it was nothing to do with frame rates. Everything in the projects at my end and the production company was set to 25fps. It was more down to using an older variant of the xml protocols.
(Still an opportunity to scold an assistant editor, so don’t sleep on that)
i would if i there was someone to blame!
@kirk If I’m conforming camera original media from an AAF/XML, I can often get odd framerate stuff (looking at you, stock footage) to come in correctly by conforming by Handles instead of TC. If you’re loading in graded selects that won’t help you, though.