Premiere Media Start timecode issue MXF

[John_W_Pilgrim]

We are having big trouble with some Sony Venice MXF footage.

Premiere is misinterpreting the Media Start timecode across several days worth of shoots.

The problem reproduces in both Premiere 2018 and 2019, on multiple machines, in old and new project files, and even after clearing the cache and aggressively deleting XMP and other sidecar files.

Please see the graphic below for more description.

Since the text on that graphic isn't web searchable, here's a summary of the issue:

We received a drive from our DP and copied it onto our NAS, as we have successfully done dozens of times before.

We ran the footage through Adobe Media Encoder to make smaller MP4s with burned in timecode for the producers to review, as well as WAVs for transcription.

As we started editing using selects notes with TC from the producers, it became clear that the timecode was off.

Upon investigation, we ascertained that Premiere had the Media Start timecode screwed up.

Nothing we've done has been able to get the timecode correct, short of manually going clip by clip and using Interpret Footage/Timecode to set the correct timecode as an Alternate Start Timecode, which is not an acceptable solution in a busy post-production studio.

Anybody been having similar experiences, or have a solution?

Thanks in advance,

John

San Francisco, CA

[John_W_Pilgrim]

PS: Sadly, After Effects also is showing the incorrect timecode for the start of these clips. 😞

[John_W_Pilgrim]

I'm quite confident hacking around in XML files and Premiere ".prproj" files are XML, so…

Looking through some ".prproj" files I created in both Premiere CC2018 and CC2019, containing either (a.) the original MXF file with the wrong Media In timecode or (b.) a MOV transcode of the MXF that has the correct Media In timecode, I found the following.

The TL;DR is that Premiere CC2019 appears to have two bugs:

1. it misinterprets the Media Start timecode of MXF files on import

2. it misinterprets the Media Start timecode of MXF files when converting a CC2018 project file

[Elliott_Sound]

Hi John,

I'm wondering what program you used to transcode your MXF into an MOV with correct timecode before bringing it into Premiere. My experience so far has been that if I transcode within Premiere or Media Encoder the resulting video file still displays incorrect timecode?

Thanks!

Galen

[scottppm]

Hi Galen,

You could transcode your MXF files using any "non Adobe" program (ex. Resolve, Apple Compressor, etc.) to maintain correct timecode.  The other option would be to downgrade to a previous version of Adobe Premiere / AfterEffects / Media Encoder (ie. CC2018) and transcode there.

[John_W_Pilgrim]

I would use a high quality program for doing MXF -to- ProRes MOV transcodes. For Sony footage, we use Sony Raw Viewer or BMD DaVinci Resolve on MacOS.  DaVinci would be my choice on MacOS for transcoding MXFs from mixed camera vendors. On Windows, I would use Assimilate Scratch Play Pro (or full Scratch) to do MXF -to- ProRes MOV transcodes.

Adobe just announced that Creative Cloud on Windows will now encode ProRes MOVs, but I have heard no indication that the MXF timecode bug has been fixed, so at this point using Adobe to transcode won't fix the problem.

[John_W_Pilgrim]

RameezKhan or Kevin-Monahan - From what I can see in other posts you seem to be the timecode experts.  Any insight on this issue?

Thanks in advance....

[Kevin-Monahan]

John,

I'll make sure the bug is filed internally. I truly apologize for this problem. I think others on user voice have noticed it. Several copies of the same issue seem to be reporting it. This one has the most upvotes. I'll upvote it, as well: Bug: timecode is not accurate upon import – Adobe video & audio apps

Thanks,

Kevin

[DoyleTX]

I am also having this problem with MP4 clips recorded by a Sony A7Riii.  "Lucky" for me, I'm also recording to an Odyssey 7Q+ with camera trigger, which means that the camera footage TC is always 1 frame behind the 7Q+.  But this is sort of a silly issue.

[Cool_Hand]

I have been suffering from this problem as well, with a Sony F55.  Two shoots with a Sony F55 and a Canon C300 MKII, since the 2019 update, the F55 shows the wrong source timecode, the C300 and backup audio match perfect. I even tested it on another computer running Premiere 2019 and the same issue appeared.

After trying to export to Resolve, and only getting the C300 footage to work, I discovered that the timecode for the F55 in Resolve was different then Premiere, and correct.  I have now been modifying the start timecodes in the source clips that i need to sync up with the C300.

It's a pain, but until there is a fix I have on other solution.

[John_W_Pilgrim]

Thanks Cool-Hand.
If you would, please click the "I have the same question" flag at the bottom of my original post above.

I have been told that the Premiere "Formats" team is aware of this bug and is currently working on it.

