There’s a bug in InqScribe 2.0.5 that affects FCP XML exporting. Currently the bug only affects exports that use XML templates that are based on NTSC DF.
The bug is that InqScribe is counting the dropped frames when it converts from the timecode to a single frame count number. As a result, the converted timecodes will drift farther and farther from where they should be, the later in the movie you go.
There is a workaround that you can use until we fix the problem.
Update: turns out the workaround didn’t work. Drat. But the good news is that we’ve fixed the underlying problem in InqScribe 2.1. A public beta can be found here.
This fix takes advantage of the fact that the conversion from non-DF timecode to a frame number works fine in InqScribe, and actually lines up with what the DF value should be. The tricky part is getting FCP to recognize the imported XML as DF.
It goes like this:
1. Export from FCP a non-DF XML template for InqScribe.
2. Export FCP XML from InqScribe using the template.
Since InqScribe notices that the template is non-DF, it’ll convert based on that timecode format, which we know will actually line up with what you want.
3. Open the exported XML file in a text editor and do a global search and replace as follows.
FCP XML notes timecode format like this:
If the value for <ntsc> is TRUE, it uses DF. If it’s FALSE, it uses non-DF.
So, if you replace “<ntsc>FALSE” with “<ntsc>TRUE”, you’re essentially converting the XML file to DF, which what you want. Remember to do a replace all — there will be tons of <rate> bundles throughout the XML file.
4. Import the modified XML into your project.
If all goes well, FCP will decide this is a proper DF import, and you’ll see all the timecodes line up.