If you’re using Final Cut Pro 7 and importing InqScribe-generated FCP XML files, you’re probably pulling your hair out. As of FCP7, any imported subtitles beyond the two minute mark show up with a duration of only one frame.

The problem is twofold. First, InqScribe is setting incorrect values for the in and out points for each generated subtitle. In prior versions of FCP, these values were essentially ignored on import, because in and out points for a static subtitle don’t really mean that much. (The start and end points for the subtitle, which determine where the subtitle goes in the sequence, were and are correct.)

Unfortunately, FCP7 is interpreting those values differently, and any subtitle with an in point greater than the subtitle’s stated duration ends up with a frame length of 1. Since InqScribe was setting every subtitle’s duration to 3600 frames (because this value shouldn’t really matter: effective duration of the subtitle is based on the start and end values), most users will find that subtitles that start at the two minute mark or later are affected.

We’re working on a fix for the next beta release. In the meantime, there is a workaround.

Here’s an excerpt from an InqScribe-generated FCP XML file:

<generatoritem id="Text">
    <name>Text</name>
    <duration>3600</duration>
    <rate>
        <ntsc>TRUE</ntsc>
        <timebase>30</timebase>
    </rate>
    <in>7540</in>
    <out>7610</out>
    <start>7540</start>
    <end>7610</end>

Note that InqScribe sets the duration to 3600 (regardless of the actual duration, which is based on the start and end values). InqScribe also sets the in and out points to the start and end values. The problem is that in and out values should technically never be greater than the duration.

So the fix is to change every instance of in and out to this:

<in>100</in>
<out>3600</out>

With this change, in and out stay within duration’s range, and FCP7 won’t clip the resulting subtitle.

To make this change easily, use a tool that supports regular expressions to find all instances of the in and out tags. Here’s a solution that uses sed, which comes installed on OS X.

1. Export the FCP XML file from InqScribe as usual (let’s say it’s called export.xml).
2. In the Terminal, navigate to the directory containing export.xml, and issue this command (which is one long line, make sure to copy the whole thing):

sed -e 's_\(<in>\)[0-9]*\(</in>\)_\1100\2_g' -e 's_\(<out>\)[0-9]*\(</out>\)_\13600\2_g' < export.xml > export_fixed.xml

3. Import the resulting export_fixed.xml into FCP7.

If you want to dig into sed so you understand what that command is doing, here’s a solid sed tutorial. It’s a very powerful tool.

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 time codes 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 time code 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 time code 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 time code format like this:

<rate>
  <ntsc>FALSE</ntsc>
  <timebase>30</timebase>
</rate>

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 time codes line up.