ClipReady Get ClipReady
Product menu

ClipReady

Chapters and timecode, carried over

Last updated:

Two things go missing between a disc-sourced MKV and an editable MOV, and they go missing for opposite reasons. Chapters exist in the source and get dropped. Timecode never existed in the source and has to be created.

Chapters: present, and easily lost

Matroska stores chapters properly, and a Blu-ray or DVD backup usually arrives with a full set. MOV and MP4 can hold chapters too, so there is no technical reason to lose them.

They get lost anyway, because carrying them is a deliberate act. A tool that does not explicitly map chapters across simply does not, and you find out when you are scrubbing a two-hour file looking for a scene you know is about forty minutes in.

For editorial this matters more than it sounds. Chapter markers on a disc backup are usually scene boundaries, which is exactly the navigation you want when you are pulling one sequence out of a long file.

Timecode: not missing, absent by design

This one confuses people, because “the timecode was lost” implies it was there.

Matroska has nowhere to put a SMPTE timecode track. It is not a bug or an omission in your file. The container has no such concept. So a remux cannot preserve timecode from an MKV, no matter how careful it is. If you want a MOV with timecode, something has to author one.

That is a meaningful difference. Preserving is safe; authoring is a claim. Written badly, a timecode track is worse than none at all, because everything downstream believes it.

Where a wrong timecode comes from

Two common ways:

Inheriting a stale rate. If a film DVD reports 29.97 and the timing is restored to its real 23.976, a timecode track authored from the source’s declaration counts at 29.97 while the picture runs at 23.976. Every frame number after the first is wrong, and it drifts further the longer the file runs.

Letting the muxer guess. Some tools pass source metadata through wholesale, and the MOV muxer will happily synthesize a timecode track from whatever tag it finds, including one that was never meant to describe this file.

What ClipReady does about it

Chapters are carried across explicitly. If the source has them, the output has them.

Timecode is authored at the output rate, not the source’s. When a soft-telecined DVD is restored to 23.976, the timecode track counts at 24 and describes the file that actually exists rather than the one that arrived. Each track records where its timecode came from, whether preserved from the source, advanced to match an In point, or synthesized, so it is never ambiguous which of those happened.

When a truthful timecode cannot be authored, ClipReady writes none and says so. It also explicitly stops the muxer inventing one from a source tag behind the plan’s back, which is the failure mode that produces a file that looks correct and is not.

And if you pull a single range out of a longer file, the clip’s timecode is stamped for its own In point, so it lines up where it belongs rather than starting at zero.

What the finished file gets checked for

Before anything is saved, ClipReady loads the output back through AVFoundation and confirms the timecode track is present, associated with the right video track, at the right rate, with a legal drop-frame flag and the expected first sample. If any of that is wrong, the file is not written.