Manfred

Got questions or doubts? Ping me on Discord

Never lose a take

A take is written to disk while you record it, so while the disk keeps up a crash or a power cut costs you only its last moments.

What it does

A take is a .manf file, Manfred's own container, written so that whatever reached the disk before the stop reads back. The sound, the video, the loudness and the gate's decisions go in as chunks, each with its own CRC-32 check, and every chunk stands alone.

Nothing already written is ever rewritten. The writer hands its bytes to the system at every flush, every 250 ms while you record, and syncs them to the disk whenever 500 ms have passed with anything unsynced. Stop writes an index and a trailer and syncs once more.

The numbers below for a stop, a crash and a power cut are bounds that follow from that flush and sync design, not timed runs. The crash and power-cut bounds hold while the disk keeps up: the writer can queue tens of seconds of media for a disk that falls behind, and a crash or a power cut loses whatever is still queued.

Open a take that never reached its trailer and Manfred scans it chunk by chunk, checking each one. A damaged stretch is skipped up to the next sync point that checks out; a torn end is cut. The take opens as recovered, with everything before the cut, and Manfred makes the file whole again, so the next open is instant.

  • A crash

    If Manfred is killed, what it had handed to the system is kept: everything up to its last flush, which the recorder sends about every 250 ms while the disk keeps up.

  • A power cut

    If the power goes, everything up to the last sync is on the disk: at most about the last half second is lost while the disk keeps up.

  • The untouched microphone, always

    The noise gate is on by default, and every take keeps the untouched microphone beside it; the gated sound is rebuilt from it whenever you play or export. A take torn mid-word may miss the gate's last 10 ms or so of decisions, and that stretch plays as if the gate hadn't turned. The raw sound is never affected.

  • The disk stays out of the way

    The recorder hands its sound to one writer thread and never touches the disk itself; compression runs on that thread. Up to 5 seconds of sound wait in the microphone's ring and 4,096 writes in front of the disk. If the disk falls further behind than that, the newest sound is dropped and counted, kept as silence in its place so the picture stays in sync, and the take is still saved.

Bounds by design, and measurements

lost when you stop a take, a bound by design
0 ms
How it follows
at most lost if Manfred is killed mid-take while the disk keeps up, a bound by design
≈250 ms
How it follows
at most lost if the power goes mid-take while the disk keeps up, a bound by design
≈500 ms
How it follows
from the start of a take to the first sound in the file, measured
266 ms
How it was measured
samples and frames dropped with the window's thread frozen 500 ms, six times in a 60 s take, measured on a test build
0
How it was measured
sound dropped with every disk sync slowed by 20 s, measured on a test build
0
How it was measured
of sound dropped with every disk sync slowed by 40 s, past the buffers, every sample counted and the take saved, measured on a test build
18.2 s
How it was measured

How to use it

  1. In the window, press REC.

  2. In manfred tui, r or Space starts and stops a take.

  3. From any terminal, record the microphone for a minute:

    manfred record --seconds 60
  4. Your takes, newest first; a recovered take opens like any other:

    manfred list
  5. The sound as the microphone gave it, before the gate:

    manfred export take.manf --audio --raw

Recording under stress

Measured 2026-10-20 on a release build from before the noise gate, with 60-second takes of a voice recording and a 1280x720, 30 fps test camera encoded to H.265 on the GPU. Test-build hooks froze the window's thread or slowed every disk sync; they were a patch for the proof and are not in the product. Manfred 1.2.0 keeps every buffer size, and the run has not been repeated on 1.2.0.

  • The window frozen

    With the window's thread frozen for 500 ms, six times in 60 s: 2,919,360 of 2,919,424 samples, the 64 short being the last 10 ms block at the stop, and 1,825 of 1,825 frames. Nothing was dropped.

  • A slow disk

    With every disk sync slowed by 0.4 s, and then by 20 s: no sound dropped, and 1,824 of 1,824 frames captured. The 20-second stall fits because 20 s waits in the writer's queue and 5 s more in the microphone's ring.

  • Past the buffers

    With every disk sync slowed by 40 s: 18.2 s of sound (874,080 samples) and 447 frames were dropped, every one counted. The take was still saved, the dropped sound is silence in its place so the picture stays in sync, and the window said what was lost: “18210 ms were lost and are silence. 447 video frames were dropped.”