Turn your SUB subtitle file into an LRC lyrics file quickly with a simple online converter.
MicroDVD .sub and LRC look similar at a glance — a timing marker, then some words — but they model time differently. A MicroDVD cue has a start and an end, expressed as frame numbers. An LRC line has only a start: the lyric appears and stays until the next one replaces it. Converting from one to the other therefore discards half the timing information by design, and whether that matters depends entirely on what you are building. If you want a scrolling lyric file for a music player, LRC is exactly right. If you want captions on a video, it is the wrong target and a subtitle format is the answer.
| Property | MicroDVD (.sub) | LRC |
|---|---|---|
| Purpose | Subtitles for video | Synchronised lyrics for audio players |
| Origin | Tiamat Software's MicroDVD Player, March 2000 | Kuo (Djohan) Shiang-shiang's Lyrics Displayer, 1998; never formally standardised |
| Timing marker | {start_frame}{end_frame} |
[mm:ss.xx] at the start of the line |
| Timing model | Frame numbers against a specific video encode | Elapsed time from the start of the audio |
| End times | Yes — every cue has one | No — a line runs until the next timestamp |
| Precision | One frame; 40 ms at 25 fps | Centiseconds, truncated rather than rounded |
| Hours | Not applicable (frames count up) | No hours field — minutes keep counting past 59 |
| Line breaks in one cue | Pipe character ` | ` |
| Styling | Inline {y:i}, {c:$BBGGRR}, {f:}, {s:} codes |
None in the base format |
| Metadata | None | Optional [ti:], [ar:], [al:], [by:], [offset:] tags |
| Repeated lines | Each occurrence is its own cue | One line may carry several timestamps |
| Platform note | Accepted by YouTube as a SubViewer alternate | Accepted by YouTube as a basic caption format |
[ti:], [ar:] and [al:] metadata afterwards, which most lyric players display.<track> element expects..sub, replace MicroDVD's | separator with a space or a slash. LRC allows only one line per timestamp, so a piped cue converts into an untimed orphan line.{start}{end}text lines into the Input (SUB) box; the character count beside the label confirms it was read..sub reads {1}{1}23.976. This parser reads every MicroDVD file at 25 fps and offers no frame-rate control, so anything else means the timestamps need checking — and delete that line before converting either way.subtitles.lrc, or "📋 Copy" to paste it into a tag editor. Play the result against the audio and check the first and last line before you keep it.{25}{100}Hello means frames 25 to 100, and only the frame rate of the source says how long that is. MicroDVD has no field for the rate; by convention it is written as a first cue, {1}{1}23.976. FFmpeg's MicroDVD demuxer scans the opening lines for that shape, and the reference Python library pysubs2 raises UnknownFPSError rather than assume a value when it is absent — a fair measure of how underdetermined the format is on its own.
This converter neither reads that line nor exposes a frame-rate control, so every MicroDVD file is parsed at 25 fps. Delete the hint line from the input, or it becomes a lyric reading 23.976, and treat the [mm:ss.xx] values in the output as provisional until you have played the file against the audio. A lyric file makes that check quick — a scrolling display is unforgiving about timing, so a wrong rate is obvious within a verse or two.
Frame number divided by frame rate gives the time in seconds, which is enough to sanity-check a converted file by hand:
| Frame number | at 23.976 fps | at 24 fps | at 25 fps | at 29.97 fps | at 30 fps |
|---|---|---|---|---|---|
| 24 | 0:00:01.001 | 0:00:01.000 | 0:00:00.960 | 0:00:00.801 | 0:00:00.800 |
| 1,500 | 0:01:02.563 | 0:01:02.500 | 0:01:00.000 | 0:00:50.050 | 0:00:50.000 |
| 90,000 | 1:02:33.754 | 1:02:30.000 | 1:00:00.000 | 0:50:03.003 | 0:50:00.000 |
The error from a wrong rate is proportional rather than fixed, so it grows across the track. Over a four-minute song a 23.976 fps source read at 25 fps ends about ten seconds early — enough to put the last chorus on the wrong line — and LRC's [offset:] tag will not repair it, because that tag shifts everything by a constant.
Two input quirks are worth checking before you convert. A UTF-8 byte-order mark at the head of the file makes line one unmatchable, since the cue pattern is anchored to an opening {, so the first lyric silently disappears — Windows-authored .sub files often carry one. And a cue with an empty end frame, {1234}{}, is skipped entirely, because this parser requires digits in both braces.
They are discarded. LRC is a "display this from here" format: each [mm:ss.xx] line replaces the previous one, and the last line in the file stays on screen until the audio stops. For a song that is the correct behaviour and the reason the format is so compact. For subtitles with pauses it is a real loss, and the usual symptom is a line that lingers through a long instrumental or a silence.
Because that cue used MicroDVD's pipe separator. A cue written {25000}{100000}Never gonna|give you up becomes two physical lines, and only the first carries [00:01.00] — the second is a bare line of text that a strict LRC player will ignore or mis-display. Replace | with a space in the .sub before converting and the whole cue lands on one timestamped line.
Centiseconds — two digits after the point, as in [00:01.04]. The value is truncated rather than rounded, so 999 ms becomes [00:00.99] rather than [00:01.00]. That is a hundredth of a second at worst, comfortably below what anyone perceives in a scrolling lyric, and it matches what the format's convention expects players to read.
The minutes field keeps counting. LRC has no hours component, so a line at one hour, one minute and forty seconds is written [61:40.00] rather than [01:01:40.00]. Players generally handle that, since the format was designed for songs; it is another sign that LRC is a poor fit for a feature-length subtitle track.
[ti:] and [ar:] metadata tags?No — the converter writes timestamped lines only. LRC's ID tags carry title, artist, album, author, the file's own author and a global offset in milliseconds, and a MicroDVD file has nowhere to store any of them, so nothing would be truthful to write. Add them by hand at the top of the downloaded file, or let a tag editor write them, before loading the lyrics into a player. The [offset:] tag is worth knowing about separately: it shifts every timestamp at once, which is the quickest way to nudge a whole file that lands consistently early or late.
They do not, and LRC has nowhere to put them. MicroDVD's {y:i}, {c:$0000ff}, {f:Arial} and {s:12} codes are stripped during parsing and the base LRC format has no styling model at all. Extended LRC variants add per-word timing rather than styling, and this converter does not emit those either.
We ran a three-cue MicroDVD file through this exact pipeline. The output was three plain [mm:ss.xx] lines followed by their text, with no metadata header, no end markers and no styling — exactly the shape described above. A separate run using an unflattened piped cue produced the orphan second line, which is what the flattening step in the how-to prevents. Text and ordering were exact; the timestamps are the part to check against the audio.
No. The file is read locally with the browser's FileReader API, converted by JavaScript that was delivered with the page, and handed back as a Blob download — no request carries your text off the machine and there is no server-side copy to expire. If LRC turns out to be the wrong target, the SUB converter hub lists the subtitle formats that keep end times.