Premiere VS Avid clip timecode

[Vince Becquiot]

Interresting… I no longer own a copy of Avid Xpress, but I did compare timecodes from this particular camera and Premiere, and it was correct at the time. Which one is the correct timecode BTW ? I’ll assume you are ingesting P2 directly in both applications?

Vince

[Apollon Botta]

I checked the clip’s TC using P2 Viewer and Avid’s TC is correct. Is there a way to manually change a clip’s TC in Premiere?

[Vince Becquiot]

Really? That doesn’t sound good, I’ll have to check again on that. I guess since the EDL doesn’t work anyway with MXF, it’s less of an issue 🙁

Yes, you can go under File > timecode and change things around.

Vince

[Apollon Botta]

Actually, “Timecode” under “File” is greyed out and won’t let me choose it (and yes, I do have the video clip selected in the Project window). Is this just an issue with MXF files?

[Vince Becquiot]

Yikes, you’re right. I never realized that wasn’t supported either…

I’ll give credit to Adobe for getting us DVCPro HD support, but they do need to implement it a bit better with the rest of the application.

At this point I can only think of exporting to uncompressed first, which I don’t think you’ll see as a viable option. Or there is the Raylight, Cineform plugin options…. Not much of a light at the end of that tunnel.

Vince

[Bouke Vahl]

Both TC’s are correct.
There is a 0.001 speed difference between 23.976 and 24 fps, based on 0 as a starting point.

Do not think 23.976 is the same as 24 in all cases.

It’s easy enough to script a conversion routine if needed, but best is (as always) not to convert half way during post.

Bouke

http://www.videoToolShed.com
smart tools for video pro’s

[Apollon Botta]

Well I ran the numbers and by golly you’re right. For some reason Premiere is spitting out TC that’s 24fps-based from zero and not 23.976, even though it says it’s 23.976 in the project, resulting in a .001 difference.

I am able to generate an EDL of TC out of Premiere (granted, it’s 24fps-based, apparently). So how can I best go about getting those numbers changed accurately according to the .001 difference? I’m not a programmer but I imagine writing something to calculate and spit out each new TC would be simple if one knew what he was doing? Any help here?

[Bouke Vahl]

Yes, that’s very easy.
If you have a decent TC calculator, convert to frames, do the .1 % difference on the frames, go back to TC.
If you don’t, i’m sure there are a lot online. Just check them before commiting yourself to an evening of tc typing…

Even if you’re not a programmer, you can write this yourself in Excel.

I could make an app that converts an entire edl in the blink of an eye, but that will take me an hour or two, and i’m swamped for the next couple of days.
How many events are we talking about?

Bouke

http://www.videoToolShed.com
smart tools for video pro’s

[Pat Mcgowan]

Does this problem go way back to the coding of SMPTE TC in early versions of premiere? Time on the wall vs. SMPTE?

[Bouke Vahl]

Totally not, and i don’t even know what you’re talking about.
(i started with Premiere in 1996 or so, and even then it had normal TC)

This is not a ‘bug’ or Premiere specific thing. An educated guess sez that TC in these files is written relative to the frame rate, like BWF uses ‘samples after midnight’ to define TC.
Now this is difficult to grasp, i imagine. An example (for BWF)

You have a BWF clip @ 48 KHz. (it sez so in the header)
If the starting timecode is 00:00:10:00, the timecode is written in the file as 480. Meaning, 10 times 48k samples a second has passed since 00:00:00:00 (‘after midnignt’) before the recording of this clip started.

Now when you interpret the clip as 24 Khz and you calculate the TC from there, the starting TC will be 00:00:20:00
(480 / 24 samples have passed before recording this clip)

Now the 24 example is just for easy math. Nobody will do this.
But people will speed up / slow down audio all the time when converting between 23.976 (NTSC 24 with pulldown removed) and ‘true 24’ (like in film).

So it is just a matter of how different software packages deal with the math, and if they give you an option to use a different way of calculating.

For the original poster goes that if he has a 24 project vs a 23.976 project, both TC’s are right.

And it’s up to the software developers to make tools to help with these conversions. But without knowledge on how things are nobody will be able to use them. Remember that most of the video production world is still normal Pal or NTSC.

Bouke

http://www.videoToolShed.com
smart tools for video pro’s