Re: Why use time as a unit of measurement? (was: Proposal 0.0)

If exact sync with a frame of video is a requirement, then your clock will 
have to be much more precise than you may be thinking - has to do with how 
analog television timing works (it's not really 30/25Hz frame rates - there 
is an error of 1/1000).  That's one reason why "time" in television is 
actually {time, frame} (aka SMPTE 12M), where time is only to the second 
and frame is the frame within the second.  If you don't do this, then at 
some point you will indeed get off by one frame.  But if you relax the 
requirement to +/- 1 frame (way better than is done in practice by the time 
the viewer actually sees the text), then simple timelines work fine.  But 
on the otherhand, why not permit multiple timelines and avoid the 
argument?  In addition to SMPTE 12M, there is the new SMPTE ATR.

At 08:04 PM 2/11/2003 -0800, lists@wiltgen.net wrote:

>Johnb@screen.subtitling.com wrote...
>
> > FileX is indexed against the timecode that is stored as VBI data on TapeX.
> > So unlike SMIL - the media are separate - subtitles in one - video and
> > audio on another.
>
>You can forget about SMIL, although I think that understanding what it is
>a useful prerequisite for anyone who wants to contribute.
>
>Unless I'm missing something, Proposal 0.0 works just the way you would like
>-- subtitles in one file, video and audio in another.
>
> > In practice, the broadcaster will want to show adverts. These can occur
> > at **any time** during the broadcast, and may differ from showing to
> > showing...
>
>In my previous post I described how this would work.  (Please let me know
>if the explanation didn't make seise.)
>
> > Subtitles are frame accurate for lip synching.
>
>I've explained a few times why time (rather than frame-based timecode)
>must be used.  As two examples, the TT should still work when taking a
>24fps film source to NTSC, or to the web via a QuickTime movie with a
>default timebase of 600 units/second whose video content is encoded at
>12fps.
>
> > I can conceive of other situations where the assumption of 1 sec per sec
> > is invalid.
>
>I know you're not serious, but I don't get the joke.
>
> > ...timebases can always be converted into a single format.
>
>Exactly, and that single format is time.
>
>-- Charles Wiltgen
>    <http://playbacktime.com/>

-----------------------------------------------------
Michael A. Dolan  TerraByte Technology    (619)445-9070
PO Box 1673 Alpine, CA 91903 USA  FAX: (208)545-6564
URL:http://www.tbt.com

Received on Wednesday, 12 February 2003 09:11:36 UTC