Leap Year And Drop-Frame Time Code Are Conceptually The Same

Community member Alan Hardiman sent this over to us; it’s so good, we thought it best to simply run it rather than try and rewrite it.

For those in the media production industries, February 29th is a good day to revisit drop-frame SMPTE time code, because both leap year and drop-frame time code came into being for the sole purpose of reconciling two different time bases on which we do things with mundane regularity.

Take the calendar first: our calendar simply charts the sequence of the individual days that comprise a single year. The day is based, of course, on a single rotation of the earth on its axis, whereas the year is based on a single revolution of the earth around the sun. Rotation and revolution are the two different time bases on which our calendar is constructed.

Since it takes about 365.25 days for the earth to revolve around the sun, we collect four of those quarter days and add them together into a single day—February 29—that appears on the calendar once every four years.

We do this because there’s no such thing as a quarter-day: you couldn’t start a New Year at 6:00 a.m. After all, a day is a day and cannot be partitioned like that. It’s an integer.

It’s important to see that the concept of the yearly calendar comprises 366 days—February 29 is not imaginary. But rather than adding a day every four years, what we are really doing is dropping a day from the calendar in every year that is not a multiple of four. If the year is not divisible by 4, then we drop February 29 from our count of days in that year.

It’s exactly the same with drop-frame time code, where frames are analogous to days, and hours to years. A video frame is a whole thing, an integer, and we count 30 of them in one second. But the rate at which they proceed is a bit less than 30 per second, more like 29.97 frames per second.

This is the same sort of fractional discrepancy that exists in the annual rate of 365.25 days per year.

We deal with it the same way, by dropping 2 frames from the count at the very beginning of every minute that is not a multiple of 10. In that first second, there are only 28 frames.

So frames 00 and 01 simply do not exist at the beginning of every minute of time code that doesn’t have a zero at the end of it (10, 20, 30, 40, 50, and 00 minutes being the exceptions), just as February 29 does not exist in any year that can’t be divided by 4. It’s as simple as that.

Why go to the bother of doing this? For the calendar, it’s long been considered important that the seasons start at roughly the same time every year: if we didn’t have February 29 as a corrective, then the beginning of Spring, for example, would progress steadily back through February, January, December, and so on as the years rolled by.

For producers, it’s important that the time displayed by your time code reader agrees with the real-time clock on the control room wall. Without drop-frame time code, a one-hour program as measured by your time code would actually run 3 seconds and 18 frames to long, and that would wreak havoc with broadcast schedules.

Note that what we are NOT doing is cutting out frames from our program and leaving them on the cutting room floor, as some of my former students at the Toronto Film School used to believe. Those “dropped” frames are simply never there in the first place, just as February 29 will not “be there” in 2013, 2014, and 2015. The calendar works as “drop-day” code.

The takeaway from this blog entry is that if you can intuitively grasp the concept of leap year, then you’ve already got the essence of drop-frame time code. Conceptually, they are one and the same.