Resolve correctly read the MXF start timecode, where as Premiere 2019 has a bug reading it, so it's not surprising that XML generated by Premiere 2019 does not accurately re-conform in Resolve.

How are you fixing the Media Start timecode in Premiere? Are you using Modify Clip / Timecode to set a new Alternate Timecode for the Start of File for each clip?

Once you did that, did the XML successfully translate from Premiere to Resolve?

[Cool_Hand]

Hi John,

Yes, once I Modify Clip / Timecode and changed the Timecode to my correct new Alternate code.  Resolve was happy with my new AFF and XML.

This doesn't work in old projects, I found I could cut in CC 2019 - then set a new Alternate Timecode.  In old project the Timecode is off like it is in Resolve throughout the sequences.  I had to reinstall Premiere 12.2, I do think it's a Drop frame issue now. 

Thanks for the info I am glad the team knows.

Cheers,

Lucas

[John_W_Pilgrim]

Cool_Hand,
Be aware that if you have Premiere 2019 set to write XMP files or sync XMP metadata, then Premiere 2019 will write the erroneous MXF media start timecode out to an XMP metadata sidecar file, which Premiere 2018 (prior version) will read and assign the wrong Media Start timecode to the footage, even though PP2018 will read the correct timecode from MXF files if there aren't any (incorrect) XMP files around.

It took me some time to get our shop's Premiere preferences coordinated and to delete the XML files from our servers, to prevent this backfeeding of the timecode error into PP2018.  PP2019 does write out the corrected Alternate Timecode to the XMP (see photo), but we opted to just suppress the writing and reading of XMPs altogether.

[Cool_Hand]

Thanks John,

I noticed the sidecar file while I was testing my options, I'll keep this in mind once they fix the problem.

It's funny I always update one suite and check the plugins, a couple of projects; (all of them happened to be non drop.)  It looked fine to me, what a sneaky bug.

All the best!

[Ryan Grevatt]

Thank you John - this post saved us quite a bit of time today!

[ChrisZ590]

I have just discovered this problem with the MXF files from the Sony PXW-Z190 as well.

Compared the media timecode start time with the Media Info app vs Adobe Premiere Pro. Premiere Pro is reporting incorrect timecode. Also tried to transcode/rewrap to MP4 file in Media Encoder. It also read and created new file with incorrect timecode.

Frustrating to say the least. Hopefully a fix is coming from Adobe very soon.

[Elliott_Sound]

Just wanted to chime in and say that I am also experiencing this issue bringing in Canon MXF OP1a wrapped files from the Canon C300 MkII at my work. Hoping for a bug fix soon! Thank you for the thread @John W Pilgrim

[AB_BTK]

Same problem with Sony FS7 footage.  This is a major problem.  I hope Adobe fixes it PDQ.

[KS-Andre]

This issue is still present.

Has Adobe still not recognized there is an issue with how it's misinterpreting timecode?!?!  This is not the only place mentioned this issue.

It keeps me from bouncing into Davinci for Color without performing a Render and Replace action first which is a kill in Drive space.

If this isn't cleared I will take it as my reason to jump to Resolve for my work entirely.  I know a post house who have done so and are not hurting for it.

[Daniel Hoover]

Some people on UserVoice are reporting that this MXF timecode bug has been fixed in Premiere 13.0.2 - has anyone else tried the new update?

Bug: timecode is not accurate upon import – Adobe video & audio apps

[Elliott_Sound]

@Daniel Hoover The 13.0.2 update seems to have fixed the timecode problem for me, at least for the Canon c300 MkII I use at my work.

[Kevin-Monahan]

Is this issue solved for you now, John?

Kevin

[noahg64558676]

Kevin -

This issue is NOT resolved.

[Jan_Berlin]

Hey folks. I am not sure about this Issue, but I have a similar Problem: I want to create a 24fps H264 File with Timecode Overlay form a ProRes Mov Source. AME (using the Timecode Overlay Effect) and Premiere (using the Timecode Effect on a adjustment Layer) will cause in a wrong Timecode Overlay. AME reads the TC correctly (on the In-Out-Timeline) but displays another one.

Another big Issue with an uptodate Adobe product.

Btw: CC2017 is fine with that!

[LazerKaboom]

I'm on version 14.0.0, and as of 01/02/2020, I'm still seeing this issue. I'm working with GoPro Cineform mp4 and the timecode is coming in generically as "alternate timecode". Resolve, RV, and Nuke all read TC correct but Premiere is displaying very incorrect data. After I choose "modify/timecode/original timecode the issue is resolved. Kevin, would your team be able to allow this option to be batchable? I wouldn't mind selecting all clips and changing this info, but as of now, I have to go one by through hundreds of clips.