[opendtv] Re: Half Truths - Was More 1080p@60
- From: "John Shutt" <shuttj@xxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Sat, 8 Dec 2007 11:08:37 -0500
----- 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:
