Premiere Pro Reads Incorrect Timecode from Source-Makes Bad XML

[Peter Garaway]

Very interesting Richard. Thanks for all of the details. David brought up some good suggestions.

I’d also like a sample of the file if possible. Getting the file into the hands of a developer should be helpful understanding where things are going wrong.

pgaraway at adobe dot come

Thanks !

Peter Garaway
Adobe
Premiere Pro

[David Roth weiss]

Peter,

Interestingly, the clip Richard sent did not yield anything useful after my analysis other than the TC difference between Premiere and every other product, just as Richard described. Since he transcoded via a Sony app rather than via the Abobe Media Browser, I thought that some underlying metadata might not have been translated properly, and I recommended that, as a test, he import the camera card directly thru the media browser. He’s doing that now.

I used to have an app that could show all the underlying metadata mostly invisible at the user level, but I’ve lost that app. In the past I was able to identify flags that were inadvertently not triggered by certain recorders and encoding apps, which could be the issue in this case with the translation by the Sony app.

In any case, it will be interesting to see if your developers can pinpoint the issue. Or, if perhaps the issue is fixed simply by importing the card directly via the media browser.

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.

[Andreas Kiel]

Richard wrote:
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)

That’s the difference between 23.976 and 24

– Andreas

Spherico
https://www.spherico.com/filmtools

“He who fights with monsters should be careful lest he thereby
become a monster. And if thou gaze long into an abyss, the abyss will
also gaze into thee.” – Friedrich Nietzsche, Beyond Good and Evil

[Richard Clabaugh]

Thought I’d share an update.

In short, the problem remains unresolved be we’ve covered a lot of ground.

First, thanks to David Roth Weiss for looking over the clip and confirming what I found – Adobe programs read the timecode one way, every other program reads it another way. Since then I have tried several things he suggested and spent days trying to determine the cause and create some work arounds. I have tried more than I care to itemize here right now, but suffice to say the problem has not gone away and no quick fixes, or slow fixes, have revealed themselves. The problem continues to defy all logic and the attempts to fix have created only more puzzlers.

My final “work around” for the time being, after a very long list, was that Adobe Media Encoder also reads the timecode in the same manner as Adobe Premiere — so I used it to transcode the XDCam files into ProRes files and in the process it embeded within those files the same (incorrect) timecode that Adobe Premiere Pro was showing. This, at least, gave me a piece of “source” video I could bring into other programs and they would then find the right spots in the video to match what Premiere listed in it’s exported XML file. With this, I was able to do color correction in DaVinci Resolve on the first of seven segments for the show I’m working on.

Other than that, the situation has gotten worse as several other segments that appeared to be fine have turned out to have similar read errors within Premiere when I export them – but inconsistently.

The latest is I opened an edit delivered to me by an editor, who worked on Premiere Pro for Windows, made sure it was good on one machine here in my office (Premiere Pro CC 2115 on my iMac) and all was good. Copied the project (and footage) to another drive, took it to another machine in my office (also an iMac running the same version of Premier Pro) and when it opened everything was wrong – the timecode had read differently between the two machines and this time Premiere Pro didn’t match up to it’s own timeline.

My deadline for delivery is this weekend and I’m using brute force workarounds at the moment and several of them have failed.

I just want to conclude by saying — after considerable testing – this definitely appears to be a bug within the program – at least as far as I’m concerned. If a program cannot read the timecode consistently, it should either show some kind of error message or start counting from 00:00:00:00 at the head of the clip. At least that tells you there’s a problem. To display what appears to be a perfectly valid timecode, only to have it turn out to be different from all other non-Adobe apps seems like a problem to me. As stated in my original post, I am NOT the only person to encounter this.

If I can find a real cause or solution to this I’ll post it here. Meanwhile, I’ve just got to get this job out.

Just didn’t want to leave everyone hanging!

This problem remains unresolved.

[Andreas Kiel]

Thanks Richard for publishing the details of you problem.

I said earlier in this thread that the time difference is the difference caused by 23.976 and 24 fps.
Could you send me an XML from Premiere that causes the trouble in Resolve. There might be a chance to create a XML fix for Mac.

– Andreas [kiel (at) spherico.com]

Spherico
https://www.spherico.com/filmtools

“He who fights with monsters should be careful lest he thereby
become a monster. And if thou gaze long into an abyss, the abyss will
also gaze into thee.” – Friedrich Nietzsche, Beyond Good and Evil

[Peter Garaway]

Hi Richard,

I may have missed it but I didn’t see an email from you with the sample file and the xml if possible. We would be happy to take a look.

Thanks ,

Peter Garaway
Adobe
Premiere Pro

[Cameron Bill]

Great info everyone. Thanks for all’s advice as I am battling the exact same issues and am frustrated that my TC burns for the past year appear to be off by a few minutes.

I have some more info that might help.

[Jeff Coleman]

Holy Exasperation Batman! You must be completely brain fried by now.

I hope this is helpful and not off-topic. Have you tried opening those files in an earlier version of Premiere?

I noticed today importing Pan AF-100 AVCHD files that they read differently between CC2015.3 and CC 7.2.2

Ingesting via the Media Browser or Prelude the file comes into the project showing a framerate of 59.94 ndf. If I create a sequence from that .mts clip, the sequence is also 59.94 ndf. If I drop a timecode filter on to the clip in the sequence it displays 60 frames of timecode ndf. The next part is what’s different between the versions of Premiere:

In 2015.3 – the Source Viewer or the metadisplay timecode track display in the Program Viewer shows the clip as 29.97 ndf timecode. For every two frames I jog in the sequence the timecode of the source track/clip moves 1 frame. If I load the clip in the Viewer it only shows me 30 frames of timecode. So the timecode filter shows 60 frames but the metadisplay and the Viewer only show 30.

In CC7.2.2 – I get all 60 frames of timecode in the metadisplay and in the Viewer. So the timecode filter shows 60 frames and the metadisplay and the Viewer show 60.

Perhaps that’s an intended revision of the program, but strikes me as a bug. I should be able to load a 60frame clip into the Viewer and see all 60 frames of timecode. That strikes me as the later version of Premiere not handling the timecode of an AVCHD clip as well it did in a previous version. Seems something has changed under the hood.

[Todd Pretre]

Hello all,

I’m on a PC and have just encountered the same original problem stated above in PP 2017. I did a project a month ago with no issues shooting dslr 24p. Now I’m seeing timecode problems. I always bring in video through the Media Browser. The long and short of it, this is costing me time I don’t have (like any of us do, right?) and money that was not budgeted for the project…all for something that has always worked in the past. Simply stated, I’m wondering why something as basic as timecode in video editing software can be as incorrect as this.

I’m shooting two cameras: EX3 and 5dMkIII. My onsite producer always takes notes via a monitor on site to expedite logging material in post. The timecodes she took down during interviews via direct camera output are NOT what the
timecode effect is displaying in Premiere 2017. The first shooting day, she logged timecode from the 5DMkIII. Those timecodes did not match at all. The second day (a week later), she logged the timecode from my EX3, as I figured it was a camera issue. These timecodes were even more incorrect.

The 5D kept a running time in PP, just that the numbers were way off. For the EX3, PP starts each clip in the timeline at 00:00:00:00, no matter if the clip begins one hour and 42 minutes into the timeline and even interviews that began somewhere in the 02:10:12:09 timecode area. The timecodes read the same in the source window and in the timeline…at least that’s consistent, thought it’s entirely incorrect an not a help in the process.

I see all the technical info at the top and I applaud you all for that time put in and information learned. I’m not nearly as savvy. If I can provide material to aid in a fix (since I have different formats than mentioned above), I’m happy to do so. As a company of one with a busy schedule, I’m sorry to say it’s very difficult to invest time in multiple processes described above which have not lead to a fix. I know, I know, we are all in that boat and I’m not intending to say “poor me.” This is why I’m very appreciative of those who can work towards a fix and I’m thankful for those who dedicate many hours to help out the masses.

Currently, I’m recreating the project in 2015.3 and am not having this issue. Timecodes are working as they should.

On a somewhat similar note, every time I ingest in PP 2017 I highlight all clips in the Media Browser and drag them into my project. All files transfer EXCEPT the first clip in the list (which is highlighted). I always have to go back and drag that first highlighted clip into my project separately. Is anyone else having that issue as well? It happens with every ingest I do.

Again, thanks to you all for your efforts detailed above. If I can be part of the fix, I’m happy to help when and where I am able. I look forward to future posts and following this thread.

Thank you to you all.

Todd

[Richard Clabaugh]

Just to return to this since I started it and I see others are also still having this problem…

I had to drop dealing with it and just get the project out by manual conform/brute force, but I did begin to make some connections – none of it very useful for most of us.

There were four ways to digitize material that I triedL
1. Via Final Cur Pro “Log and Transfer”
2. Via Sony XDCam Transfer program (this is what I most often use)
3. Via Premiere Pro 4 directly
4. Via DaVinci Resolve (I usually do that only if I need to apply a LUT, which was not the case here)

The one that seemed to work best was if I digitized using Premiere Pro. Whatever timecode it created on import it than recognized and exported an XML that was consistent with itself, although not with what other programs read for the same material. All other programs still had a problem with it, but this produced the best results.

I consider this an unsolved bug as of that time. Have not done a project of this workflow since November, so have not checked it with the latest Premiere Pro. (Last thing I shot was on an Arri Alexa and I’m not editing it).

I just didn’t want to leave everyone hanging and not knowing how it turned out.

Hopefully someone will resolve this.