The same captions written out across SubRip, WebVTT, ASS/SSA, SBV, TTML and a synced LRC lyric file, with known timings, for exercising subtitle parsers, format converters and burn-in tools against every serialisation.
An Advanced SubStation Alpha (.ass) subtitle with a styles section and three timed Dialogue events (the styled format libass renders) carrying the same captions as the SRT/VTT twins.
A SubStation Alpha (.ssa) subtitle (the predecessor of ASS) with a V4 styles section and timed Dialogue events, carrying the same captions, for testing SSA parsers and SSA-to-ASS upgrades.
A YouTube SBV caption file (start,end timestamp lines followed by caption text) carrying the same three captions, for testing SBV parsers and YouTube caption import.
A TTML (Timed Text Markup Language / DFXP) caption document (timed XML paragraphs with a styling region) carrying the same captions, for testing XML caption parsers and IMSC players.
An LRC synced-lyric file with ID tags (title, artist, album) and four line-level [mm:ss.xx] timestamps, for testing karaoke and music-player lyric sync and LRC parsers.
Short clip with a SAMPLE soft subtitle track (mov_text): twin to the hard-burned caption.
Companion SRT for the soft-sub MP4: same SAMPLE cue timings.
Companion VTT for the soft-sub MP4: same SAMPLE cue timings.
Video QC companion SAMPLE (desync-caption.srt) for Wave G suites.
Video QC companion SAMPLE (desync-caption.vtt) for Wave G suites.
Video QC companion SAMPLE (portrait-caption.srt) for Wave G suites.
Video QC companion SAMPLE (portrait-caption.vtt) for Wave G suites.
Video QC companion SAMPLE (square-caption.srt) for Wave G suites.
Video QC companion SAMPLE (square-caption.vtt) for Wave G suites.
Plain UTF-8, no byte-order mark, Unix LF line endings. The reference member of this set: every other file here carries the same five cues, so a parser's output can be diffed against this one. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.
UTF-8 with a leading U+FEFF byte-order mark. Windows caption tools emit this constantly, and a parser that does not strip it sees the BOM as part of the first cue number and fails to match its index. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.
UTF-8 with Windows CRLF line endings. Parsers that split on a bare \n leave a trailing carriage return on every line, which usually surfaces as a stray box glyph at the end of each caption. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.
Both awkward properties at once (a BOM and CRLF endings), which is what a file saved by Notepad on Windows actually looks like. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.
UTF-16 little-endian with a BOM. Every second byte is NUL, so a parser that reads bytes as UTF-8 or ASCII sees a file that appears to start and end immediately. Tools must detect the BOM, not assume UTF-8. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.
UTF-16 big-endian with a BOM: the byte order most decoders forget to handle, since little-endian dominates in practice. Identical cue content across the whole set, so any difference in a parser's output is an encoding bug and nothing else.
Japanese captions mixing kana, kanji and full-width punctuation. Full-width characters occupy two columns in a monospaced renderer, so line-length limits computed in code points under-count them.
Right-to-left Arabic with joined letterforms, including a bidirectional line where Western digits sit inside RTL text. Exercises the bidi algorithm and any renderer that assumes left-to-right layout.
Right-to-left Hebrew without letter joining: a second RTL script, so a renderer cannot pass by special-casing Arabic shaping alone.
Cyrillic captions: outside ASCII but still single-width and left-to-right, which isolates encoding handling from layout handling.
Characters above the Basic Multilingual Plane, a composed/decomposed accent pair, and a zero-width-joiner sequence. Anything that measures caption length in UTF-16 code units rather than graphemes miscounts these.
Broadcast closed captions as Scenarist SCC: SMPTE timecodes followed by hexadecimal CEA-608 byte pairs, with odd parity set on every byte as the standard requires. Uses pop-on mode: RCL to load, ENM to clear non-displayed memory, a preamble address code for row 15, the character pairs, then EOC to display. This is the fixture that exposes decoders which treat captions as text: the parity bits, the two-byte control codes and the frame-accurate timecodes all have to be handled.
Timed text as DFXP, byte-for-byte a TTML document, just under the extension Netflix, Adobe and older captioning tool-chains still use. Same tt root, same head/body/div/p structure, same styling and region attributes. It exists to check that a caption parser dispatches on document content rather than on the file extension: a parser that accepts .ttml but rejects an identical .dfxp is exactly the bug this catches.
The same five cues as a plain JSON array with float second timings: the shape most caption pipelines use internally between parsing one format and writing another. Handy as the expected intermediate when testing a converter, since it removes timestamp-formatting differences from the comparison.
Three cues whose time ranges deliberately overlap, so at 3.2 seconds all three are active at once. Legal in SubRip and common in multi-speaker transcripts, but plenty of renderers assume one cue at a time and either drop the extras or stack them off-screen.
Cue indices run 1, 2, 3 but the timestamps do not: the file is ordered 6.5s, 1.0s, 3.5s. The spec does not require chronological order, so a conforming parser must sort by start time rather than trusting file order. Parsers that stream cues straight to a renderer show them in the wrong sequence.
A cue whose start and end are identical, and one lasting a single millisecond. Both appear in machine-generated captions from forced-alignment tools. A renderer that computes a display duration and divides by it, or that filters out non-positive durations without saying so, mishandles these.
One caption line of 334 characters against a 32-column broadcast convention. Exercises wrapping, truncation and validation paths, and shows immediately whether a burn-in tool wraps text or lets it run off the frame.
WebVTT cues carrying the full positioning grammar (line, position, align and size) plus named cue identifiers instead of numbers. Captions are placed at four different points in the frame, which is what real subtitles do to avoid covering burned-in text. Parsers that treat everything after the timestamp as cue text will fold these settings into the visible caption.
WebVTT exercising the parts of the format beyond plain text: a STYLE block with ::cue selectors, a named REGION, voice spans, cue classes, and inline bold/italic/underline/ruby markup. A parser that handles only timestamps and text will render the tag names as visible characters.
A WebVTT file used as a chapter track rather than captions: cue text is a chapter title and the cues tile the timeline with no gaps. Players surface these as seek-bar markers, so it exercises a different code path from subtitle rendering despite being the same file format.
A WebVTT metadata track whose cue payloads are JSON objects rather than text for display. This is how timed analysis output (scene changes, detections, speech segments) is carried alongside a video and read from JavaScript via the cue change event. Nothing here should ever be rendered on screen.
Advanced SubStation Alpha using the features that distinguish it from SubRip: per-syllable \k karaoke timings in centiseconds, a full V4+ style definition with primary and secondary colours, and an \an override that repositions a line. Converting this to SRT necessarily loses all of it, which makes it a good test of whether a converter warns about that or drops it silently.
Five hundred short sequential cues over four minutes. Small in bytes but long enough to expose quadratic parsing, per-cue DOM churn, and UI that re-renders the whole caption list on every cue change.
An intentionally corrupt SubRip file: the first cue's timing line is missing the --> separator, so it cannot be parsed as a time range. The second cue is well-formed, which is the point: a robust parser should report the bad cue and still return the good one rather than failing the whole file.
An intentionally corrupt SubRip file with two separate index problems: the first cue is numbered with a word, and index 2 is then used twice. SubRip indices are advisory rather than load-bearing, so this distinguishes parsers that key cues by index (and lose one to the collision) from those that do not.
An intentionally corrupt SubRip file that stops in the middle of the third cue's timestamp, as a truncated download or an interrupted write would. There is no trailing newline. Tests whether a parser returns the two complete cues or discards everything because the tail is unparseable.
An intentionally corrupt WebVTT file with the mandatory WEBVTT signature removed from the first line. The cues themselves are perfectly valid. The spec requires strict rejection, so a browser refuses it outright while many lenient parsers accept it: a useful disagreement to be able to reproduce.
An intentionally corrupt SubRip file whose first cue ends three seconds before it begins. Nothing is malformed at the text level, so parsers accept it and the problem only surfaces downstream, as a negative duration, a caption that never displays, or a sort that puts the timeline out of order.
An intentionally corrupt TTML document with an unclosed p element, making it not well-formed XML. Any conforming XML parser must reject it outright, which is exactly the useful property, since it distinguishes real XML parsing from regex-based caption scraping that would happily extract both cues.
An intentionally corrupt SCC file whose first caption is valid but whose second carries byte pairs with the wrong parity. CEA-608 requires odd parity in bit 7 of every byte, and broadcast decoders use it to detect transmission errors. Tests whether a decoder checks parity at all, and whether it drops just the bad caption or the whole file.
An intentionally corrupt SubRip file with a lone UTF-8 continuation byte appended: a byte that can never legally start a character. Both cues are otherwise fine. Exercises the difference between strict decoding, which raises, and lenient decoding, which substitutes a replacement character and continues.
A machine-readable index of all 67 timed-text, streaming-manifest and ad-signalling fixtures in this wave, with id, format, path and byte size for each. Useful as a work-list when running a parser across the whole suite, and as a manifest to diff against after regenerating.
The same cues in Windows-1252, the legacy code page behind most real-world caption mojibake. Pure ASCII until the curly quotes and em dash, which encode as single bytes 0x93, 0x94 and 0x97: none of which is valid UTF-8. A tool that assumes UTF-8 either raises or silently substitutes replacement characters exactly where the punctuation was. There is no BOM and no in-band signal, so correct handling requires either charset detection or being told.
Identical to the reference file except the final newline is missing, so the last cue is terminated by end-of-file rather than by a blank line. SubRip separates cues with a blank line, and parsers that split on a double newline and discard the remainder drop the final cue entirely: a bug that is invisible until a file happens to end this way.
One file with both line-ending conventions: CRLF for the opening cues and bare LF for the rest, the shape a caption file takes after being edited on two platforms or assembled from two sources. Parsers that detect the convention once from the first line and then apply it to the whole file mis-split everything after the switch.
WebVTT with a byte-order mark ahead of the mandatory WEBVTT signature. The spec explicitly allows this, and browsers accept it, but a naive check that the file literally starts with the six bytes 'WEBVTT' rejects a perfectly valid file. The mirror image of the missing-header corrupt fixture: one is valid and often refused, the other is invalid and often accepted.
Cue text mixing escaped entities, raw ampersands, unescaped angle brackets used as maths, and one genuine italic tag. SubRip has no formal escaping rules, so every parser draws the line somewhere different. Shows immediately whether a tool decodes entities, passes them through, or mistakes '3 < 5' for an unclosed tag and swallows the rest of the line.
A WebVTT segment carrying X-TIMESTAMP-MAP, the header HLS uses to align caption times with the MPEG-TS presentation clock. Cue times are relative to the map rather than to the file, so a player that ignores the header renders every caption ten seconds early. Invisible in a text editor and a classic cause of 'captions are out of sync' reports.
Cue text that contains the --> separator, and a second cue whose text looks exactly like a timing line. A parser that finds timing lines by searching for '-->' anywhere rather than by tracking cue structure splits these into extra phantom cues. Structurally valid SubRip throughout: the file is correct and the naive parser is wrong.
The conventions captioners actually use: speaker names in caps, leading dashes for alternating dialogue, square brackets and parentheses for sound effects, and music notes around lyrics. None is part of the SubRip grammar, so tools that extract speaker names or strip non-speech cues have to pattern-match them. Useful for testing transcript extraction and caption-cleaning passes.
WebVTT with multi-line and single-line NOTE comment blocks, runs of up to five blank lines between cues, and trailing blank lines at end of file. All legal: the spec treats blank lines as separators, not as structure. Parsers that count blank lines to find cue boundaries, or that treat NOTE as a cue identifier, produce phantom cues or drop real ones.
Enhanced LRC with per-word timings in angle brackets alongside the usual per-line timestamps: the format karaoke and lyric-sync apps consume. Includes the standard metadata tags, an offset field, and a final empty timestamp that clears the display. Simple LRC parsers read only the line timings and silently render the word markers as visible text.
TTML using the features broadcast caption profiles rely on: two layout regions, named styles including a text outline, a declared frame rate and media time base, and spans nested two deep so styles cascade. Converting this to SubRip necessarily flattens all of it. Tests whether a TTML implementation resolves style inheritance or only reads the leaf text.
SubViewer/SBV as YouTube exports it: no cue indices, a comma rather than an arrow between start and end, and single-digit hours. Superficially similar enough to SubRip that format detection by eye fails, which makes it a good test of sniffing logic: a parser that guesses SubRip from the timestamps then trips on the missing index.
Per-cue timings and text metrics for the shared cue list, as a caption QC tool would export them: start, end, duration, line count and character count. Useful as the expected output when testing a caption analyser, and as a quick way to check reading-rate calculations against known values.
The WebVTT half of a scrub-preview pair: each cue covers a slice of the timeline and its payload is a media-fragment URL naming a rectangle of the sprite sheet. This is how seek-bar previews are delivered in practice, and the #xywh fragment syntax is the part players implement inconsistently: some resolve it relative to the VTT, others to the page, and some ignore the fragment entirely and show the whole sheet.
One MKV carrying three soft subtitle tracks (English, Spanish and Japanese), each with a real ISO 639-2 language tag and a human track title, and English flagged as the default. Every cue names its own second and its own chapter, and the picture burns in a matching timecode, so you can confirm the right track is displaying without trusting the player's own menu labels. Single-track sample files never exercise the code that actually breaks: track enumeration, language-tag mapping and default selection. This is the smallest file that does.
Two English subtitle tracks in one file: the full dialogue track, and a forced-narrative track that carries only the two moments where on-screen text needs translating. The second track sets the `forced` disposition, which tells a player to display it even when the viewer has subtitles switched off. The forced track is deliberately two cues, not eight. A forced track that repeats the full dialogue is the most common way this feature is got wrong in the wild, and a fixture that reproduced that mistake could not be used to detect it. Useful for checking that a player reads the flag rather than the track order, and that a transcoder preserves it: many drop the disposition silently and the file still looks fine until a viewer turns subtitles off.
Standard subtitles and SDH (Subtitles for the Deaf and Hard of Hearing) as two separate English tracks, distinguished only by the `hearing_impaired` disposition. The SDH track adds the non-speech information a deaf viewer would otherwise lose (the tone that is playing, the marker that is moving) in square brackets above each line. Because both tracks are tagged `eng`, any picker that keys on language alone shows two identical-looking entries. That is exactly the bug this file exists to surface: the flag is the only thing that separates them, and it is the thing most often dropped in a remux.
An ASS subtitle track that carries its own styling: two named styles, alternating cue by cue, one bottom-centred and one top-centred in italic teal. ASS is the only widely-used soft subtitle format that survives a remux with its positioning and colour intact. The useful test is what happens on the way out. Convert this to SubRip or to WebVTT and the styling is silently discarded: the cues remain, so the conversion reports success while half the information is gone. Converting to MP4 is worse still: mov_text keeps neither the styles nor the positions.
Two soft subtitle tracks inside an MP4, in mov_text: the 3GPP Timed Text format that is the only subtitle codec MP4 officially carries. Safari and QuickTime read these natively; most other browsers ignore them entirely and expect a sidecar WebVTT track instead, which is the single most common reason subtitles appear on an iPhone and nowhere else. Compare with the MKV in this group: the cue text is identical, but mov_text drops all styling and positioning, so this is also the file to test a lossy subtitle conversion against.
WebVTT muxed inside a WebM container, which the Matroska specification allows and almost nothing consumes. No browser surfaces an embedded WebVTT track through the HTML TextTrack API (the web platform expects a separate <track> element pointing at a sidecar file), so this is the fixture for the gap between what a container is permitted to hold and what a player will actually give you. One caveat about this file specifically. Every other fixture in this phase carries byte-identical H.264 video, but the WebM muxer accepts only VP8, VP9 or AV1 video and WebVTT subtitles (that restriction is the container's definition, not a limitation of the tooling), so the picture here is re-encoded to VP9 from the same source frames. Same content, different bytes.
The control for this group: the same picture with no subtitle track at all. Every other file here differs from this one only by what was muxed in. Worth more than it looks. A track enumerator that returns an empty list, one that returns a single null entry and one that throws are three different behaviours, and none of them can be told apart using a file that has subtitles.
A WebVTT chapter track for the 24 second film in this group, with 12 cues at 2.125 second intervals. The cues are not decoration: each one marks a boundary between two of the twelve generated segments, verified against the measured transitions, so seeking to a cue lands on a join. Chapter tracks over two-second clips have nowhere to seek to; this is the first in this library with somewhere to go.
The WebVTT index for the sprite sheet in this group: 24 cues, one per second, each naming a rectangle of the sheet with an xywh media fragment. The sheet and this index are each useless alone, which is why they are paired.
A WebVTT chapter track for the 24 second film in this group, with 12 cues at 2.125 second intervals. The cues are not decoration: each one marks a boundary between two of the twelve generated segments, verified against the measured transitions, so seeking to a cue lands on a join. Chapter tracks over two-second clips have nowhere to seek to; this is the first in this library with somewhere to go.
The WebVTT index for the sprite sheet in this group: 24 cues, one per second, each naming a rectangle of the sheet with an xywh media fragment. The sheet and this index are each useless alone, which is why they are paired.
A WebVTT chapter track for the 24 second film in this group, with 12 cues at 2.125 second intervals. The cues are not decoration: each one marks a boundary between two of the twelve generated segments, verified against the measured transitions, so seeking to a cue lands on a join. Chapter tracks over two-second clips have nowhere to seek to; this is the first in this library with somewhere to go.
The WebVTT index for the sprite sheet in this group: 24 cues, one per second, each naming a rectangle of the sheet with an xywh media fragment. The sheet and this index are each useless alone, which is why they are paired.
