Find files, editable templates and browser test targets by what you need to make or test. The directory below is cut by format; the two collections under it cut the same library by subject and by workflow.
Page 15 of 19; 24 results per page.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
Companion SRT for the soft-sub MP4: same SAMPLE cue timings.
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.
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.
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.
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-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.
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.
Video QC companion SAMPLE (desync-caption.srt) for Wave G suites.
Video QC companion SAMPLE (portrait-caption.srt) for Wave G suites.
Video QC companion SAMPLE (square-caption.srt) for Wave G suites.
