Hello Adobe! Major Time Code Problem in 2.0

[Eric Addison]

Not sure how often anyone from Adobe goes over the posts on this site. I would make a phone call to Adobe, and I think there is a place on their website where you can report bugs…not sure about that though.

—Eric

[Steven L. gotz]

Email to prembugs@adobe.com gets results as well, I believe. But you are usually better off reporting through https://www.adobe.com/misc/bugreport.html because it provides guidance for a format.

Steven
https://www.stevengotz.com

[Timothy Eaton]

Thanks Eric — I’ll try to call Adobe tomorrow and post to the bug site as well. I was hoping somebody reading the list might have their ear more than I do. I don’t really consider this a bug. They’ve included time code in the last four or five versions. That seems like plenty of time to understand the basics of editing.

Tim

[Timothy Eaton]

Thanks for the links Steven!

[Dave Friend]

[Timothy] “Major problems: First, the hour code in a digitized clip is arbitrary and has nothing to do with duration, which would determine time code offset. The offset should be figured using the minute code only.”

Perhaps I do not understand what you are saying, but the offset between NDF and DF timecode values accumulates over time. The further you get from hour zero, the greater the difference between the NDF and the DF representation of any given time value becomes. Therefore your assertion that hour value is not relevant is incorrect. The DF/NDF offset cannot be determined without considering the entire value including the hour. And yes, it does pertain to duration – even if the duration is short.

You are absolutely correct when you say correct TC handling is crucial to offline/online workflow. And I do not claim that Adobe has solved the long-standing DF/NDF timecode handling issues. To be honest, I have not had to deal with mixed TC sources since the release of 2.0.

Oh, and the representation of the value 07:15:05:00 NDF as 07:15:31:04 DF is 100% correct.

Dave

[Timothy Eaton]

Dave,

What you’re saying is true for program duration, although I would be surprised if you can find a seven hour show. But in the case of capture the tapes are in exact agreement at the beginning of hour seven, to use the example. They haven’t been running for seven hours, but only (in the example) for fifteen minutes. A differential of 16 seconds after 15 minutes is well … “problematic,” (to use a nice word), since the offset between drop and non-drop is 3.59 seconds per hour. Make sense?

Further, the way in which Premiere changes my non drop code to drop frame when I change the program settings or import a project with different settings follows a logic I have yet to fathom, and in practice has caused us many problems. The example of creating a non drop offline file in a non drop project and having it show up as a drop frame offline file in the project window demonstrates Adobe’s inattentiveness to time code.

My sense is that Adobe still does not understand the importance of time code in making Premiere Pro the professional product it can be. I would love to be persuaded otherwise by a crack team of Adobe programmers that will solve this issue practically overnight and save us many hours of reconstructing a project (:-). But I’m not going to hold my breath.

Thanks Dave, Tim

[Tim Kolb]

[Dave Friend] “Oh, and the representation of the value 07:15:05:00 NDF as 07:15:31:04 DF is 100% correct.”

Hi Dave…

…it’s correct on a 7 hour timeline…but not a tape that started with hour 7 from the field.

This is indeed a REALLY bad problem if it is as described. I have been trying to reproduce here and am not seeing the same results…it all seems fine.

Tim-can you give me another specific instance where I can repro the issue?

TimK,

Kolb Productions,
Creative Cow Host,
Author/Trainer
http://www.focalpress.com
http://www.classondemand.net

[Timothy Eaton]

Hi Tim,

In Project Settings, under General, set the display format to Non Drop-Frame. In the project window, right click, select New Item then Offline File. Under Media Start, enter 06:04:00:00. Then under Media End, enter 06:10:00:00. Click OK. First, notice that the code appears as drop frame code. This alone is ridiculous. Also note that the differential between what you entered as the non-drop in point and what appears as the drop frame in point in the project window is 21 seconds 26 frames. This corresponds to the formula I gave earlier. 6 hours x 60 minutes is 360 minutes + 4 minutes is 364 minutes x 60 seconds is 21,840 seconds x .001 is 21.84 which is equivalent to 21 seconds 26 frames. Since this tape begins at hour 6 time code, we’ve only been running the tape for 4 minutes. 21 seconds is too big a differential over 4 minutes.

Yes this is bad, very bad, and it’s costing us a tremendous amount of grief.

Thanks for your interest!

Tim

[Dave Friend]

[Timothy] “But in the case of capture the tapes are in exact agreement at the beginning of hour seven, to use the example.”

No, they are not. 7:00:00;00 DF and 7:00:00:00 NDF are not the same value. It does not matter how long the tape has been running, the time value of hour seven is explicitly defined by the SMPTE standard according to the TC format in use. This is the way SMPTE has defined the standard. Adobe is simply following it.

[Timothy] “the way in which Premiere changes my non drop code to drop frame when I change the program settings or import a project with different settings follows a logic I have yet to fathom,”

As I said earlier, I have not had to deal with mixed TC formats in V2 yet so I cannot make informed comments. From the quick test I did, it seems that Ppro assumes that the value you enter for a New Item | Offline File is in the same TC format that the Project is using as the

[Timothy Eaton]

Dave,

Dave wrote: “No, they are not. 7:00:00;00 DF and 7:00:00:00 NDF are not the same value. It does not matter how long the tape has been running, the time value of hour seven is explicitly defined by the SMPTE standard according to the TC format in use. This is the way SMPTE has defined the standard. Adobe is simply following it.”

I understand SMPTE code, but drop frame is designed to accomodate for the difference in code over running time. Generally hour numbers are used to designate tape number, and editing software must take into account the fact that the hour number on tapes is arbitrarily set and has nothing to do with running time. Otherwise the drop / non drop differential on an hour seven tape starting at 7:00:00:00 will be 25 seconds when it should be zero, and the drop / non drop differential on an hour ten tape starting at 10:00:00:00 will be 36 seconds when it should be zero. That’s as well as I can explain it.

I have spoken with Adobe and they are aware of this issue, and understand that it is a problem. Whether they will fix it is another question. They’ve given me a workaround for creating offline files, which I will test and report back on this thread.

Thanks Dave,

Tim