Measured · 301 packs · one machine

What Crate saves, and how we measured it.

72.5% aggregate reduction 301 real packs Both figures computed by the engine

That aggregate is the least interesting number on this page, because one total hides every session that did badly. So the rest of this page is the spread behind it, the cohort that actually does the work, the packs at the very top of the range, a head-to-head against thirteen archiver configurations on size and on time in both directions, and the three things we are careful never to claim.

Method

Two byte counts, one subtraction.

Measured · 301 packs

The spread, not the headline.

Every quantity on this page sits on the same rule, so you can compare them by eye. Here is the reduction achieved across all 301 packs — the box spans the middle half, the line is the median, and the whisker runs from the bottom tenth out to the best result recorded.

Measured · 35 packs above 89%

What is actually up at the top of the range.

A distribution that reaches 96.0% invites one fair question: does anything real live there, or is the tail a rounding artefact on a folder of empty files? These are the packs above 89%. There are 35 of them, and 16 are sessions of 1 GB or more. This is the evidence behind the “up to” end of the claim, and it is the top of the range — not the result to expect.

Six of the 35, chosen to show the sizes involved rather than the best ratios. Every one is a multi-gigabyte session, so the tail is not an artefact of tiny folders. It is also not typical: the median for sessions of 1 GB and over is 72.6%, and across all 301 packs it is 58.6%. If you are budgeting a drive, budget with those two.

Measured · benchmark run 2026-08-20

Against every major archiver, at their best settings.

Four real client sessions, named by class and never by client, each packed by Crate on both shipping presets and by eleven other archiver configurations set for maximum compression — thirteen runs per class. Rows are ordered by engine family, not by result. Every number in the three tables below is measured; nothing in them is projected.

How the run was done. Single run, one machine, serial, nothing else running. Not averaged — read sub-second gaps as ties.

Size — reduction achieved

Reading the bar colours

• Crate. Both presets, on the same rule as every other bar on this page.
• Package under 1.5× the size of ours. Bigger than Crate’s, but within half again.
• Package 1.5× the size of ours, or more. One round threshold, applied identically to all four classes — never tuned per column.
• Did not give every byte back. The one mark on this page that is not about size. Hatching outranks any colour band.

Amber and red here mean size, and nothing else. RAR, 7-Zip, xz, zstd, gzip and ZIP all restored every class at 100% verified. A red bar says the package came out larger; it never says the engine is unsafe. Integrity has its own channel — the hatch — precisely so the two can never be read as one claim. The band is computed from the measured sizes already in the table:

Two notes on the swatches. These bars are a size scale and sit only inside the benchmark tables; the square teal and amber chips in the reading key at the top of the page are a provenance scale — measured against derived — and appear only on text. Different shape, different place, different question. And nothing in these three tables is derived anyway: every figure in them was measured on the run.

One consequence of a fixed threshold, stated so it is not mistaken for tuning: zstd --ultra -22 lands just inside amber on Live tracks and well into red on Stems. Same rule, two corpora, two answers.

All four classes are complete at 13 of 13 runs. Every engine in the table has now finished on every class, so no cell in the three tables above is blank — and none of them is guessed.

Time to pack — wall clock

Smaller usually costs time; here it did not. Crate packed faster than every other configuration in every class. Three results from the table, plainly: on Stems, ZIP -9 takes 64.0× Crate Default’s pack time to land 22.8 points behind on size. On the mix session, 7-Zip -mx=9 solid + delta takes 49.6×. On live tracks that same configuration spends 797.9 s against Crate’s 30.4 s and still finishes 5.0 points behind.

Slowest pack in each class: 7-Zip -mx=9 solid + delta at 49.6× on the mix session and 44.9× on loop-heavy, ZIP -9 at 64.0× on Stems, zstd --ultra -22 --long=31 at 59.3× on live tracks. The closest anything came to Crate was FLAC + tar at 1.3× — the one configuration that lost files.

Time to open — wall clock

The direction that matters when you are trying to get back to work. Crate does not win this one everywhere, and the table says where. On live tracks, 7-Zip -mx=9 opened faster than Crate — 15.3 s against 17.4 s, a real 0.9×. On the mix session, zstd --ultra -22 and its --long=31 variant finished in 2.2 s to Crate’s 2.3 s, which under the tie rule is a tie rather than a win for anyone. Crate opened quickest on loop-heavy and on Stems.

Read this table with one caveat, and it cuts both ways. Unpack time is a full expand of the archive to a fresh tree. It excludes Crate’s per-file SHA-256 verification pass — work no other engine performs at all. So our figures here flatter us, and everyone else’s describe an expand that never checks whether the bytes came back. FLAC + tar opened the live-tracks archive in 31.7 s; 1.8% of what came out matched the source.

Settings, as run

Not claimed

Three things this page does not say.

What we do claim, and gate every release on, is separate from all of this: a restored session is bit-identical to the original, per file, by SHA-256 — or the file is reported as failed and quarantined rather than delivered. Size is a benefit. Fidelity is the product.

Known bias

Where these figures are weakest.

Every dataset has a shape imposed by how it was collected. Here is the shape of this one.

• Floor

  These totals are a floor, not a census. Analytics are opt-out and not every install is on the current version, so packs exist that this dataset has never seen. The true aggregate is larger than 711.43 GB by an amount we cannot measure and will not estimate.

• One machine

  The 301 packs come from a single working machine and its real client sessions. That is a genuine workload rather than a synthetic corpus, but it is one studio’s taste in material, sample rate and plugin set — not a survey of the industry.

• Single run

  Every benchmark timing is one run on one machine, serial, with nothing else running. It is not averaged across repeats, so small gaps carry no information — treat anything under a second as a tie. The size figures do not have this problem: an archive is the size it is.

• A correction

  The xz --delta=dist=6 -9e row was measured twice. On the first run its filter never engaged: the harness placed a bare -9e preset after --delta, which resets the xz filter chain, so that archive came out byte-identical to plain xz -9e. The harness was corrected and the row re-measured on a quiet machine; the figures in all three tables above are that corrected run. It is written down here rather than quietly replaced.

• Verification

  Unpack times exclude Crate’s per-file SHA-256 pass, which no other engine performs. That flatters our restore figures, and it is also the reason a Crate restore can tell you a file came back wrong while a plain expand simply cannot.

• Corpus

  The head-to-head corpus is four real client sessions, named by class and never by client. Four sessions is enough to show a consistent margin; it is not enough to promise one on material we have not seen.

• Tail

  The 35 packs above 89% are the top of the range and nothing more. They are shown because a claim that reaches 96.0% should have to produce the sessions that got there — not because they predict yours. The two numbers worth planning around are 58.6% across all packs and 72.6% for sessions of 1 GB and over.

• Settings

  Every competing archiver ran at maximum compression, with a large dictionary and solid mode where supported. If you can beat these numbers with a better configuration, we would rather know than not — the settings are listed above so the run is reproducible.

• Units

  Decimal throughout: 1 GB = 10⁹ bytes. Reading these figures as binary GiB would overstate every size on the page by about 7%.