Convert SBV to SRT

There is essentially one source. YouTube’s caption editor writes SBV, its download tool offers it beside SubRip and WebVTT, and nothing else in general use produces the format. If a file with this extension is on your machine, it came from a video on that platform, either downloaded deliberately or handed over by somebody who downloaded it.

The two situations that follow are equally common. Someone wants to correct captions offline and put them back, in which case the format is fine and this conversion is unnecessary. Or someone wants the captions somewhere else entirely — a local copy of the video, a second platform, an editor, a client — and that is where a format only one company reads becomes a problem.

Because it does not implement it. VLC and its peers read SubRip, WebVTT, Advanced SubStation Alpha and a handful of container-embedded formats; SBV is not on the list and there is no plugin culture around adding it. The player does not report an error, it simply finds no subtitle track and plays the video plain.

That is a support decision rather than a technical difficulty — the format is trivial to parse, which is rather the point of it. It exists to move caption text in and out of one web application, and it never acquired the wide implementation that would have made it worth a player author’s time. The registry classes it as niche, which is exactly right.

The timing line splits and grows. SBV puts both times on one line separated by a comma; SubRip puts them on one line separated by an arrow, with each time zero-padded to two digits of hours and a comma rather than a full stop before the milliseconds. So 0:04:12.500,0:04:15.100 becomes 00:04:12,500 --> 00:04:15,100.

The text does not change at all. Line breaks inside a caption survive as line breaks, the characters are copied through unmodified, and the blank line between entries is preserved because both formats separate their entries the same way. It is the shortest list of differences of any pair on this site.

SubRip puts a sequential number on its own line above each timing line, and a strict parser expects it. SBV has no numbering whatsoever, so the converter supplies one, counting from one in the order the entries appear.

Because SBV entries come out of YouTube in chronological order, the numbering matches the timeline and there is nothing to check. If the file has been hand-edited and an entry moved, the numbers follow the file rather than the clock — most players sort by time and do not mind, but a strict upload validator may. Reading the first and last entries after conversion is a five-second sanity check.

This is unusual enough on a conversion site to be worth stating without qualification. SBV has no styling, no positioning, no colours, no fonts, no speaker markers and no numbering. It carries a start, an end and some words. SubRip carries the same three things and a counter.

So there is no trade-off to weigh, no caveat to read and no output to inspect for damage. The austerity that makes SBV useless as an archive format is what makes converting out of it perfectly safe. Every other subtitle pair on this site involves at least a decision about precision or a note about what is dropped; this one does not.

A large share of SBV files are automatic transcripts rather than authored captions, and the conversion does not improve the words. Speech recognition is reliable on ordinary conversational language and unreliable on exactly the terms that carry the point: names, places, product names, acronyms and technical vocabulary.

Two mechanical faults are worth fixing at the same time. Machine output breaks lines where the recogniser flushed its buffer rather than at a clause boundary, which is why captions read awkwardly even when every word is right. And it produces cues of a length nobody chose. Both are easy to fix in an SRT, which is plain text with an obvious structure, and both are the difference between subtitles somebody reads and subtitles somebody switches off.

There is one class of error worth hunting deliberately rather than reading past. Speech recognition does not fail loudly — it substitutes a real word for a real word, so the caption is grammatical, plausible and wrong, and the eye slides over it. A misheard name, a negation dropped from a sentence, a figure that changed by an order of magnitude: none of those look like errors on the page. Checking the words that carry the meaning against the audio is the only pass that catches them, and it is the pass most often skipped.

Almost every platform that accepts subtitles accepts SubRip; several also accept WebVTT; approximately none accept SBV. That asymmetry is the practical reason this conversion exists, and checking the destination’s accepted formats before uploading is faster than discovering it from a rejection.

Where a platform asks for a language code in the filename or as a field, set it correctly rather than leaving a default. Subtitle tracks that arrive without a declared language get labelled by guesswork or by the uploader’s account language, which is how a Spanish track ends up listed as English on a video that then gets recommended to the wrong people.

The other thing worth doing before an upload rather than after is opening the SRT and reading the last few cues. A caption file downloaded from a platform covers the video as that platform had it, and a re-upload frequently is not the same cut — an intro card added, a sponsor segment removed, the tail trimmed. The end of the file is where that shows, and a subtitle track that runs past the end of the video is the one fault an upload form will accept without comment.

The captions were timed against the copy that was uploaded. If your local video is a different cut — a version with an intro card, a trimmed opening, a re-upload with a sponsor segment removed — the SRT will be uniformly out by the length of the difference.

That is an offset rather than a drift, and it is the easy case. Check the first caption and one near the end: wrong by the same amount at both ends means a constant shift, which any player and every subtitle editor can apply in one step. Wrong by a growing amount would mean a frame-rate problem, which cannot happen here because both formats state times rather than frames.

The numbering the conversion adds is the one thing in the output that can be got wrong later. SubRip expects a sequential counter, and every edit that changes how many entries there are — splitting a long caption, merging two fragments, deleting a stray line — invalidates every number after it. A file with two entries numbered 214 is a file some players and most upload validators will complain about.

Two habits avoid it. Do the structural edits in a subtitle editor rather than a text editor, because renumbering is automatic there and manual everywhere else. Or do them in the SBV, where there is no numbering to break, and convert again afterwards — the conversion is instant, nothing is lost in either direction, and the numbers come out correct by construction. The second route is often faster when the work is a long correction pass over a machine transcript.

Once converted, the SubRip file is the better master by every measure that matters. Subtitle editors handle it, players load it, platforms accept it, and it holds everything the SBV held. There is no information in the original that the copy lacks.

The sensible arrangement is to keep the SRT, edit it there, and convert back to SBV only if the YouTube caption editor is where a particular correction has to happen. That way the file you maintain is the one the whole world reads, and the platform-specific format is something you pass through rather than something you archive.