File security & the password ring

A collection saves as a single sealed .mtxCol file. Sealing does two jobs: it can protect the file with passwords, and it makes the file resilient so damage can be repaired. This page covers both, and explains how the recovery settings trade size for resilience.

Passwords: two layers

A collection can carry two independent passwords: an external password that locks the file as a whole, and an internal password that protects the contents inside. Encryption is AES-256-GCM, with the key derived from your passphrase through a two-stage key-derivation scheme; the file header is authenticated too, so it cannot be altered or transplanted without the password check failing.

Warning — there is no backdoor. If you lose the passphrase, the data cannot be recovered. Keep your passwords (and your password ring) safely backed up.

The password ring

The password ring is your personal keychain of passphrases, each with a name and notes. When you open a file whose passphrase is in your ring, Tuning Editor recognises it by fingerprint and opens it automatically. You can set a default passphrase for new collections, and import or export the ring to move it between machines.

Figure 1

How recovery works

The .mtxCol is self-healing: alongside your data it stores Reed-Solomon recovery information, so localized corruption or a truncated file can be repaired automatically when you open it. In plain terms:

• the file is split into small blocks and grouped into stripes; each stripe carries extra parity blocks that let missing or damaged blocks in that stripe be rebuilt;
• the blocks are interleaved across the file, so one continuous scratch is spread thinly — a handful of bytes per stripe rather than wiping out a whole stripe at once;
• every block is checksummed, so the reader knows exactly which blocks are bad (and can rebuild them), and the small layout header is stored in three copies so losing one does not orphan the file.

Truncation is handled the same way: the missing tail is treated as damaged blocks and rebuilt, within the parity budget.

Recovery strength (the percentage)

The recovery strength, set on the General tab of Preferences, is a percentage (about 10% by default) that decides how much parity each stripe gets — and that is the single knob that trades size for resilience:

• Size — the sealed file grows by roughly that percentage. 10% adds about a tenth to the file; 25% about a quarter.
• Resilience — in return, each stripe can lose up to about that percentage of its blocks and still be rebuilt. Because the blocks are interleaved, that roughly corresponds to surviving a continuous damaged stretch about that fraction of the whole file.

So a higher percentage repairs more damage but makes a bigger file; the default is a sensible balance for everyday use.

The .rec sidecar

For the strongest protection, also write a separate .rec recovery file (the sidecar option, also on the Preferences General tab). The .rec holds an independent parity set at the same percentage, and when it sits next to the collection its budget adds to the parity already inside the file — so a stripe can survive losing up to twice as much. It is the best defence against larger gouges and heavier truncation, at the cost of an extra file to keep with the collection (roughly the size of the parity, i.e. about the same percentage of the collection).

In short, three useful setups:

• Low percentage, no sidecar — smallest file, basic protection against minor corruption.
• Default ~10%, no sidecar — a balanced everyday choice.
• Higher percentage + .rec sidecar — largest footprint, but the toughest recovery — good for archives and field copies you cannot easily replace.

Tip — if you enable the .rec sidecar, keep it in the same folder as the .mtxCol. The collection still opens without it, but the two together give the best chance of a full recovery.

See also

• Collections & versions
• Preferences — recovery strength and the .rec option.
• Troubleshooting — a protected or damaged file that will not open.