- From: Luke-Jr <luke-jr@cox.net>
- Date: Tue, 20 Jan 2004 20:42:24 +0000
- To: Johnb@screen.subtitling.com
- Cc: public-tt@w3.org
-----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