[Brian j. Smith]

Jeremy, thanks for suggesting Digital Rebellion. They came up with a modification to their already amazing Pro Media Tools that did the trick. I cannot thank Jon enough for his quick work and generosity in solving this one for us.

https://www.digitalrebellion.com/contact.html if you are interested in their fix and/or more about their other products.

[Brian j. Smith]

The strange part is that compressor is seeing the correct timecode. And Final Cut X also sees that info. I wish I knew more about the inner workings of the way AME transcodes the footage.

If Compressor sees the correct TC info, is there perhaps a way to know what Compressor looks at vs FCP?

Someone on the Adobe forums suggested we use Premiere (in this case not an option) though it would solve our issues.

Hopefully Bouke has an idea or two on this and may know what part of the AME encoded file inside QT Premiere is looking at and can translate it to TC that FCP can read.

While still to be resolved, I’m glad someone else is getting the same results.

[Brian j. Smith]

This issue seems to happen with the XDcam footage that we have too.

The reel information from the Red footage does not show up in FCP when going from AME to the ProResLT setting. It does, however show up in Premiere.

As far as QTchange goes, at first glance, the current version reads the Timecode like FCP does. I’m going through the user guide to see if I missed something simple. The reel shows up in QTchange.

[Brian j. Smith]

We set up a ProResLT preset to run all the clips in Media Encoder. Here are the preset settings we used for the R3D files, XDCam, and H.264:

Quicktime ProRes (LT), 1920×1080, 23.976 fps, Quality 100, 48000 HZ, stereo, 16 Bit. None of the advanced settings are changed. Max render quality and frame blending are off.

In preferences, the only things that seemed to be relevant to this situation is in “Appearance>Display Format” this is set to 24fps. We tried 30fps (just in case this altered something), but this gave us the same results.

In Preferences>Metadata, we left the “write XMP ID to files on import” checked. Also:
Export options: embed in output,
Source preservation: Preserve all
Output file metadata: All Metadata

We have several Mac Pros each running separately and we get the TC errors regardless of the machine running the clips.

Did I leave anything out?

[Brian j. Smith]

Jeremy,

Here is a zip folder of screen shots that should show the issue a little more clearly. The image that was created via Media Encoder has “_001” at the end of the file name.

There is an image showing the original TC from RedCineX.

In FCP, I compare the QT from AME to the QT from RedCineX.

I’ve also included shots of the item properties in FCP. The duration of the clips match, but when you look at the logging tab, the TC rate for the file with the issue is 30, where the correct file shows 24.

I tried to change the TC rate via the “Modify>Timecode” option in FCP, but that did not significantly alter the clip’s TC. As a side note, this would not be a feasible option for the quantity of clips we have.

Since my first post, we took the AME to ProResLT clip and tossed it into compressor just to see what timecode compressor could read, and it was correct. (screen shot of that is included, too).

3588_ametimecodeissue.zip

Bouke,
We did an initial test with QTchange and had mixed results. Perhaps, we missed something. If the above information helps you to know if your program can do the trick, that would be great.

[Brian j. Smith]

I’ll post in the morning when I get back to the office. Is there anymore information that would be helpful?