Re: Roll-up captions in WebVTT

On Mon, Dec 19, 2011 at 3:20 AM, Glenn Maynard <glenn@zewt.org> wrote:
> On Sun, Dec 18, 2011 at 3:07 AM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> On Sat, Dec 17, 2011 at 1:05 PM, Glenn Maynard <glenn@zewt.org> wrote:
>>> It's not backwards, but if you havn't seen it in realtime and don't know
>>> what I'm talking about, the above description probably isn't enough.  Let me
>>> know if you want a more detailed description (or I'll dig out an example).
>>
>> I've seen it in some Karaoke videos, but never with actual captions.
>
> All subtitles I've seen work that way.
> https://zewt.org/~glenn/overlapped-caption-example.mpg  That's a
> relatively complex example, with multiple disconnected streams of
> dialogue, and I find it easy to follow while still paying attention to
> the actual video.

Must be a cultural thing. I totally lost track of where my eyes were
supposed to look at in this example and found it impossible to follow.
I would have much preferred scrolling captions on this one so I would
know where the next text will appear.

I've not seen any captions done this way other than the ones you have
pointed out.


>> And to be honest, I found the need to have my eyes jump first down a
>> line to read the next, then up a line to read the next etc much worse
>> for reading than others where the lines move. In the first case my
>> eyes have to continuously re-focus on alternative lines above and
>> below, whereas in the second case my eyes will focus on what I am
>> reading and move with the text motion, then jump down a line (which is
>> a movement they are used to from normal reading).
>
> I'm not looking from one caption to the next; I'm glancing down from
> the video at one caption and back to the video, then at the next
> caption when it shows up, then back to the video.  My eyes don't rest
> on captions any longer than necessary.

In that case it's even more complicated, because you do not know which
line will disappear next and where the new text will next appear. It
seems to me that because you've only ever seen this style of captions
you have created tactics to deal with it. It totally confuses me
though.

Anyway, all this just confirms what I am saying: we need both means of
displaying.

BTW: I have a focus on the captions and watch the video more
peripherally. The study that was shown earlier also supports that this
is the more general watching pattern.


>> My argument is that there are situations where scrolling captions are
>> needed and they are not necessarily rare or worse for everyone to
>> watch. It's a different presentation that some prefer and others
>> don't.
>
> I don't think we're talking about preferences here, though, just
> authoring needs (eg. live captions), right?  Viewing preferences are a
> different matter entirely--those should be up to the user, not baked
> into the markup.

I don't think you can do rollup as a preference - how would you do
that? I think you have to provide two different files with different
makrup for people to choose from if you want to support both means.

I believe it may be a cultural issue whether you prefer one style or
the other: in the US, rollup seems more natural and your examples all
seem to be from Japan, so I assume there it's more natural to swap out
lines. So, as an author, you'd create the captions in the appropriate
way for each language.

However, as it stands, we don't have a sensible means to create the
rollup effect. This is why I've started this thread.


>> Therefore we should have a standard means of doing them rather
>> than having to do awkward text copying to simulate the effect (and
>> screw up all useful automated analysis of the text).
>
> Duplicating captions would be evil, of course (think about what might
> happen if the track was being output via TTS), and much more evil if
> someone was trying to fake smooth scrolling (dozens of duplicates per
> caption).

That's my point: it's currently the only way to achieve scrolling
captions and it's evil. Therefore we need a better way.

Cheers,
Silvia.

Received on Monday, 19 December 2011 00:02:26 UTC