looking for a iriver replacement

[Greg Miller]

Steve,

Thanks for confirming what I had suspected (and explaining the math) about video time stability.

If you set up a few different cameras side by side, and shot the same scene, would they all be pretty close (within a frame or two) at the end of an hour or so?

Still, I'm a bit confused as to why a clock rate error would cause the picture to get "scrambled." Wouldn't that just be analogous to cranking your film cam at 23.5 FPS instead of 24.00 fps? Sure, there is the additional complexity of sequential scanning, but I still don't see it.

After all, when NTSC TV was switching from 30.00 FPS (monochrome) to 29.97 FPS (color), that didn't cause any "scrambling." Each scan line took slightly longer, each frame took slightly longer, but the phase lock loops in the receivers could easily accomodate that change and everything worked just fine.

So, then, why would a slight clock rate error in a digital video cam cause picture "scrambling"?

[Steve House]

It can scramble when you have to cut between or mix sources with slightly different clocks. If you cut from one video source to another, the frame boundaries and the scan lines within the frames must be exactly "in register" with each other or there will be a glitch. In other words, camera A and camera B must start and end a field at exactly the same instant. That's why for live switching, each camera plus the switcher plus the title generator, etc are all genlocked to a common house clock. As it makes its way through a typical broadcast chain, the signal has to pass through any number of different devices, all of whom have their own clocks. One paper I read gave the example of a remote feed from a camera that doesn't have access to the studio's genlock that needs to be switched with picture from in-studio cameras that do. While there are circuits that can correct for minor variation from one device to another or for the fact that two asynchronous devices won't have the frames exactly "in register", they can only go so far. If the remote camera clock is too far from the studio clock driving the switcher, the picture will have problems.

[Greg Miller]

Thanks, Steve, I'm starting to see some of that.

Certainly I'm aware of the genlock situation, going back to the old days of vacuum tube camera chains. In a live switching -- or worse, a live fading -- situation, of course every source would need to be exactly in sync. You'd need to be at exactly the same point in the same scan line, or everything would be a mess, because you'd always be transmitting sync from the sync generator, and not switching sync from one source or the other.

But I still don't quite get it, in terms of editing. Let's say two cameras shoot a one-minute scene. One camera has 1798 frames, one one camera has 1795 frames. When these two files are imported into the NLE, there are now two sets of frames.

Couldn't you view either set of frames, by itself, without any problem?

And, if so, then if you start your edit with file A, and, at frame 500 you cut to file B, why would there be a problem? You're doing it at a frame transition, right?

In other words, does the NLE know or care that one frame from file A represents 0.0333704 seconds, while one frame from file B represents 0.334262 seconds? I'd think that once the files are in the NLE, a frame is a frame is a frame.

(Obviously, I work only on the audio side, someone else works on the video side... But I would like to understand this, just for the sake of increasing my overall knowledge of the world.)

[Richard Crowley]

Originally Posted by Greg Miller

But I still don't quite get it, in terms of editing. Let's say two cameras shoot a one-minute scene. One camera has 1798 frames, one one camera has 1795 frames. When these two files are imported into the NLE, there are now two sets of frames.

Couldn't you view either set of frames, by itself, without any problem?

And, if so, then if you start your edit with file A, and, at frame 500 you cut to file B, why would there be a problem? You're doing it at a frame transition, right?

In other words, does the NLE know or care that one frame from file A represents 0.0333704 seconds, while one frame from file B represents 0.334262 seconds? I'd think that once the files are in the NLE, a frame is a frame is a frame.

(Obviously, I work only on the audio side, someone else works on the video side... But I would like to understand this, just for the sake of increasing my overall knowledge of the world.)

Even when (not IF) camera clocks drift the bottom line is that they produce a different number of frames for the time period in question. If you are doing live switching (and especially wipes and dissolves) the video sources must be in exact lock-step together. And after the advent of color, the sync requirements bar was raised by an order of magnitude with not only vertical and horizontal sync-lock, but color reference (burst) sync as well to a fraction of a degree of the sine wave.

However, shooting multiple cameras without genlock indeed produces video files with varying numbers of frames for a given time period. Sometimes it is only a few frames and makes no difference, but sometimes (with long time periods and/or less accurate equipment clocks) it may add up to several seconds. And a similar phenomenon with video camcorders keeping pace with non-sync audio recorders.

