Re: [tt-af-1-0-req] Some (late) comments on the requirements

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 20 January 2004 09:55 am, Johnb@screen.subtitling.com wrote:
> Are you from a 'fansub' background?
Somewhat, though I've moved to doing mostly just programming and design for 
the time being. One of my projects is to create tools for authoring the TT 
format (using a temporary XML format until specs exist) and displaying them 
on video.
>
> > On Monday 19 January 2004 02:56 pm, Johnb@screen.subtitling.com wrote:
> Basically you say "the video file that goes with the timed text will also
> be paused". In a broadcast environment this is not possible. You CANNOT stop
> the video..... E.g. It is coming off a server, through an MPEG encoder and
> up to a satellite.
Ah, I was assuming you were doing the subtitles at the same place the video 
was being broadcast originally. Personally, I would suggest seperating parts 
of a TT file into scenes and marking subtitles with (very accurate) 
percentages through the video. Then it would be easy to adjust to different 
source files or media.
> > > Basic colours (for text - 16 colour model is sufficient)
> > 16 colours per dialogue may be sufficient, but overall it is
> > unlikely to be enough. Usually when I subtitle something, I use different
> > colour schemes to represent who is speaking. Timed text (not just
> > subtitles) also would involve displaying, for example, the title of a
> > movie or similar
> > which could very well need complex effects including colour fading.
> Broadcast subtitling also uses colour for dialogue. E.g UK Teletext.
> Teletext is limited to a basic colour set.
So you're looking at TT as a format which you convert when streaming it. I'm 
looking at TT as being the format that is actually streamed.
> Speakers are allocated a colour, but often colours are re-used
> if a character no longer appears in the program.
Even reusing previous characters' colours, there are still many different 
characters which would go over using 16 colour shades.
>
> Extra colours would be usefull for more creative purposes, but
> they are not IMHO essential.
They would be essential for a do-everything-TT format, which I hope is what 
the TTWG is meant to create...
> There is also an issue about how many colours 
> could be easily distinguished from each other. Certain colours
> do not show well on video, and it is more difficult to distinguish
> quickly between colours that vary by intensity but not hue.
One could also argue that 256 colors is plenty for images too.
> > > Background colour and box styles <SNIP>
> > There are also usages where one would only want a combination of an
> > outline, a shadow, and/or a box. I often use a combination of custom
> > outline and text colours to indicate who is speaking.
> Broadcast subtitling is very restricted in the features available since it
> is rarely burnt-in. DVD subtitling is much less restricted (though tends to
> follow broadcast conventions).
I would be thinking more of a format similar to DVD, but using MPEG-4, Vorbis, 
and TT as the standard formats for the content. In this case, there would be 
no restrictions by conversion formats.
> > > Transparency is used for background. I have never seen reversed text
> > > (i.e. background solid with transparent text).
> > I have on occasion seen semi-transparent foregrounds and rarely (but it
> > does exist) seen completely transparent foregrounds. One such example of
> > semitransparent foregrounds can be seen in the openings of most (all?) of
> > the opening for the .hack//LIMINALITY anime series by Bandai.
> The use of transparency for foregrounds seems contrary to one aspect of a
> caption or subtitle, which is to remain readable :-) I guess it's not so
> important for the title or credits :-)
It's quite readable. The credits in this example are only slightly 
transparent, enough to see the background behind them.
> > > Vertical text has yet more rigorous demands, but is typically produced
> > > as graphics that are burnt over video.
> > A complete TT format should remove any need for text to be burnt into
> > video. 
> > If that is not to be the goal, the format would be better suited as only
> > a captioning/subtitling format, and not timed text. Timed text is very
> > broad and covers much more than just captions.
> TT AF format does not remove the need or desire for burnt-in subtitling.
> How do you retro-fit a TTAF decoder to 100 million TV sets?
> TTAF is not primarily a distribution format (tho it could be).
> In truth, I suspect TTAF may be too top heavy for captions/subtitles,
> though I am reserving judgement until I see the Specification draft.
> But this is a difficult balance to achieve. TTAF needs to be applicable
> to broadcast captioning / subtitling (surely a major target area),
> multimedia, and generic text over time (e.g. scrolling text displays,
> timetables, teletext magazine services etc.)
Convince the TV industry to move to using MPEG4/Vorbis/TT for distribution 
content. ;)
Simple enough to do it for a DVD-replacement format though...
>
> > > Finally - although a distinction is (rightly) made concerning captions
> > > and subtitles, in terms of the system requirments for their display
> > > there is very
> > > little difference. Captions may use more features for display than
> > > subtitles, as captions carry non speech information as text and this
> > > may be rendered using colour or styles that would not normally be used
> > > for speech related text display.
> > Though not perhaps the technical definition of subtitles, they are
> > usually considered to include overlaying translations of visual items
> > making them much more complex than captions.
> Actually that is more of a definition of 'description'.
>
> According to SMPTE:
> subtitles are translation of dialogue
> captions are dialogue and sound effects in the same language (no
> translation) (i.e. for hearing challenged)
> description is text substitute for the visual items (i.e. for visually
> challenged)
I am referring to translations of visual items.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFADZKzZl/BHdU+lYMRAt0yAJ46oKflZtlHuAxfChd6h085hrhC3QCeOK0w
jt1bLm+ZeEFKaISX+3iEyaU=
=wQa1
-----END PGP SIGNATURE-----

Received on Tuesday, 20 January 2004 15:43:16 UTC