Convert STL subtitle files to SUB format quickly—upload your STL, run the conversion, and download the resulting SUB file.
MicroDVD .sub is one of the oldest surviving subtitle formats: a plain text file where each line is {start-frame}{stop-frame}Text. It indexes subtitles by video frame number rather than by clock time, which makes it fast for a player to seek but tightly coupled to the frame rate of the video it was cut against. Converting Spruce STL to MicroDVD moves cue text from one frame-counted format into another — which sounds trivial and is where the trouble starts.
The conversion runs in your browser: the file is read locally, parsed by page JavaScript, and returned as a download.
Read this before you download anything. The .sub frame indices this page currently writes are scaled by a factor of 1000, because the emitter multiplies the cue's millisecond value by the frame rate instead of its value in seconds. A cue that should start at frame 25 is written as frame 25000.
In our testing against this page's own emitter, a cue timed 00:00:01:00 , 00:00:04:00 , Hello came out as {25000}{100000}Hello. Frame 25000 at 25 fps is 16 minutes 40 seconds into the video, not one second. Every cue is affected, and the same is true whichever frame rate you assume — the ratio is constant.
| Cue at 1.000 s → 4.000 s | Correct MicroDVD line | What this page writes today |
|---|---|---|
| at 25 fps | {25}{100} |
{25000}{100000} |
| at 23.976 fps | {24}{96} |
{25000}{100000} |
| at 30 fps | {30}{120} |
{25000}{100000} |
Two workarounds. If you only need the subtitles to play, convert to a time-based format instead — STL to SRT and STL to VTT both carry the timings correctly to the millisecond, and every player that reads MicroDVD also reads SRT. If you specifically need MicroDVD, take the output and divide both frame numbers on every line by 1000, then round; at 25 fps that recovers the correct index exactly, because one frame is 40 ms.
There is a second, smaller defect worth knowing: only the first line break in a multi-row cue becomes the | separator MicroDVD expects. A three-row cue emits a literal newline in the middle of the line, which breaks the one-cue-per-line rule and makes the trailing row parse as junk. Two-row cues are unaffected.
| Property | Value |
|---|---|
| Syntax | {start-frame}{stop-frame}Text, one cue per line |
| Timing basis | Frame numbers, not timecodes |
| Frame rate | Not carried by the format — playback depends on the frame rate of the video file |
| Frame-rate convention | Many players honour a leading {1}{1}23.976 declaration line; FFmpeg's MicroDVD demuxer scans the first lines for it. It is not part of the core syntax, and this converter neither writes nor reads one |
| Line breaks | | inside the text |
| Styling codes | {y:...} style, {f:Arial} font, {s:12} size, {c:$BBGGRR} colour in BGR order, {P:...} position |
| Code scope | An uppercase code affects the whole subtitle; a lowercase code affects only that line |
| Encoding | Plain text; no encoding is declared in the file |
| Extension clash | .sub is also used by VobSub, an unrelated binary bitmap format paired with an .idx file |
This converter parses the Spruce / DVD Studio Pro text flavour of .stl: cue lines of the form 00:00:04:12 , 00:00:07:19 , First row|Second row, with | marking a row break. Header directives such as $TapeOffset = FALSE and // comment lines are skipped harmlessly.
It does not parse binary EBU Tech 3264 STL, the broadcast interchange format the EBU published on 27 February 1991. That file is binary — a 1024-byte General Subtitle Information block followed by 128-byte Text and Timing Information blocks — so it matches no text cue pattern and produces zero cues here, with the message "No cues parsed from input. Check the format." If a text editor shows a short readable programme title followed by mojibake, that is the flavour you have.
A time-based format like SRT or WebVTT states when a cue appears in hours, minutes and seconds, so it plays correctly against any copy of the video. MicroDVD states which frame a cue appears on, which is only meaningful if the player knows the frame rate — and the format has nowhere to record it. A file cut against 25 fps PAL material and then played against a 23.976 fps transfer of the same programme drifts by roughly 4.3%, about 2.6 seconds per minute, and the drift accumulates: by the end of a feature the subtitles are minutes out.
This is also why the frame field in your source STL matters. Spruce STL timecodes end in a frame count, and this page converts that count at a fixed 25 fps with no control to change it. On 30 fps or 29.97 fps material the sub-second part of every timecode is wrong, and frame fields of 25 and above are converted incorrectly enough that a cue at 00:00:01:29 can land earlier than one at 00:00:01:12. EBU Tech 3264 explicitly allows both rates, signalled by a Disk Format Code of STL25.01 or STL30.01, so 30 fps material is common and worth checking for.
Because of the scaling defect described above: the emitter multiplies the cue's millisecond value by the frame rate rather than its value in seconds, so every index comes out 1000 times too big. A cue at one second is written as frame 25000 instead of frame 25. Divide both numbers on each line by 1000 and round, or convert to SRT or VTT instead.
No, and this is a common mix-up. VobSub uses the same .sub extension for a binary file containing bitmap subtitle images, always paired with a text .idx index. MicroDVD .sub is plain text you can read in any editor. If your file is unreadable and has a sibling .idx, it is VobSub and nothing on this page applies to it.
Whatever frame rate the video actually runs at, because MicroDVD stores no frame rate of its own. Most players expose a subtitle frame-rate setting for exactly this reason. If you do not know the rate, a time-based format sidesteps the question entirely — that is the strongest practical argument for choosing SRT or VTT over MicroDVD.
No. It reads only the Spruce / DVD Studio Pro text flavour, whose cue lines look like hh:mm:ss:ff , hh:mm:ss:ff , text. A genuine Tech 3264 file is binary, built from a 1024-byte GSI block and 128-byte TTI blocks, and returns zero cues with the message "No cues parsed from input. Check the format."
No. MicroDVD does define styling codes such as {y:i} for italic and {c:$BBGGRR} for colour, but none are emitted here — the output is cue text and frame indices only. Spruce inline codes like ^I and ^B in the source are not interpreted either; they travel through as literal characters and will appear on screen unless you remove them.
It comes out malformed. Only the first row break becomes the | separator MicroDVD expects; any further breaks stay as real newlines, splitting one cue across several physical lines. Since MicroDVD requires one cue per line, the trailing rows will not parse. Reduce such cues to two rows before converting, or use a format with proper multi-line support.
No. This page is client-side: the browser's file reader loads the file, JavaScript in the page does the parsing, and the download is generated locally.
No. Many players honour a leading {1}{1}23.976 line as a frame-rate declaration, and FFmpeg's MicroDVD demuxer looks for one, but it is a convention rather than part of the format and this converter does not emit it. If your player needs the hint, add the line by hand at the top of the file.
SRT, in almost every case. It is time-based, so it survives a change of frame rate, and it is the format with the widest player and editor support. STL to SRT gives you that directly; choose STL to VTT instead if the destination is an HTML5 <video> element, since that is the format a <track> element loads.