[Bug 13943] <track> The "bad cue" handling is stricter than it should be

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13943

--- Comment #15 from Philip Jägenstedt <philipj@opera.com> 2011-09-28 08:39:51 UTC ---
(In reply to comment #13)
> (In reply to comment #11)
> > I agree with Philip. The parser shouldn't drocanianly drop cues for trivial
> > authoring mistakes. I don't know if we need to polish the parsing of the id
> > (though I don't mind that), but certainly the timestamp parsing needs
> > polishing. From what I remember when looking at SRT content, it's not uncommon
> > to have various mistakes in the timestamp. Usually you don't notice the error
> > (until you validate the file or check a browser's error console). The parsing
> > of timestamps should be DWIM (doesn't need to be compatible with SRT
> > implementations though).
> > 
> > 1:01.000 = 01:01.000
> > 01:1.000 = 01:01.000
> > 01:01,000 = 01:01.000
> > 01:01.5 = 01:01.500
> > 01:01.5000 = 01:01.500
> 
> Maybe.
> 
> > 01:61.000 = 02:01.000
> 
> It would be bad if we accepted this kind of mistake IMHO. Think e.g. about
> 01:5432153.000 - that's neither readable nor makes it much sense at all as a
> time format.

This example actually came my OVC demo, where
<http://people.opera.com/philipj/2011/09/ovc/demos/the_conceited_general.vtt>
has this cue:

02:59.000 --> 02:61.000
<v General><c.sound>grunt

This was a mistake, but I didn't notice because I didn't watch the entire video
after the final editing.

Whether or not we allow >2 digits is another matter, but 01:5432153.000 doesn't
really seem more problematic than the hours, which are not limited.

> I'm in two minds about this.
> 
> On the one hand, allowing simpler time formats (such as just
> seconds.milliseconds) would be a nice simplification to allow and makes it
> easier to convert from other formats that use such a formats.

I'm not really opposed to making minutes optional, but that isn't what is being
suggested here.

> On the other hand, every simplification that we introduce into authoring makes
> the parsing much harder. With the fixed format that is currently given,
> implementing a parser is really trivial. Allowing for all the exceptions and
> authoring errors will give us all sorts of edge cases. For example, in SRT
> 01:01.5 is actually interpreted by some players as 01:01.005 and by others as
> 01:01.500 . We'd have to introduce rules on what these things actually mean and
> then implement more complex parsers.

Sure, but as implementors we are quite willing to deal with this if it makes
the format more usable.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 28 September 2011 08:39:54 UTC