[opendtv] Re: Half Truths - Was More 1080p@60
----- Original Message ----- From: "Tom Barry" <trbarry@xxxxxxxxxxx>
This all seems more confusing then it should have to be, so maybe I'm missing something here.
First, 30/1.001 is not an irrational number since it is exactly equal to 30000/1001 and an irrational number is a real number that cannot be expressed exactly as a fraction n/m of two integers.
You're right, Tom. The actual number is 29.9700299700299700299700299700... It is a repeating decimal, not an irrational number.
Ditto for 59.94 being 59.9400599400599400599400599400... and 23.976 being 23.9760239760239760239760239760... 

I apologize for my incorrect mathmatical term.
But more practically if you started with 24fps video and just regularly counted frames, always dropping the last one out of every 1001 then it seems that, at least in the long run you would be exactly correct, with no cumulative errors. And it would also be exactly correct every 41.8 (1001/24) seconds or so. Wouldn't that be better than every 2 minutes?
It is true that when 29.97 drop frame timecode came about, it was in the era of simple logic gate electronics, and it wasn't very hard to create a logic gate array to do the math of 'drop two frames every minute, execpt for every 10 minutes.'
Today, if you were to create a new way to do drop frame for 23.976 video you would need some scheme that both uniquely identifies each frame, and is predictible so when you are editing tape and you wish to back up exactly 15 frames, you know what the target timecode value is no matter if you cross a drop frame boundry or not.
I suppose you could simply have a microprocessor use a lookup table that says "if the timecode is 00:00:41:16 (1000 frames) then the next count is 00:00:41:18, if the timecode is 00:01:23:10 (1000 more frames past 00:00:41:18) then the next count is 00:01:03:12", and so on for the entire 24 hour period.
To do that would require that every VCR, Camcorder, Editor, Timecode Generator, etc. be equipped with a microprocessor and a lookup table of skipped timecode values to do the math. This would be necessary so that when a VTR is told to cue to a 3 second preroll point, and the deck is parked at 00:00:44:17, it knows that the target timecode to park at next is 00:00:41:16, not 00:00:41:17, which doesn't exist under your scheme.
However, when using 23.976 video, there are 2071528.4715284715284715... frames in a 24 hour period, so even with your scheme you'd still drift away from real time by half a frame a day. Not much but it accumulates so you'd have to jam sync your source to real time once per day anyway.
So the tradeoff would be a scheme that was off by only a fraction of a frame per day but requires a complicated lookup table to determine which frame counts are to be skipped, or a simple rule for determing which frame counts to be skipped that humans can remember but would be off by almost 5 frames per day.
Maybe in this day and age that would be a better approach than trying to recreate the old fashioned simplified NTSC drop frame timecode scheme and it's inaccuracies. As I said, this is ripe for a SMPTE paper, and a SMPTE standard. With the proliferation of HD programming in the n/1.001 framerates, I'm surprised this hasn't been addressed sooner.
John 



----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org 
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word 
unsubscribe in the subject line.

Other related posts: