-
Wrong TC on master file exports
Apparently now, FCP X exports master files with the wrong TC. This is with Mavericks and 10.0.9. I have a 23.98fps sequence that starts at 59:53:00 in the Project timeline. The exported ProRes master file reads the start at 59;57;12 in both QT Player 7 and in DH Pro Player. This appears to have changed with Mavericks.
If I import the same file back into FCP X, the code is correct. Apparently this is a problem with how the code is now read by the players using Mavericks.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
11 Replies
-
To add, FCP 7 and PrProCC see the correct numbers on the exported file. Scratch Play sees the wrong numbers. Seems to be some misreading of the NDF-DF flag. Maybe tied to QT and Mavericks.
Test – I bring the file into FCP 7. Edit it to a sequence and then export that new sequence with the same numbers as a new self-contained file. The new file’s TC is properly read in all the other applications, including QT7 and Pro Player. This points back to the FCP X export metadata.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
Oliver, this is out of the blue, but did you export the entire storyline as a click the clip selection – or did you do a true range selected export?
I ask because I recently had to output a huge voice job in separate “per slide” segments (voiceover in the primary) and the internal timings were off unless I did an actual range selection per clip – (the the yellow box selection WITH the handles) not just a “click selection”
Reminded me that all “selections” in X are not created equal.
Just a shot in the dark.
Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.
-
Thanks. I exported the project sequence from the share menu without any range selection. This appears to be a bug related to FCP X and Mavericks. The exact same procedure from FCP X on a machine running 10.8.5 yields correct TC when played in QT7 on a machine with 10.8.5.
One developer have pointed me to documentation that indicates 64-bit code related to TC in AVF versus 32-bit code for legacy QT-based apps. My guess is that FCP X exports TC based on this 64-bit AVF code and that this now is just becoming apparent in Mavericks and is a conflict with any legacy apps. Since nearly all players that play QT are doing so based on the legacy QTkit that is the old 32-bit code, it’s something that invariably bites all media players, which display TC.
It may not affect 29.97, 59.94 or 25fps TC. I have not tested that, so I don’t know.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
Aah, – the traditional mess of one process trying to march to more than one distinct timekeepers.
Gotta love audio!
Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.
-
Here’s the weird part. I’ve done some subsequent testing and I may have been mistaken about Mavericks. I can get projects that export both correctly and incorrectly on machines running under 10.8.5 and 10.9.
Tonight I tested it on my machine with a completely new sequence. Export was correct. So then I went back to the sequence on which I had an issue. Export was wrong. OK, corrupt sequence, maybe. I copied & pasted that to a new project. Same issue. I copied & pasted it to the back part of the “good” sequence. Export was fine. So then I tried to retrace these steps and from then on, could not get a correct export at all. Even doing the exact same thing I was doing before that yielded a correct sequence.
My suspicion is that something within X is really messed up when it comes to TC.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
Well Oliver, I certainly understand and sympathize with your situation.
Like you, I spent decades upon decades living and dying on the alter of perfect house sync timecode.
Thankfully, I’ve spent the past half decade watching timecode sync be less and less a part of what I need to do.
Half the time, the cameras I get footage from don’t even have TC any more. At best, that stick on GoPro or DSLR has some type of counter code, but full SMPTE with User bits just isn’t in the mix as much. And when I get files from an F-55 or Alexa or Red I just treat them the same as my GoPro files. Files are files. Frames are frames. One just as useful as the next.
I know that’s NOT the way most pros work. And I also know that there’s a MASSIVE investment across the industry in keeping shops and people who might still have a real engineer or two around to run house black – comfortable that they can continue to work they way they always have – and classic timecode is a huge part of that.
But personally, if I never send another nickle to Horita, Deneke, or Burst during the rest of my career – I’ll consider that a quiet victory.
Funny, but I’ve spent the past couple of weeks clearing out the back of the studio in a year end frenzy of cleanup – and at first, I felt pangs watching all that once expensive rack mount gear that I sweated so hard to afford to own – nearly all going to the local Boy Scout electronic recycling drop off since it’s all about as desirable as BetaSP cameras any more.
Sic transit technology.
Sorry I couldn’t help more.
Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.
-
The frustrating part is that I cannot consistently produce either good or bad results. The main complaint is how other PLAYERS reader the TC. Other NLEs seem to read it correctly. Of course, all NLEs track clips based on frame counts and not TC internally. Ultimately it’s an issue of how the TC info is stamped into the file header.
Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
[Oliver Peters] “Other NLEs seem to read it correctly. Of course, all NLEs track clips based on frame counts and not TC internally. Ultimately it’s an issue of how the TC info is stamped into the file header.”
Makes perfect sense.
It’s pretty easy to maintain compatibility when the task is to conform to standards that have been in place for a long time and that everyone understands.
Kinda more difficult, I suspect, to try to do something entirely new – and get the benefits of re-evaluation and forward thinking while simultaneously making what you’re creating play nice with the systems that have been around forever.
Specifically with timecode – I wonder whether there’s even a “central timecode management system” built into X or if it’s all just math done on the fly. Considering that so many worldwide users are now shooting on cameras and formats that don’t support TC at a very basic level.
On my last studio gig – the rigs were all sophisticated Pan/Tilt heads with what looked like security cameras mounted on top – all feeding HD-SDI on Cat-6 to one of the new Panasonic digital switchers.
I remember looking at that and feeling like my shoulder mounted camera rig sitting back in the shop was crying silently on it’s shelf.
Oh, well.
Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.
-
I looked at the XML from FCP X (converted by Xto7) and that same XML, but “washed” through FCP 7 with a new FCP 7 XML export. The one converted from FCP X says “display format-DF”, while the one re-exported from FCP 7 says “displayformat-NDF”. That clearly seems to be the cause of the problem. Apparently FCP 7 and Premiere ignore this information, because the XML is correctly imported into each of those apps.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
[Oliver Peters] “That clearly seems to be the cause of the problem. Apparently FCP 7 and Premiere ignore this information, because the XML is correctly imported into each of those apps.”
Now that’s fascinating.
Since drop and non-drop TC are simply alternate numbering schemes for the exact number of actual frames s – it appears that somehow something under the hood in these NLEs is using the frame ID NUMBERS – rather than the metadata about the frames, themselves – for calculating TC IDs.
That’s an extremely curious way to code something and has me totally baffled.
Unless you’re CNN or some other type of 24 hour broadcast operation, drop frame timecode is another artifact of an NTSC system that honestly needs to fade away.
It fixes broadcasters problems. Not content creators problems. That reminds me again of more than a decade ago when I responded to a guy on the internet who was doing a “TV Commercial” who posted that his spot was 64 seconds long and I tried to gently inform him how critical it was that id didn’t go over 59.5 – To my astonishment, he responded that it was a “TV spot for web use only”…
Sheesh.
Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.
Reply to this Discussion! Login or Sign Up