Hi folks,

This was also recently brushed on here (with gammaburst & others):

http://www.sonicfoundry.com/forums/ShowMessage.asp?ForumID=4&MessageID=109642

Ain't math fun?...


Cheers, MPH

It is interesting. What happened to the good old days of b&w and 30fps? :)

Apologies for not fully understanding before writing!!!

I recaptured a video that I PTT via Vid Fact. 1.0.
When put back on the timeline, it plays back fine and will PTT again fine, but there must be at least a 5 sec. delay before the audio starts playing back when playing the file in WinMedPlayer. Wierd. Oh well.

Oops, scratch that. It is playing in sync just fine now. My Bad.

DaveT2,

Keep in mind that it doesn't require even close to an entire frame of skew to skew a track by a frame.

When you drop a video event onto the timeline, VV determines what frames it will use based on what frame is aligned at the START of a frame boundary. This is one of the reasons the 'quantize to frames' feature was created, to help prevent frame boundary errors.

You can see this for yourself by:

1. Turn on quantize to frames
2. Putting a video event on the timeline (Make sure it starts on a frame boundary
3. Creating another video track & placing a copy of the same event driectly underneath it.
4. Place a marker right on a frame boundary a few frames in from the start
5. Turn off quantize to frames
6. Shift the copied track a fraction of a frame to the right (an I mean a fraction, you can zoom in all the way & move it a few pixels -- that's all it takes).
7. click in the middle of the the frame directly after the marker (so you can see that frame)
8. toggle hide/unhide of the first track & compare what you see in the preview window.

You should see a 1 frame skew, even though you only moved the 2nd track by say a 20th of a frame. That's because in VV, where the frame boundary occured, the edge of the previous frame was underneath it, so that became that frame.

You'll never see a frame change occur in the middle of the project frame boundaries, even if the video clip frame boundary is misaligned.

So in VV, you CAN'T ever have an error of a frction of a frame. It's always on the boundary, so when it shifts, it shifts an entire frame.

I had my first error at 87 frames, which is +0.00261 seconds skew, and while's that seemingly nothing, it's enough to exhibit this behavior in VV3.

BTW, if you take a quick look on google groups for 29.97003, you'll find a bunch of articles from video engineers that explain the equations for why it's 29.97003 & not just 29.97 -- Even the link I provided showed someone else with the same issue.
Here's one of the first articles I found

I am confident that this is the issue. The issue is with the frame capture tool setting the .AVI fps values to 29.97000 instead of 29.97003.

SoFo has not done anything wrong, but be MORE accurate that other apps out there & the misconception of what the practical standard is. The only fault I find with SoFo is their inaccurate descrptions can be misleading, so just change the preset name to reflect the true accuracy.

We'll probably need SonicEPM or SonicDennis to intervene on this issue to settle it.

I printing the same file with VidCap & captured it in with NO issue.

- Jon

Martyh,

Thanks for the defense on this.

- Jon

Actually, it's 30,000 / 1,001, not 29.97003 (it's a repeating fraction, so it's 29.97002997002997...).

Any hardware that is capturing at 29.97 (exact) is going to drop a frame every now and then, but there is no such thing since capture hardware syncs to the incoming signal, which is theoretically 30000/1001.

The problem is that some capture software incorrectly marks the file as 29.97 (exact) when it really should mark it as 30000/1001.

Likewise, it sounds like After Effects works in 29.97 (exact) which, as you point out, is not correct.

Vegas, being media format agnostic, says "fine, you can drop 29.97 media into this 30000/1001 project, but it's going to slip a frame every 9.2 hours". The time-to-frame math happens to work out such that the first frame slip happens near the beginning (apparently frame 5), and then again 9.2 hours later, but I suppose it's the one in the beginning that's bugging you.

You are right that Vegas is doing the right thing <g>.

Possible fixes for these bad captures and renders would be to take any incoming 29.97 media and treat it like 30000/1001, but there could be audio sync issues with that (or, it might *fix* audio sync issues due to the incorrect frame rate, at least in the capture case). Or, the time-to-frame logic could be re-worked so that the first frame to slip was at least an hour downstream, but that could have other effects.

In the meantime, if you just capture or render out a enough "header" (apparently, 5+ frames) so that the first slipped frame is never accessed / used, you'll be fine.

I wonder what AE does with true 30000/1001 footage, if it works in 29.97? It may drop a frame somewhere, which would be the inverse of Vegas duplicating a frame. Or, it loses audio sync.

To further muddy the waters, SMPTE drop-frame timecode ends up being 29.97 (exact), so it *still* drifts from wallclock time (1 frame every 9.2 hours), but not nearly as bad as non-drop (108 frames per hour).

///d@

Does the DV format, when it's on a device (camcorder etc.), have provisions to set the frame rate? I guess what I'm asking is if the video stream has the frame rate set in it, so the camcorder adjusts playback speed for 29.97 or 29.97003 sources?

If you rendered a 29.97 projectd to a DV tape, would it play at a different rate?

I'm curious if I probably encountering a capture issue, or is it a print-to-tape issue? When you're capturing, does the DV stream inform the capture device what it's framerate is?

- Jon

No, NTSC DV plays at 30000/1001 on your camcorder. There is no way to mark it as "29.97" and have it play at that.

That said, it's based on the crystal in the camera, which has some error to it, so if you start two camcorders on exactly the same frame number, by the end of the tape, they may have drifted some. This is the reason the pros use timecode master/slave setups and house sync to tie all of their devices together to the same "heartbeat". That way, all devices, audio and video, will alway be in sync. Pro devices can sync to external clock or sync.

///d@

to clarify, NON Drop timecode does not drift anymore than drop frame. But in non-drop there are too many numbers, so you end up with more numbers than you have frames.

It would be like making a calendar with every month having 31 days. At the end of the year, you would have 372 days. Non-drop makes math easier for editing systems since you don't have to calculate the frames that are dropped. And is practical for most short format editing.

Dave T

To clarify non-drop:

"But in non-drop there are too many numbers, so you end up with more numbers than you have frames."

Whoops, actually... every frame has a number and every number has a frame, the frames just run slow:

Non-drop TC does not increment as quickly as real-time and will not match the clock on the wall, beacuse video runs slightly less than 30fps.

DROP-frame TC increments a tad more quickly to match the clock, by skipping a few numbers along the way.

HTH, MPH

I mis spoke a bit. and thanks for the correction. Non drop counts the number of frames, but not the actual time elapsed. 900 frames would equal 30 second time code in non drop, but the actual time elapsed is different. Drop frame compensates for the difference in frame count and actual time by dropping frame numbers. I edited this part because it was incorrect, thanks to MartyH for catching. His next post is in reference to my incorrect information.


I have always kept in clear in my head by thinking of the movie Amadeus when they said there are too many notes. Too many frames. :)

My original point though was to clarify that this is not a "drift" per se.
Dave T2

Hi Dave,

I'm not trying to pick on you, really.

Drop-frame TC drops two frames a minute, except for on the tens.

2/min for 60 min = 120, less the tens (6x2=12) = 108/hr skipped

Yer point is taken on it not being a frame/TC drift, aside from the math issue SoFo indicates.

Cheers, MPH