Convert VTT to SUB

The situation is specific and more common than it sounds. A talk, a lecture or a stream has been saved for offline viewing, the captions came down as WebVTT because that is what the player used, and the machine it will be watched on is a disc player, a media box or a television that reads files off a USB stick and was built before any of this existed.

What makes this conversion different from converting a subtitle file for a video you already have is that you are producing the video too. The transcode is yours, which means the frame rate is a setting rather than a fact, and that changes the advice on this page from a warning into an instruction.

WebVTT is a W3C specification from 2010, written for the video element that had just arrived in browsers. MicroDVD dates from 1998, is documented rather than standardised, and the registry classes it as legacy with patchy support. Nothing writes it now; subtitle editors read it in order to save something else.

The gap shows in what each format assumes. WebVTT assumes a rendering engine that can position text, style it, distinguish speakers and switch between caption kinds. MicroDVD assumes a player that draws a line of text at the bottom of a frame and nothing more. The conversion is not translating between two dialects; it is dropping down a level.

MicroDVD records which frame a line appears on, so writing one requires a frame rate. This page offers no way to set it. The control exists on the site, but only where MicroDVD is the source, because reading such a file is impossible without one; writing it uses the fallback, which is 25.

For anyone transcoding a video anyway, that is the least interesting constraint on the page: set the encoder to 25 frames per second and the subtitle file is frame-accurate from the first line to the last. Web video is commonly 30 or 60 and occasionally 24, so this is a real change rather than a coincidence — but it is one setting, and the alternative is a caption track that is minutes out by the end.

Converting 30 frames per second down to 25 is not free, and it is worth knowing what you are trading. The encoder has to drop or blend frames, and steady camera pans are where that shows as a faint stutter. For a talk, a lecture or an interview — which is most of what gets archived this way — the picture is nearly static and the difference is invisible. For anything with real motion in it, weigh the stutter against a subtitle file that a device with no frame-rate setting cannot be told how to read.

Each start and end time is multiplied by the frame rate and rounded to the nearest whole frame. At 25 frames per second a frame is 40 milliseconds, so every boundary in the file snaps to a 40 millisecond grid. A cue starting at 12.510 seconds and one starting at 12.530 land on the same frame.

For dialogue this is invisible; nobody perceives twenty milliseconds. It matters for caption tracks that were cut finely — some automatic transcription output emits very short cues, a few words at a time, and a track built that way can end up with adjacent entries sharing a frame boundary. A player will show them in sequence regardless, but if two lines appear to flash at once, this is the cause.

A WebVTT cue can carry a line number, an alignment, a position and a width, which is how a caption is kept clear of a lower third or of burned-in text. MicroDVD has no positioning at all. Lines appear where the player puts them, which is the bottom, and there is no field in the format that could say otherwise.

Cue settings are therefore read off the end of the timing line and discarded. There is nothing to warn about at conversion time because the loss is complete rather than partial — no approximation is possible, and any placement in the source has to be accepted as gone. Where a caption was moved for a reason, check that the reason does not make the subtitle unreadable at the bottom of the frame.

NOTE comments and STYLE blocks contain no timestamp arrow, so they are skipped rather than turned into captions — nothing from the authoring layer of the WebVTT file leaks into the SUB. That part is clean.

Voice tags are the part that is not. A speaker marked with an angle-bracket tag at the front of a cue is copied into the MicroDVD entry verbatim, because cue text is never reinterpreted, and an old player will draw the brackets on screen. Transcription exports use them heavily. A search and replace over the VTT before converting is thirty seconds and saves reading every caption twice.

A MicroDVD entry occupies one physical line, so a forced break inside a caption is encoded as a vertical bar and split again by the player. Multi-line captions from the VTT come across correctly without anything needing to be escaped.

The consequence is that a pipe already present in your caption text becomes a line break on playback, and the format offers no way to escape one. Web caption tracks pick these up from transcribed technical talks and from anything quoting a command line. Searching the VTT for the character before converting is the only defence, and it is quicker than wondering why one caption is split oddly.

The SUB file is written as UTF-8, which is the right modern default and what the WebVTT source was guaranteed to be. Any player made in the last fifteen years handles it, and accented characters, non-Latin scripts and typographic punctuation all survive intact.

Hardware from the MicroDVD era frequently does not. Those players were built when subtitle files were single-byte and regional, and handed UTF-8 they render accented characters as boxes or pairs of stray symbols. If that happens, the file is not damaged and the conversion did not fail — re-saving it from a text editor in the encoding the device expects is the fix, and it is the one step of this process that cannot be done here.

Because you are running the encode yourself, you have a route the other MicroDVD pages cannot suggest — not a control here, but a setting in your encoder. Subtitles can be rendered into the picture during that pass, at no extra pass and no extra loss beyond the one the transcode already costs. The device then needs no subtitle support at all, which sidesteps every problem on this page at once: no frame rate, no encoding, no filename convention, no format.

The price is that they become permanent. Burned-in captions cannot be switched off, cannot be replaced with another language, and cannot be read by anything except a person looking at the screen. For a copy made for one player in one room that is usually acceptable. For anything that is also an archive of the material, keep a soft copy as well — the subtitle file costs a few kilobytes and it is the only version anybody can correct later.

Play the transcoded video and the new subtitle file together on your own machine first, in a player that lets you see both. Check the first caption and one near the end. Both correct means the frame rate matched. Both wrong by the same amount means an offset, usually because the download included something the captions were not timed against.

A growing error means the rate is wrong, and at that point re-encoding at 25 is faster than any other remedy. Doing this before the file goes onto a USB stick matters because the device at the other end will tell you nothing: it either shows subtitles or it does not, and it will not say which of the two problems it is having.