The longer a recording runs, the more ways it can die. An app crash at minute 5 costs you 5 minutes. The same crash at hour 3 of an interview, deposition, or live event costs you something you may not be able to get back.
We build KeepTake around the promise that a recording, once started, cannot be thrown away. This post explains the specific failure modes of long recordings and the engineering that defuses each one. Even if you never use our app, knowing these will change how you set up long takes.
Failure mode 1: the unfinalized file
Most video files are written in two phases. During recording, the app streams compressed frames to disk. At stop, it writes the index (the “moov atom” in MP4/MOV terms) that tells players where every frame lives.
That design has a brutal consequence: if the app dies before finalization, you have gigabytes of frames and no index. Many players will refuse to open the file at all. This is why a crashed QuickTime recording is so often unplayable, even though nearly all the data is sitting right there on disk.
The fix: fragmented MP4
The MP4 format has a mode designed for exactly this: fragmented MP4.
Instead of one giant index written at the end, the file is written as a stream of small self-contained fragments, each carrying its own index data.
KeepTake records MP4 with fragmentation on keyframe boundaries (ffmpeg’s frag_keyframe mode).
The property this buys is the whole ballgame: the file on disk is playable at every moment during recording. Kill the process, kick out the power cord, kernel panic, it does not matter. Everything up to the last completed fragment is a valid, playable movie. When recording stops normally, the file finalizes cleanly and is a perfectly ordinary MP4.
For lossless recording, KeepTake uses FFV1 in MKV, and MKV has good interrupted-write behavior by design. It was built for streaming and muxing, and players are accustomed to reading MKV files that were never “closed”.
Failure mode 2: the recording that never touched disk
Some tools buffer significant amounts of video in memory, or record to a temporary location and move the file into place at stop. Both patterns convert a small failure into total loss: whatever was in memory is gone, and temp files get cleaned up by the OS or by the app’s own startup logic.
KeepTake’s rule is that frames stream straight to the final, persistent, timestamped file from the first second. There is no temp file, no rename-at-the-end, and nothing is ever auto-deleted. Even a recording you stop after two seconds is a real file in your recordings folder. Memory use stays constant no matter how long the recording runs, because nothing accumulates in RAM.
If you use another tool, find out where it writes during recording. If the answer is a temp directory or “in memory until stop”, treat every long take as at risk.
Failure mode 3: the full disk
Video is big. An uncompressed 1080p30 recording eats roughly 8 GB per minute, and even lossless FFV1 consumes around 27 GB per half hour. We put real numbers on every format in our format comparison.
A disk that fills mid-recording is a genuinely nasty failure. The encoder cannot write, the OS starts misbehaving, and many apps crash in exactly the way that destroys the unfinalized file from failure mode 1.
The fix: watch the disk, stop before the cliff
KeepTake runs a live disk-space monitor during every recording. It knows the current write rate, shows you the estimated remaining recording time, warns you early, and if the volume approaches full it gracefully auto-stops the recording, finalizing a clean playable file with headroom to spare. An out-of-space condition becomes a saved recording plus a notification, not a corrupted file.
Doing this manually: before a long take, check free space against the per-minute cost of your format, and leave generous margin. The margin is not paranoia; the OS itself degrades when the boot volume gets close to full.
Failure mode 4: the single giant file
A three-hour take in one file is one basket with all the eggs. It is also unwieldy: slow to copy, slow to open in some editors, and awkward to upload.
KeepTake offers auto-segmenting: split the recording into a new file every 5, 10, 15, or 30 minutes. Segments cut on keyframe boundaries, so nothing is lost between files, and each finished segment is fully finalized the moment it closes. For very long sessions this means most of your recording is already in safely closed files while the take continues.
Segmenting is optional because single-file recording with fragmentation is already crash-safe. But for multi-hour material, segments make the aftermath (copying, archiving, uploading) dramatically nicer.
The checklist for a long take
Whatever software you use:
- Confirm where the app writes during recording, and that a crash leaves a playable file. Test this by force-quitting a test recording.
- Check free disk space against your format’s real per-minute cost, with wide margin.
- Prefer crash-tolerant containers: fragmented MP4 or MKV, not plain MOV.
- For multi-hour sessions, split into segments.
- Do a full-length dry run once. Not 30 seconds; an hour. Long-take failures, like gradual audio loss on macOS, only show up over time.
The force-quit test in step 1 is the single most informative thing you can do. If your recorder fails it, every long take you make with it is a gamble. We built KeepTake so that test is boring: you force-quit, the file plays, every time.