Convert VTT to SBV

WebVTT is a document format with room in it: an obligatory header, optional cue identifiers, comment blocks, a style block, settings appended to any timing line, and inline tags inside the text. All of that exists for good reasons and all of it is in the way when what you want is a list of moments and what was said at each of them.

SBV has none of it. A timing line, some text, a blank line, and the next entry. That is the entire format, which is why it survives as a working file long after the tool it was built for changed shape, and why it is the sensible target when the next step is a human reading every line or a script splitting on a comma.

The header goes, because SBV has none. Cue identifiers go, because SBV has no numbering or naming of any kind. NOTE and STYLE blocks go, and they go for a structural reason worth knowing: a block is recognised as a cue by containing a timestamp arrow, and neither of those does, so they are skipped rather than misread as caption text.

Cue settings go too. A line, align, position or size setting written after the end timestamp is read up to the first space and the remainder discarded. If the track relied on positioning to keep captions clear of on-screen text, that placement is not recoverable from the output, and the WebVTT file is the only copy of it.

One line carries both times separated by a comma: 0:04:12.500,0:04:15.100. The full stop before the milliseconds is the same as WebVTT uses, so that half needs no thought. The hours are what change — SBV writes them without zero padding, which is the detail that makes a renamed file fail and a converted one work.

The timings themselves are untouched. Every value is held in milliseconds through the conversion and written back at millisecond resolution, so each entry starts and ends at precisely the moment it did in the VTT. Nothing is rounded, snapped or shifted; only the punctuation around the numbers is different.

This is the limit of the flattening and it is worth stating clearly. Cue text is copied verbatim. An italic tag, a bold tag, a voice tag naming the speaker — all of them travel from the WebVTT into the SBV as literal characters, because nothing interprets the inside of a cue.

SBV has no styling whatsoever, so those tags will be shown rather than applied. If the point of converting was a file with nothing in it but words, one search and replace finishes the job. Doing it in the WebVTT first is better practice, because that file is the one somebody will convert again next month.

Most WebVTT files in circulation came out of automatic transcription, and the structure of SBV suits the correction pass well: the timing lines are short enough to read past, the text is on its own lines, and there is no numbering to renumber when a caption is split or merged.

What to fix, in the order that pays: proper nouns and technical vocabulary, which is where recognisers fail most and where the failures change the meaning; then line breaks, which machine output places where its buffer flushed rather than at a clause boundary; then cue length, because a recogniser has no sense of how long a viewer needs. None of that is a format problem and all of it is why an automatic transcript is good enough to skim and not to publish.

A trick that saves a full pass: collect the names before you start. Speakers, companies, products, places, any acronym the recording leans on — write them down from the description or the slides, then search the caption file for each one. Recognisers fail consistently rather than randomly, so a name that came out wrong once came out wrong every time, and a search and replace fixes thirty instances in one action. Reading the file top to bottom hunting for them is the same work spread over an hour.

SBV is Google’s own format, produced by the YouTube caption editor since 2008 and offered by its download tool. Uploading one puts the captions back where they can be edited against the video timeline, which is the fastest way to fix timing rather than wording.

It is worth being straight about the necessity: YouTube accepts WebVTT directly, so this conversion is not a prerequisite for captioning a video there. It earns its place when the editor is where the work is happening, when a script in your workflow expects the export format, or when a caption archive is already in SBV and a new file arriving as WebVTT is the odd one out.

A large share of the demand for caption files has nothing to do with subtitles. People want the text: to turn a talk into an article, to quote a speaker accurately, to search a two-hour recording for the four minutes that matter. For that, timings are noise and SBV is a stop on the way rather than the destination.

The flattened file makes that last step trivial — delete every line containing a comma between two timestamps and the transcript is what remains. Do it in an editor with a regular expression, or in three lines of any scripting language. What no conversion fixes is the reliability of the underlying words, and a transcript sourced from a recogniser needs checking against the audio before anything is quoted from it.

If the next step is code rather than a person, the shape of the file decides how much code. A WebVTT parser has to handle an optional header with optional metadata after it, blocks that may or may not begin with an identifier, timing lines that may or may not carry settings, and blocks that are comments or styles rather than cues.

An SBV parser splits on blank lines, splits the first line on a comma, and takes the rest as text. That difference is real, and it is the honest reason somebody would convert in this direction for a scripting task. It is also worth weighing against using a maintained WebVTT parser instead, which handles the awkward cases correctly and costs one dependency rather than an afternoon of edge cases.

Correcting a caption file usually means changing where the boundaries are, not only what the words say: a cue that runs across a sentence break wants splitting, and two fragments the recogniser separated want joining. In SubRip every one of those edits invalidates the numbering from that point on, and a file corrected in a text editor ends up with two entries numbered 214 or a run that jumps from 300 to 302.

SBV has no numbering to break. Splitting an entry means adding a timing line and a blank line; merging two means deleting them. Nothing after the edit needs touching, and no player or platform is counting. That is a genuine advantage of the format for the one job it is good at, and it is why a correction pass done here and converted back is often less error-prone than the same pass done in the SubRip file directly.

As an archive, no. It reads essentially nowhere outside YouTube, it carries nothing WebVTT or SubRip does not, and it records no information about where the captions came from or what they were positioned to avoid. A directory of SBV files is a directory that has forgotten things.

As a working file for one task, it is excellent, which is the distinction worth drawing. Convert, correct, upload or parse, and keep the WebVTT as the file you come back to. If the corrections happened in the SBV rather than in the source, convert back rather than leaving the two copies to disagree — the words are the same in both formats, so nothing is lost by moving them in either direction.