January 26, 2012 at 11:42 pm
After spending the majority of my day searching for a solution to this problem, I am hoping someone on the COW will be able to steer us in the right direction. I have also posted this in the AME forum as well, as it has to do with both AME and FCP 7.
After encoding several hundred clips of various file types to ProRes 422 LT at 23.976fps in Media Encoder, we discovered that the timecode of the source clips and the LT clips varies significantly when we bring the quicktime clips into FCP 7 or Quicktime 7. This is also creating issues for the EDL.
The source clips are XDCamHD, H.264, and .R3D files. We set up a batch in AME with a preset for ProRes (LT) at 23.976. After the batch processes, we import the clips into FCP 7 then export an EDL from the sequence. The EDL shows timecodes that do not match the source clips.
The timecode is off by several hours, not just a few frames. If we look at the LT clips in Premiere, the timecode matches the source clip. In Final Cut, not even close.
Any ideas on where to start on this one?
If we use RedCineX to convert the R3D files, things seem to work. Also, compressor seems to have correct results. We were hoping that media encoder would be the solution as it processes these clips much faster.
We are looking for a solution that doesn’t involve re-transcoding all of the footage.
January 27, 2012 at 3:27 am
Can you post a screen grab of a few of the mismatching timecodes in qt?
January 27, 2012 at 3:41 am
I’ll post in the morning when I get back to the office. Is there anymore information that would be helpful?
January 27, 2012 at 3:09 pm
have a look at QTchange, see if that reads the correct TC.
If that is the case, i could make an option to ‘refresh’ the TC.
(deleting the old track and insert a new, compatible one…)
Do concact me direct if this is indeed the case.
(if it is not, i can perhaps work around it, but that will take more time and i will concider it a custom job…)
smart tools for video pros
January 27, 2012 at 4:07 pm
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).
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.
January 27, 2012 at 4:23 pm
What was the exact setup you used in AME?
January 27, 2012 at 5:27 pm
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?
January 27, 2012 at 5:54 pm
No, this seems to be pretty comprehensive.
I haven’t tried this yet, but I’m willing to give it a shot.
I always use RCX or RCXPro for Red transcodes.
Is it only the Red files that are bonked?
Are the reel names and other metadata consistent?
As far as a fix, QT Change will probably be a great way to go if Bouke can get you sorted.
Give me a little time and let me see what happens which I try a transcode over here.
January 27, 2012 at 6:11 pm
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.
January 27, 2012 at 7:50 pm
I just tried one test clip (from Epic footage), and I am finding the same thing. AME isn’t passing this data on, and the data in the QT file is bad/not matching which is why it doesn’t work in FCP (or anywhere else).
Here’s a screengrab of the left being AME, the right being RCX:
It does however, store some of the info in XMP, which why PPro sees it, but it obviously does not parse that info and send it along to the EDL. What a shame. XMP doesn’t seem to have a “Reel” field. I just noticed this, and this is pretty weird. There must by something I am missing.
To add an interesting twist, if I choose “none” in the metadata prefs of AME, it passes along the correct TC (but still no reel name):
You need to get this info embedded in to the QTs and without a bunch of hand matching work, I think QT Change is going to be your best option to do this in a batch. You can also use QT Edit from Digital Rebellion, but that would be a one at a time endeavor.
Log in to reply.