Convert SUB/IDX (VobSub) to SRT
The first run downloads the text reader — about 4 MB plus the language model, served by this site and cached by the browser afterwards. Nothing is uploaded, and the result is machine-read: proofread it before you rely on it.
Options
A bitmap subtitle is a picture of text, so the words have to be read back out of it. Tell the reader which language it is looking at — the list covers every language this site is published in. Pick the one the subtitles are actually written in: Russian subtitles read with the English model come out as noise, not as Russian. Only the model you pick is downloaded (the others never are), so switching costs one download per language, cached afterwards.
VobSub splits one subtitle track across two files, and both are needed. The .sub file holds the pictures: a chain of MPEG program-stream packets, each carrying a bitmap compressed with a two-bit run-length code. The .idx file holds everything else: the sixteen-colour palette, the frame size, and one line per subtitle with its start time and the byte offset inside the .sub where its picture begins. Drop only the .sub and there is no way to know how many subtitles there are; drop only the .idx and there is no picture to read. This page takes the pair and writes an .srt.
Each packet is located by that byte offset, so the index is not a convenience — it is the map. Inside the packet, two header words give the size and the position of a control sequence; the sequence sets the display area, chooses which four entries of the palette the pixels refer to, and points at the compressed bitmap. The decoder then walks the run-length code twice, once for the even rows and once for the odd ones, because VobSub stores the two fields of an interlaced frame separately. That detail is why a naive decoder produces a picture with every other line missing.
The timestamps come from the .idx, which is the only place they exist in a usable form. A cue ends where the next one begins; the final cue is given two seconds, and the loss list records that. Subtitles whose pictures produce no readable text are left out and counted, not written as blank lines.
The text itself comes from OCR, which means it is a reading rather than a transcription. This is where DVD subtitles are hardest: they were authored in small bitmap fonts with italic tags for off-screen voices, and a recogniser does not know that a differently slanted word is the same word. Proofread the file. Pick the language the subtitles are in — the model is chosen per page, downloaded once, and cached by the browser.
Nothing is uploaded. The pair is parsed and recognised in this tab; the only network requests are for the recogniser's own files, which this site serves.
Frequently asked questions
Why does this page need two files when every other tool here needs one?
Because VobSub stores one track in two files by design, not because the tool wants two inputs. The .sub holds the bitmaps; the .idx holds the sixteen-colour palette, the frame size and the offset of every picture together with its start time. Neither file alone can answer 'how many subtitles are there and what do they say'. If you have a .sub with no .idx, that pair was split somewhere and the index has to be recovered from the source disc before OCR is possible.
What do the filepos numbers in the .idx file point at?
A byte offset into the .sub file, at the start of an MPEG program-stream packet whose stream id marks it as a private stream — the kind DVD players use for subtitles. The offset is not a subtitle number, and it is not necessarily monotonic with the timestamps in an unusual disc, which is why this page sorts entries by their timestamps rather than trusting the order lines appear in the file.
Why would some lines come out with the wrong letters but the right length?
Because the palette and the shapes both come from the picture, and OCR resolves shapes at a fixed size. DVD subtitles are commonly authored in a small, very slanted or very bold face; a word in italics — used for off-screen dialogue and for song lyrics — is the usual casualty, because a slanted version of a letter is not a different letter to a human but is a different shape to a recogniser. If the lengths match and the letters do not, the fix is proofreading, not a different tool.
Does the subtitle's on-screen position survive into the SRT?
It does not, and there is nowhere for it to go. VobSub stores position as a display area rectangle in twelve-bit coordinates inside each packet, and SRT has no positioning syntax at all. The page uses the rectangle to know where the ink is — which helps OCR crop properly — and then drops it. If your player needs positioned subtitles, ASS is the format that can carry the information; an SRT with position markers is a convention some players honour and others print literally.
The tool says it needs the .idx — I only have a .sub. Can the index be rebuilt?
Not from the .sub alone, and not reliably from the pictures. The offsets can in principle be found by scanning for private-stream packets, but the timestamps cannot be recovered: they live in the .idx and nowhere else in the pair. Rebuilding an index means going back to the disc or the VOB file the pair was extracted from, or using the original .idx if it still exists next to another track. Guessing times would produce a file that looks correct and drifts against the video, which is worse than no file.
Is the pair of files sent anywhere while it is being read?
No. Both files are read into memory in this tab, decoded here, and recognised here. The only download is the text recogniser, served from this site and cached by the browser afterwards. You can watch the Network panel while a pair is processed: no request carries either file. This matters for VobSub in particular, because these files usually come from a disc a user owns and are exactly the kind of material that should not be handed to a conversion service.