Conversion as parsing and serialisation

SBV to VTT is not a direct translation. The tool parses the SBV file into an intermediate list of cues — each cue is just a start time in milliseconds, an end time in milliseconds, and the text — and then serialises that list as VTT. This two-step design means every format conversion here uses the same parse step and differs only in the final serialisation. Three formats need six converters, but only three parsers and three serialisers, so a fix to the SBV parser improves every SBV conversion at once.

What the intermediate form preserves and loses

The intermediate cue holds start time, end time, multi-line text, and one optional extra: a cue number. That number is populated only by the SRT parser and read only by the SRT serialiser, because SRT is the only one of the three formats that carries numbering. Everything else a format might express — WebVTT's cue identifiers, its positioning settings such as align and line, its STYLE and REGION blocks — has nowhere to live in this structure and is dropped at the parse boundary.

That is a property of the design rather than a bug in any one converter, and it cuts both ways: chaining conversions never loses more than a single conversion would, because everything droppable is already gone after the first parse. A round trip cannot restore what the intermediate form never held.

Timestamps never drift

When SBV is parsed, timestamps are immediately converted to integer milliseconds. When serialised as VTT, those exact integers are formatted as HH:MM:SS.mmm. Because there is no floating-point arithmetic and no re-parsing of formatted text, converting SBV to VTT, then VTT to SRT, then back again returns the same millisecond values you started with. No rounding error accumulates however many times you convert.

Note one asymmetry worth knowing: SBV has no cue numbers, so nothing numbers the cues on the way in — but the SRT serialiser numbers them sequentially from 1 when no number is present. So an SBV file converted to SRT arrives with clean numbering that the original never had.

Malformed blocks are skipped, not fatal

If a single cue in an SBV file is malformed — a timestamp that does not match the expected pattern, or a missing separator — that block is skipped and named in a warning, and the rest of the file converts normally. Only a file with zero usable cues is a hard error. One bad block among 400 cues will not cost you the other 399. This matters because caption exports routinely pick up stray characters or encoding quirks, and one defect should not force you to hand-clean the whole file before you can convert it.

VTT is the format browsers read natively, which is why it is usually the destination. If the target is a player expecting the older standard instead, SBV to SRT is the other route.