How we verify every conversion

A converted file you can't trust is worse than no converter at all — a caption file that's one frame off, or an SCC that a broadcaster's QC bounces, costs real money and real deadlines. So CutConvert's converters are verified against independent references: reference decoders for broadcast formats, published test media, property-based timecode matrices, and cross-checks against independent implementations. This page documents exactly what that means, format by format, because "we tested it" is a claim anyone can make — the details are what make it worth something.

Broadcast captions: verified against reference decoders

SCC, MCC, and EBU-STL are deliverable formats — files that get submitted to networks and platforms with rejection as the failure mode. Ours are checked against references we didn't write:

• SCC (CEA-608): output and decoding round-trip against the test media from caption-inspector, Comcast's open-source caption verification tool — the same reference material a broadcast engineer would use. Every caption file in that corpus decodes through our SCC reader and re-encodes accurately: 664 of 664 checks pass. Drop-frame timing at 29.97 fps — where most SCC tools quietly go wrong — is part of the matrix, not an afterthought.
• EBU-STL (Tech 3264): validated against published reference subtitle files from IRT (the German broadcast research institute that co-authored the spec era's tooling), covering the GSI/TTI binary block structure, not just "it opens somewhere."
• MCC (CEA-708): files follow the published MacCaption container specification, including its required attribution notice, and round-trip through our own decoder against the same 608/708 reference data.

Timecode: property-tested, then verified in a real NLE

Frame-rate math is where subtitle converters actually fail — 23.976 vs 24, drop-frame resync, hour-based start timecodes. Our timecode engine is held by a 3,202-check property matrix across all eight supported rates (23.976 through 60 fps), asserting exact round-trips, correct drop-frame skips (two frames per minute at 29.97, four at 59.94), and hour-digit preservation for timelines that start at 01:00:00:00.

Then we leave the math and check reality: ladder test files — subtitles placed at precise sub-frame offsets with unique content — imported into an actual Premiere Pro workstation to confirm the converter's frame alignment matches what the NLE really does, not what its documentation implies. That testing is why our SRT output lands on the intended frame in Premiere at every supported rate.

Project formats: cross-validated against independent implementations

Our DaVinci Resolve .drp converters were built from real project files gathered in the wild — exports from Resolve 16 through 19 found in public repositories — not from guesswork. Output is verified three ways: round-trip (a project converted out and read back must match the original clip-for-clip, name-for-name), parsing by an independent open-source .drp implementation, and parsing by a commercial converter's reader — three separately-written codebases agreeing on the same files. The Premiere .prproj converter is validated the same way, against real projects from Premiere CS6 through current Creative Cloud.

The standing rules

1. Real files first. Every converter is built and tested against genuine files from the tools that produce them — real Premiere exports, real Resolve projects, real broadcast caption files — because specs and reality diverge, and reality wins.
2. References we didn't write. Wherever an independent decoder, published corpus, or second implementation exists, our output must pass it. Marking our own homework doesn't count.
3. Every change re-verified. The full test suite — several hundred automated checks including the matrices above — must pass before any change ships. A converter that worked yesterday is re-proven today.
4. Honest limits, in writing. Where a conversion can't carry something (effects and grades in project formats, styling in caption formats), the page and the conversion report say so. We'd rather you know before you deliver.

If you ever find a file that converts incorrectly, we want it — a real failing file improves the verification corpus for everyone. Get in touch through the About page.

FAQ

How is CutConvert's SCC output verified? Against the test media from caption-inspector, Comcast's open-source caption verification tool: 664 of 664 round-trip checks pass, including drop-frame timing at 29.97 fps. That's an independent reference decoder, not our own tests grading themselves.

What does "decoder-verified" mean for broadcast deliverables? It means the files were checked by software we didn't write — the kind of tool a network's QC process uses — rather than only by the converter that produced them. If our encoder had a systematic error, an independent decoder would expose it.

How do you know the frame timing matches what Premiere actually does? We import ladder test files — subtitles at precise sub-frame offsets — into a real Premiere Pro system and confirm each lands on the intended frame, at every supported frame rate. The converter's math is also held by a 3,202-check property matrix covering drop-frame and hour-start cases.

How are the DaVinci Resolve converters tested without Blackmagic publishing the format? Against real .drp files from public sources spanning Resolve 16–19, with output cross-validated by three independent implementations — our reader, an open-source reverse-engineering parser, and a commercial converter — all agreeing clip-for-clip.

Does verification cover every conversion on the site? Every converter ships with automated tests that run on every change, and the formats with external references (broadcast captions, timecode, project files) are additionally checked against those references. New converters don't launch until they pass.

What should I do if a file converts wrong? Send it to us via the About page. Real failing files are the most valuable thing in this system — each one becomes a permanent test case.