Subtitles Beyond SRT: ASS, SAMI, iTT and What Styling Survives
Four families of timed text, how each one stores a caption's position, colour and frame rate, and exactly which of those things is thrown away the moment you convert to SubRip.
SubRip is the lowest common denominator of timed text, which is exactly why everything reads it. The formats above it each solved a problem SRT ignores: where the caption sits, what it looks like, which language it belongs to, which frame of the edit it starts on. Converting down to SRT is routine and legitimate. It is also a deliberate discard, and it is worth knowing what goes in the bin.
A cue is three things#
Every conversion here passes through the same internal shape: a start time, an end time, and some text. That is the only thing the timed-text formats genuinely share, and anything a source format records beyond those three values has nowhere to go on the other side. So the question 'will my styling survive?' has a short answer, and the answer is no.
ASS and SSA: the one that can actually typeset#
SubStation Alpha arrived in 1995 and its Advanced revision followed around 2002. The script is INI-shaped: a [Script Info] header, a [V4+ Styles] table naming fonts, colours, outlines and margins, and an [Events] section of Dialogue lines. Timing is written H:MM:SS.cc, one hour digit, centiseconds rather than milliseconds. Line breaks inside a cue are never literal newlines; they are written \N for a hard break and \n for a soft one.
The expressive power lives in the override tags, written in braces inside the cue text. {\i1} turns on italics, {\pos(640,80)} nails a caption to a coordinate, {\fad(200,200)} fades it in and out, and karaoke timing gives every syllable its own effect. This is how fansub typesetting matched a sign on a wall in the picture.
When you convert ASS to SRT, the override tags are stripped, the \N breaks become real line breaks, and the style table is never read. The ASS format page sets out the section layout.
SAMI: captions with an HTML shape#
Microsoft built SAMI in the late 1990s for Windows Media Player, aimed at accessibility requirements for public-sector media. The document looks like HTML: a <SAMI> root, a <HEAD> with a CSS block, and a <BODY> of <SYNC Start=...> elements whose millisecond attribute gives a caption's in-point. There is no end attribute: a caption runs until the next SYNC, and the convention for clearing the screen is a SYNC whose paragraph contains only a non-breaking space.
Two consequences follow, and both show up in converted files. The last caption has no following SYNC to end it, so a conversion has to invent a duration for it. And because language tracks are CSS classes on the paragraphs rather than separate documents, a file holding three languages holds them interleaved on one timeline: flattening it gives you all three in time order, which is almost never what you wanted.
So converting SAMI to WebVTT is the right move for a single-language archive and a trap for a multi-language one. Split the languages before converting, not after. SAMI's HTML laxity also invites embedded markup, which is why the parser here strips script and style content before any text is read.
iTT: frame numbers wearing a timecode#
iTunes Timed Text is a narrow TTML profile Apple defined for store delivery, and Final Cut Pro exports it natively. Its defining trait is timing: cues are addressed in SMPTE timecode, HH:MM:SS:FF, where the final field is a frame number rather than a fraction of a second. A frame number means nothing on its own: it is resolved against ttp:frameRate in the document header, optionally scaled by ttp:frameRateMultiplier for the NTSC-derived rates such as 23.976.
That header is load-bearing in a way SRT's timestamps never are. Set the wrong rate and every cue shifts progressively, so the file looks fine at the top and is seconds out by the end. Converting iTT to SRT resolves the timecodes against the document's own declared rate and multiplier, falling back to 30 fps only when the file declares neither.
Precision belongs to the target#
- SubRip and WebVTT record whole milliseconds, finer than any source here needs.
- ASS and SSA write centiseconds, so a millisecond-accurate cue lands on a 10 ms grid on the way in.
- iTT is a frame grid by definition. Written at 25 fps, every timestamp quantises to 40 ms.
- LRC has no end times at all: a lyric line runs until the next one, so converting to it discards every out-point permanently.
None of that matters for dialogue and all of it matters for karaoke. Convert once, from the most expressive file you hold, and keep it. If the job is simply getting captions into a browser, SRT to WebVTT is the whole task and our guide to the SRT and VTT family covers it.
Troubleshooting
Expected. Styling, positioning and karaoke live in the ASS style table and override tags, and SubRip and WebVTT have nowhere to record them. Keep the original script as the master.
Progressive drift is a frame-rate mismatch, not a timing bug. Check ttp:frameRate and ttp:frameRateMultiplier in the document header against the frame rate of the video the subtitles were timed to.
SAMI stores language tracks as CSS classes on one timeline, so flattening the document interleaves them. Separate the languages into individual files before converting.
SAMI states no end times: a caption runs until the next SYNC, and the final one has no successor. A conversion has to supply a duration for it, so adjust that single cue afterwards.
Dialogue fields are separated by positional commas and the cue text may contain commas of its own. A hand-edited line with a missing field breaks the layout; compare the offending line against the Format line in the [Events] section.
Frequently asked questions
Can I keep ASS styling when converting to SRT?
No. SubRip records a start time, an end time and text. Positioning, colour, fonts, fades and karaoke timing have no representation in the format, so they are stripped rather than approximated. Keep the .ass file as the master.
Why did my iTT subtitles end up out of sync?
iTT timing is frame-based, so the file means nothing without the frame rate declared in its header. If that rate does not match the video, every cue shifts by a growing amount. Drift that increases through the file is always a frame-rate problem.
What happens to a multi-language SAMI file?
SAMI keeps its languages as CSS classes on a single timeline, so a conversion to a one-track format interleaves them in time order. Split the file by language first if you need separate caption tracks.
Is WebVTT a better target than SubRip?
For a browser, yes: WebVTT is what the HTML track element reads natively, and it supports cue settings SubRip cannot express. For a desktop player or an editing tool, SubRip is still the most universally accepted.
Does the subtitle text go to a server?
No. Parsing and rewriting happen in your browser. That is worth caring about with captions specifically, because a caption file is a full, timestamped transcript of everything said.
