Premiere Pro Reads Incorrect Timecode from Source-Makes Bad XML

[David Roth weiss]

Have you tried exporting an EDL to see if that has the same TC issue(s)?

David Roth Weiss
Director/Editor/Colorist & Workflow Consultant
David Weiss Productions
Los Angeles

David is a Creative COW contributing editor and a forum host of the Apple Final Cut Pro forum.

[Peter Garaway]

Hi Richard,

Sorry for the troubles. Not sure if this is a practical solution for you but have you tried modifying the timecode of your clips that are not being interpreted correctly via Modify> Timecode?

I’m not seeing any open issues with files from the EX1. Can you provide a sample file for us to look at?

Thanks in advance,

Peter Garaway
Adobe
Premiere Pro

[Richard Clabaugh]

I did, in fact, try that as one of the first steps in the process and the results were exactly the same, and for the same reason. The EDL reflected the same incorrect timecode values from the source clips.

To be clear, these in the EDL and the XML are the values that, if you manually look at the Premiere Pro timeline, is says are the start and end timecode values in the source clip for each edit, but those numbers ONLY match those frames in Premiere. No other program agreess that those numbers goes to those frames, so the EDL, like the XML, produced a garbage result.

[Richard Clabaugh]

Regarding Modify > Timecode — I have not yet tried that for several reasons.

First, I would be unsure what the correct modification would be.

As an example, one clip I have:

Quicktime and Resolve mutually report that first frame TC = 15:38:29:08
Premiere Pro says the first frame TC = 15:37:33:01

That’s a difference of 56-sec and 5-frames

But by the end frame of the clip ( 3min-11sec-12 frames)

Quicktime says the Last Frame TC = 15:41:41:00
Premiere says the Last Frame TC = 15:40:44:13

That’s now a difference of 56sec and 9-frames
A change of 4 frames in roughly 3-1/4 minutes.

If we were in NTSC (30fps/60i) I’d think Dropframe vs Non-Drop Frame, but there is no DropFrame in 24p (23.976)

It’s not enough difference for a 24fp vs 30fps difference, which would be a much higher drift (6 frames per second).

Stepping through frame-by-frame does show both are counting only 24fps base (going from frame 23 to the next second in all programs).

Have not looked to see if there are “drop frames” in either program, but Quicktime reports NDF and, as I said, there is no such thing as 24p drop-frame TC.

Comparing other shots I find that all clips, and parts of clips, have a different offset, so in terms of modifying timecode, I didn’t know what to put in as a correct timecode adjustment, since it drifts and their was no constant offset, although it does seem that the higher the timecode number value, the greater the difference.

Second reason I did not try this – concern I might really seriously mess up Premiere’s file of the timeline and I’m on a deadline with this project and that could be serious – so messing with the underlying timecode without being sure what to adjust it to, felt like it might be unwise at this juncture.

If you know from experience this will fix the problem, however, I will gladly take your consul and do what you suggest — just reluctant to experiment below the hood while on a tight project deadline.

Regarding the EX1 footage — While not impossible I am disinclined to think it is the culprit here. I’ve used it for years now with no problems in both Premiere Pro and Final Cut, DaVinci Resolve and After Effects, trading footage between each program at both 24p (23.076-just to be precise) and at 30p (29.97) with no problems, including just this week posting a bunch of commercials shot at 30p. This is the only problem that has arisen and the only new combination of elements is Premiere to Resolve at 24p.

Well, okay – not 100% true. A couple updates and corrections to my original post that may be important:

My wife (an editor here) pointed out that we did export another 24p project, a feature film shot in 4K on the Red Epic, and that project, which was quit large and lengthy, had no timecode issues when the XML was taken into Resolve for Color Correction. That was done at a post house off site but I checked the XML here in our version of Resolve before sending it on and it opened fine and re-linked correctly. So we HAVE exported a 24p project, and a very large one, successfully before with no problem.

While I am not ruling out the 24p-XDCam format file being somehow connected to the problem, it’s not my first thought, especially since two other posts I’ve see regarding this problem used different file formats but had the same issues.

Follow the link in my original post, go midway down the page and you’ll see some screen captures this man did in Avid and Premiere of matching timecodes and matching frames (where the timecodes differed) and what he described and experienced with AVID is exactly what I’m experiencing here.

I will add one VERY IMPORTANT CORRECTION to my original post – on re-examing a clip in After Effects, it turned out to be showing the same timecode that matched what Premiere Pro said — so the Adobe Programs (Premiere Pro and After Effects) are saying one number while the non-Adobe programs (Final Cut Pro 7, QuicktimePro7, DaVinci Resolve) are all saying a different number.

If you think a sample clip would be useful let me know where to send it and I will.

I confess I was sort of hoping someone reading this might say, “Yes, I had that happen to me and all you have to do to fix it is go to preferences and set your interociter-interpretation techno-code emulater to read timecode channel2A in Latvarian trans-digit-multiplex mode, and all will be fine!” Something so simple and obvious I’d be slapping more forehead going, “Duh, of course, what didn’t I think of that!”

Just hoping! 🙂

[David Roth weiss]

Gotcha! It’s just a standard test as you know to try to rule out broken XML translation, which is one of silly things that sometimes happens when bigger things in our NLEs get “fixed.”

David Roth Weiss
Director/Editor/Colorist & Workflow Consultant
David Weiss Productions
Los Angeles

David is a Creative COW contributing editor and a forum host of the Apple Final Cut Pro forum.

[David Roth weiss]

Send me a clip (like 2-mins long) with known timecide. You can send it to drw000 at mac dot com.

Or…

If you can send the entire card via Dropbox that would be even better, but if not I can understand.

David Roth Weiss
Director/Editor/Colorist & Workflow Consultant
David Weiss Productions
Los Angeles

David is a Creative COW contributing editor and a forum host of the Apple Final Cut Pro forum.

[Richard Clabaugh]

I very much appreciate your feedback. It’s a logical thing to check. I remain open to any other suggestions.

[Richard Clabaugh]

Sent you an email with a link to a file along with details on what my system shows for the timecode in various programs.

Thanks for trying to help out here.

[Tero Ahlfors]

Have you imported the footage using the media browser panel?

[John Pale]

I’ll second this. Its been my experience, importing via File/Import or drag and drop may give you different results than using Media Browser, which is much better at detecting media types. Try the Media Browser and see if the timecode is correct. Also, some media types will not work correctly with spanned clips if you do not use the Media Browser.

For what it’s worth, I also saw this problem occur in Avid, where allowing the system to auto-select the AMA import plugin rather than manually selecting it resulted in the wrong timecode (hundreds of clips…grrrrrr.) This was because the wrong MXF file type was selected (P2 instead of Sony).