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

> >  > > 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.

> >Well it wasn't exactly a joke. The point was that if you use a duration
> >based mechanism, and you wish to support slow play or reverse play (or
> >random access), then you invoke a large number of conversions from the
> >duration based representation into an absolute time representation. If
you
> >start with an absolute time representation - then all that is necessary
for
> >reverse play or slow play is to alter the rate (or value) of your
(internal)
> >clock. Duration based mechanisms buy you nothing - and cost you lots.

Ok - so maybe that last sentence was a bit strong :-)

> On the contrary.  Given a document with relative durations, inserting 
> or deleting a segment is easy;  everything naturally moves up and 
> down when you do that.  If the document uses absolute values, rather 
> than relative, this is painful.

Absolute timecode values work extremely well for broadcast subtitling!

Obviously, if you **want** the following sections to move - then just insert
a new segment.
You say using absolute values makes inserting a segment painful - of course
it does IF you want to alter the duration of the entire presentation. BUT
that is not what I am trying to emphasise.... Subtitles are created against
a master tape. The duration and content of that tape is fixed and not
altered by the subtitling process.
What is created is a file containing text and timecode-cues that refer to
the timecode that was put on the tape when the master was created. So
inserting a subtitle is NOT about altering the duration of the presentation,
NOR is it about moving any subsequent subtitles - it's about creating a new
entry for a previously untitled piece of speech.

> One of the simplest uses is a timed-text file with relative 
> durations, displaying (for example) captions, layed into a SMIL 
> presentation in 'par' with the video and in a separate region.  This 
> ought to work...

Great - 'ought to work'. I've looked at this and don't see how it can within
my area of expertise (broadcast video). This is what I'm trying to get
across.
If you have 'par' layers, how do you cater for when the video one is stopped
externally. Remember - the video layer is not under the UA control. The UA
doesn't start the video layer (though it can detect it starting). Remember
also that the video layer can run at any speed and in either direction -
these also can be detected (by reading tape timecode).

One way you **could** do it using SMIL 2.0 is to use markedmedia - but this
doesn't seem to be designed for matching SMPTE timecode on a tape with
elements within the SMIL presentation.
 
> I don't disagree that perhaps SMIL needs some concept of how to align 
> time-codes in two 'par' media, but that is a composition question 
> that ought to be addressed in SMIL.

Ahhhh - finally. SMIL needs a concept of how to align timing (with external
time representations).

Let's put this straight - I've never said SMIL should not be used, nor XML
for that matter - but I have reservations about using XML, and don't see how
SMIL in it's current form matches with what is required in broadcast
subtitling. I'll state it plainly - IMHO duration based, relative timing is
not appropriate for broadcast subtitling. I suspect this view is shared,
since I have NEVER seen a subtitle file of any format - including
competitors - that uses relative timing, though some use absolute starts
plus durations.

regards 
John Birch

The views and opinions expressed are the author's own and do not necessarily
reflect the views and opinions of Screen Subtitling Systems Limited.

Received on Thursday, 13 February 2003 05:07:35 UTC