Open z38 opened 9 years ago
I wouldn't mind implementing a way of allow improperly formatted files.
The initial reason I made this lib was to easily manipulate subtitles, so it would seem logic to handle those files too.
May be better to implement this feature thru adding configurable modes to your code? Clients can use strict mode if they need to strictly validate files and some king of soft
mode, which allow to parse file with mistakes.
Other elements I encountered that the parser failed on:
I have to bump to this issue too. I would like to have option (maybe set as default) to accept "improper formatted" SRT files. Now the library is not really usable, if this can not handle, subtitle files comes from many sources, one have no control on that. The most improper formatting is as follows (others are fixed quite easily, but needed fixing too):
Please if possible, fix this. Thank you.
Okay guys, I got it, I'll see what I can do.
There's already a PR to handle overlapping cues.
I needed this for the purpose of converting srt to webvtt and did some work which fit the needs of a specific project I'm working on (I'm not sure if it's pull-request-worthy), see here: https://github.com/thomaspeeters/captioning/commit/13202f46f474eefc99f91ee02f5f1ab6946cb32b
Things I allow in my "loose validation mode":
Things I encountered, but didn't allow in my implementation:
@thomaspeeters I think it is very good start. What about to pull request?
I made a pull request. It's the first time I've done this, so I hope I did it right...
At the moment the library does support parsing strictly valid Subrip files. To build tools to realign cues, one might need to be able to handle improperly formatted files.
The following faults come to my mind:
00:28:41,1000
Are these goals in alignment with yours (therefore accepting PRs) or would you rather keep it a strict parser?