[Timothy Eaton]

Okay, we’re all in agreement about how time code is calculated for duration — hour zero. I agree. I think you are both terrific and very sharp. But what I’m disputing is how PPro 2.0 handles code when you switch from non-drop to drop on material that has been previously digitized as one or the other. In PPro 1.5 there was no penalty for having your project file set incorrectly, drop or non drop. 1.5 correctly identified the captured material as drop or non-drop and you were on your way. But when you then import that project to 2.0, it converts the files that were captured under drop frame project settings to drop frame code, whether or not it was drop frame footage. This makes your list crazy. And when it does the conversion it calculates from hour zero without compensating for the fact that hour zero on a tape is effectively the beginning of the tape, regardless of the hour setting of the time code. Furthermore PPro 2.0 incorrectly lists manually entered non drop time code as drop frame, and will not capture it correctly, at least in the New Item / Offline File mode.

Thanks for the tip on using Capture for time code entry Ken; that may be helpful. Note, however, that when you enter the code as non drop frame, it appears in the project window under Video In Point and Video Out Point as drop frame. I’ll need to test to see whether this is an issue with capture, offline, or recapture.

I do appreciate you guys taking this up and you’re bang on about the nature of time code. It’s just that when 2.0 makes these conversions it needs to take into account that the beginning of the tape is effectively hour zero.

Tim

[Timothy Eaton]

Good for you Dave. Hold firm.

Tim

[Timothy Eaton]

Dave,

I don’t know how to communicate this any better. We’re just not talking about program duration — the software needs to take that into account, otherwise there is no way to capture accurately. Take Tim Kolb’s word for it if you won’t take mine:

“Hi Dave…

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

Tim Kolb, can you explain this to Dave?

Thanks, Tim

[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

[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

[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

[Timothy Eaton]

Thanks for the links Steven!

[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]

Ken,

The source material is DVCPro HD from a Panasonic AJ HD1200 deck outputing composite SD video for offline editing, digitized with a Matrox RTx.100 card. But 2.0 converts all of that code to drop frame even if I unlink the video files and make them all offline, so they are no longer seen as a Matrox DV file, and in the process of converting them to drop frame, it offsets them dramatically and unpredictably. This is why I decided to see what would happen if I simply created an offline file in the project window. I was willing to re-enter all of our digitized files manually from an old list. (You can try it yourself — it only takes about ten seconds to create one) But the fact that 2.0 alters the simplest user created offline file, essentially making it useless for digitizing rules that plan out. I’m hoping to hear there is a simple solution (not a workaround) for this.

Thanks for any help you can give. Tim

[Timothy Eaton]

Troy,

Thanks very much for giving it a try. Maybe an Adobe connected reader will also take a look at this — it would be great to hear that there is some simple answer!

I’ve been a long-time Premiere user and we’ve had various problems with time code in the past. But with 2.0 I assumed these problems would go away since there are other fine improvements. How hard can it be to write a software module that deals accurately with time code since it’s an absolutely essential component of video editing systems? I’m not going into full rant yet, but I’m thinking about those sixty hours of digitized footage duplicated on three Premiere offline systems with three editors using the same footage, several hours of selects, and fifteen minutes of edited program with hundreds of edits. Ouch.

Thanks again Troy,

Tim