SRT — Cues Out of Chronological Order
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.
1
00:00:06,500 --> 00:00:09,000
Third by time, first in the file
2
00:00:01,000 --> 00:00:03,000
First by time, second in the file
3
00:00:03,500 --> 00:00:06,000
Second by time, last in the file
Specifications
- Cues
- 3
- File Order
- 3, 1, 2
- Time Order
- 1, 2, 3
- Indices Sequential
- yes
Testing contract
Expected to recover- Scenario
- Parse the file and sort the cues by start time, then compare against file order.
- Expected result
- 3 cues appear in file order 3, 1, 2 but in time order 1, 2, 3, and the indices are sequential. SubRip does not require chronological ordering, so a parser must sort by start time; one that assumes file order is chronological plays the third cue first.
What is a .srt file?
SRT (SubRip) is a plain-text subtitle format listing numbered cues, each with a start and end timecode and one or more lines of text. It is simple, human-readable, and extremely widely supported by players. It carries no styling metadata beyond basic inline tags.
How to use this file
Use an example SRT to test subtitle parsing, timecode handling, and converters that translate between SRT and WebVTT or other caption formats.
How to use this file for testing
“SRT — Cues Out of Chronological Order” is a deterministic Novus Examples fixture for Subtitle parsing, Video QA. 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.
Documented properties for this file: 3 cues. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such, expect parsers to fail loudly rather than silently accept them.
Media fixtures are short and synthetic by design. Prefer waveform or transcript ground truth in the same group when measuring ASR, trim, upscale, or sync tools; do not assume broadcast-quality masters.
Parse the cues and check timings against the documented count; the same captions ship across subtitle formats so you can diff a converter against a known target.
Code examples
<video controls src="clip.mp4">
<track kind="captions" srclang="en" label="English" src="out-of-order.srt" default>
</video>Related files
- csvCSV — Cue Timing ReportPer-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.
- dfxpDFXP — TTML Under Its Other ExtensionTimed 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.
- jsonJSON — Caption Cue ListThe 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.
- jsonJSON — Timed-Text Suite IndexA 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.
- webmMulti-Track Subtitles — Embedded WebVTT (WebM)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.
- mkvMulti-Track Subtitles — Forced Narrative (MKV)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.
Generated by generation/video_timedtext.py. Free for any use, no attribution required, license.