Timecode FAQ
Why is timecode important?
Timecode is important because it identifies individual frames of your video and
is used throughout any video editing system. It's rather like the page numbers of a book.
If you want to look up a page or keep track of where you are being able to assume that
page 235 comes 15 pages after page 220 is pretty fundamental! If your page numbers
are out of sequence, have gaps, or repeated sequences then things get very confusing
for the reader. Likewise, if a video tape has discontinuous timecode similar confusion
occurs for a non-linear editing system, in particular when it comes to finding a clip
on tape again during batch capture.
If you want to keep your sanity it's vital to ensure that you record continuous
timecode on your tape!
How do discontinuities on tape occur and how do I avoid them?
Whenever you change tapes (eg. to start recording a new tape from the beginnning)
your camcorder resets its timecode counter to zero. If you play a previously recorded
section of tape, the camcorder reads the timecode from the tape and carries on
using that when you resume recording. If you play or fast forward beyond the end
of the recording the timecode also goes back to zero, so if you resume recording
from there you will have discontinuous timecode. To avoid discontinous timecode,
use your camcorder's "End Search" facility if it has one whenever you change tape
or whenever you rewind and then play or fast forward the tape. If you don't have
an End Search facility then you need to play the tape briefly after inserting it
or fast forwarding it, and stop it again before it goes past the end of the recording.
Watch the timecode display and make sure it doesn't go to zero!
Why do people recommend pre-striping tapes?
The theory goes that if you record something on the whole length of a new tape before
you use it for the first time (eg. leave it recording with the lens cap on) then if
you fast forward past the end of your recording the camcorder will still find the correct
timecode on the tape and will carry on using that rather resetting to zero. In my experience
however it is still possible for the old and the new timecode values to be out of step
by a few frames, but now rather than blatantly starting from zero again it's much more
difficult to spot the problem!
I believe the idea of pre-striping comes from the
days of analogue linear editing systems, where the normal way of working was to lay
down material one track at a time: first pre-stripe the tape to lay down a control track,
then record the audio, then cut the video to the soundtrack using insert editing. In
my opinion it's not particularly relevant to DV or NLEs.
What if I screwed up and my tape has discontinuities after all?
There are two approaches to dealing with a tape with discontinuous timecode:
If the timecode on a tape resets back to zero at some point
then you could treat the two sections as separate virtual tapes, eg. "Tape 11-a"
and "Tape 11-b". When EditDV prompts you for one of these virtual tapes during batch
capture you manually spool the tape to the appropriate section before pressing Ok.
Alternatively, assuming your camcorder has DV-in, you can manually capture the
offending material and then print it back to video with new continuous timecode.
Spool the tape to just before the timecode breaks then start playing and perform a
manual capture into a new temporary project. Trim off any surplus material from
the start then copy the clip to the timeline. Rewind the tape to just before the
timecode break, press play, then pause it before it gets to the break. Now you
can print the clip to video, overwriting the original recording with the broken
timecode. A useful feature of DV camcorders in this context is that they will
always (re-)generate the timecode themselves when recording to tape but they
will preserve the date and time of recording and exposure data from the original
recording! (Although it's slightly cumbersome you can use this technique whenever
you need to do tape-to-tape copies with a single camcorder.)
Why does EditDV report a discontinuous timecode when my tape is ok?
If EditDV reports discontinuous timecode errors when you do a batch capture the
first thing to do is carefully check the tape, stepping through a frame at a time
if necessary, to check whether there is a problem on the tape and if so deal with
it as suggested above. However, under certain rare conditions it is possible for
spurious discontinuous timecode errors to be reported, where the tape is ok but
the batch capture still fails.
What seems to happen is that after capturing
so many minutes worth of video in one clip the system temporarily freezes while
the tape carries on playing and then when the system carries on capturing time
has moved on and so an error is reported. Only the Macintosh version of EditDV
seems to be affected and it seems that the cause may lie elsewhere in the system
(eg. in the operating system or in the disk drivers) not in EditDV itself.
The curious thing about this problem is that it usually occurs the same length
of time into a capture, irrespective of where on tape you are, though the time
it occurs at varies from system to system. On my system, for example, batch
captures of more than 6-1/2 minutes would fail. If a clip started at 10m00s
it would fail round about 16m30s, if it started at 11m00s it would fail at
17m30s, and so on.
If your system is one of the few affected by this problem,
the fix is to make sure that you are running with minimal extensions, have
disabled networking, have turned off virtual memory and set disk cache to the
minimum as recommended in the EditDV manual. If the problem still occurs, reduce
the length of the clips being captured so they stay below the cutoff length
that causes problems.
What's drop frame timecode?
Fortunately, those of us in PAL-land don't have to worry about such things :-), but
for historical technical reasons NTSC broadcasts 29.97 frames per second. If you
round this to 30 and number your frames accordingly then timecode will no longer
correspond to elapsed time, so to correct this drop frame timecode skips over
certain frame numbers. The frames themselves aren't dropped, just the numbers.
To understand what's going on better it might help to think it terms of simpler
numbers. Imagine a system using 9.5 frames a second, say. You might label frames
by counting 10 frames one second and 9 the next. You haven't lost a frame, just
skipped one number every 2 seconds in your counting sequence to keep things in step.
Drop frame timecode is the same, except it skips 2 frame numbers a minute, 9 minutes
out of 10 ((10 minutes - 2*9) / 10 minutes = 17982/18000 = 29.97)
EditDV always uses drop frame timecode when dealing with NTSC (as indicated by the
semicolon when writing timecode, eg. 01:12:35;28), so if your camcorder can be
set to drop frame or non-drop frame timecode use the drop frame setting, and if
you're generating a capture log by hand make sure you don't enter any illegal
timecode values or EditDV will get very confused!
Return to DV home