To directly answer the questions, When dumped into a video NLE, yes, of course you can view either set of frames without any problem. And again, there is no issue with transitions related to the video frames themselves. Dumping your video files into an NLE has the same effect as "genlocking" the cameras together for the purposes of frame synchronization. However, it does NOT solve the time accuracy problem.

The issue is with what period of RealTime each frame represents. Unless you are in Boulder, Colorado and have your camera genlocked to the National Institute of Standards and Technology (NIST) time reference station (WWV, et.al.), no camera on this planet perfectly produces a frame in exactly 1/29.97002997002997... seconds. Even when cameras are genlocked together using a really accurate sync generator, they are never perfect. But it is close enough for what we do every day.

And remember that we got those weird (1/1.001) numbers when we devised the NTSC color standard to be backward compatible with the existing (RS170) monochrome system. And because of that difference between SMPTE timecode and Real Time, we must apply the "drop-frame" kludge to keep timecode synchronized to wall-clock time.

In the case of sources (video or audio) that don't agree in time period (even though "frame-synced" together in the NLE), we must apply corrective measures to re-establish video/audio synchronization (or video/video synchronization when cutting between different cameras). I do mostly live event musical productions and IME this is easier to do than it is to explain it. The easiest way to do this is to simply "pull up" the video track to match the reference audio track wherever there is a video transition. This simple method is sufficient for most purposes.

[Greg Miller]

Thanks, Richard. I certainly understand that for live switching "absolute" sync is necessary... and my earlier question ignored live switching and asked only about the NLE ramifications. I could not understand how a slight difference in frame rate would cause pictures to be "scrambled" in an NLE situation.

Originally Posted by Richard Crowley

shooting multiple cameras without genlock indeed produces video files with varying numbers of frames for a given time period.

And yes, I realize that if you lay down two video tracks and one or more audio tracks, each from a recorder with a slightly different clock rate, there will of course be "drift" in regard to real time, which will require a bit of extra work to fix.

Originally Posted by Richard Crowley

there is no issue with transitions related to the video frames themselves. Dumping your video files into an NLE has the same effect as "genlocking" the cameras together for the purposes of frame synchronization.

That's exactly what I thought. Hence I was puzzled by the comment that different clock rates would cause the images to be "scrambled"; perhaps I misunderstood something there.

OK, if I understand Richard correctly, the frame rate won't have any effect on the image quality of the individual frames; it will only affect the exact number of frames in a given time period. So then, to get back to the earlier question: is a video camera's timebase necessarily more accurate than an audio recorder's?

Since we're talking here about audio recorders that are basically consumer level (Tascam DR-0x, Zoom H1, etc.), let's talk about low price consumer level video recorders (take your pick). If we line up a few low price ($500?) video recorders and a few low price (100?) audio recorders, would the video recorders necessarily -- or even likely -- have timebases that are significantly more accurate than the audio recorders? Why or why not?

[Richard Crowley]

Originally Posted by Greg Miller

is a video camera's timebase necessarily more accurate than an audio recorder's?
Since we're talking here about audio recorders that are basically consumer level (Tascam DR-0x, Zoom H1, etc.), let's talk about low price consumer level video recorders (take your pick). If we line up a few low price ($500?) video recorders and a few low price (100?) audio recorders, would the video recorders necessarily -- or even likely -- have timebases that are significantly more accurate than the audio recorders? Why or why not?

Simply, no. Why would we expect above-average performance from any level of consumer gear? There is no fundamental difference between the kind of components used in low-price (<$1000) camcorders or low-price audio recorders. A mass-production crystal or oscillator is a commodity item just like any other component that gets soldered to the PC board. They are what they are. Some people are lucky and experience low error rates, but that is simply a law of averages. If you want real sync, then you must use equipment that sends/receives clock information from others.

In another forum I prognosticated that it seems likely that someone will (or should!) offer an audio recorder that accepts the video monitor signal from your camcorder (or DSLR) and uses that video clock to phase-lock the 48KHz (or 96KHz) audio sample clock. Modern digital technology makes this so simple I'm surprised this isn't available already. It is likely only the (relatively) small size of the market that keeps it from being available now.

[Steve House]

Agree with Richard - was thinking of higher level cameras than the sub $1000 consumer cams when I wrote the camera would have a better clock.