Skip to content

Features

How TSR works

Three ideas hold the program up: time as the unit of compression, the incompressible layer taken apart and put back identical, an archive you use while it stays compressed. Each has its measurement.

First idea

Time as the unit of compression

The levels 1 to 9 of archivers describe the algorithm: the same level lasts a minute on one computer and ten on another, and the space returned is discovered at the end. TSR asks how much time you want to spend, and turns it into space on your machine and your files.

  1. Scanthe tree, the metadata, the duplicates
  2. Calibration1–3 seconds, on the real files
  3. Choice of timefive levels, or seconds
  4. Planthe strongest method that fits
  5. Compressionin blocks, one core per block
  6. Index and checkfingerprints per block and per file

Calibrating on the real files

Before compressing, TSR samples the files of the batch by size band and by type, and on those samples measures the speed and ratio of every method on the machine that is working. Then it tries the filters on the real files and estimates the duplicates. All of it costs 1 to 3 seconds.

The strongest method that fits the chosen time wins. Before starting TSR shows duration, space saved and extraction time; when the job is done it compares the estimate with the result.

The estimates are cautious

The real result is almost always better than announced. On a user’s two ZIP archives the estimate was 12 seconds for 13 real ones, and 5.3 MB saved for 5.27 MB; on a mail backup the Medium level declared 21 seconds for 20. The announced extraction time stays between −2% and +16% of the real one.

The five levels are multiples of the minimum time of your machine on your files; a time written in seconds is taken literally.
LevelTime
Fastest×1.1
Fast×3
Medium×8
Slow×20
Slowest×60

For scripts and services there are also four fixed profiles, without calibration: --fast, --balanced, --backup and --max. With a fixed profile the same input gives the same archive on every machine.

Second idea

It compresses where the others stop

PDFs, Office documents, PNG, JPEG, video and gzip archives already contain a compression layer. A general archiver sees them as noise and gives back 96 to 99.5% of the original. TSR takes that layer apart, compresses the real data and puts the layer back byte for byte, after proving it can.

The ten families of already-compressed files and the measured gain of each (white paper TSR-WHP-06, September 2026).
FamilyMeasured gain
JPEG−18.2% on standard photos, −11.8% on progressive ones; a JPEG-only specialist reaches about −22%
gzip, zlib−32% on the mass of gzips that reproduce
ZIP, Office, JAR−43.5% on modern Office documents and JARs
PNG−22.9% on classic PNGs; optimised ones travel as they were
PDFFrom 87–99% down to 50–79% of the original, on PDFs written with the standard zlib
H.264 video (MP4, MOV, MKV)2–3.7% on films and footage, where the others gain nothing
Programs (x86, ARM64)26.66% against 28.22% for xz
PCM audio (WAV, AIFF, CAF)On pure PCM 11.73% against 17.85% for FLAC -8
Containers written with variants−18.5% on containers that used to go in intact
Raw 16-bit imagesCT −3.63%, MRI −1.33%; it stops where it would get worse

Every file is rebuilt first

The filter is applied, the file is rebuilt and compared byte for byte with the original: at the first differing byte the file goes in as it is.

The shorter road wins

The file taken apart and the file as it is are both compressed, and the smaller one is kept, file by file. A filter can only make the archive smaller.

The incompressible is recognised

A sample of head, quarters and tail of every block recognises already-compressed or random data before working on it: on random data the maximum profile saves 94% of the time.

Left out, and measured: files written with their own variants of the algorithm (some PDFs, encrypted streams, images optimised with zopfli or oxipng), formats without a layer to take apart (MP3, AAC, JPEG 2000, WebP) and truly random or encrypted data. They go in as they are, and the rest of the batch still gains.

Third idea

The archive is used without extracting

TSR compresses in independent blocks, one per core. The same blocks open the archive halfway: only what you touch is decompressed.

The application

Preview of text and images, a tree with search, “Where the space goes”, extraction of just the chosen files, verification and repair, without extracting the archive.

A network volume

tsr serve exposes the archive over HTTP and as a read-only WebDAV volume: it mounts in Finder or File Explorer, and every application opens the files normally.

A folder, on Linux

tsr mount mounts the archive in the filesystem: grep, ffmpeg, an editor or a build open the files without knowing they are compressed, in 189 microseconds per file.

An H.264 film of 2.3 GB inside an archive plays and scrubs with 252 MiB of memory and a 1.6-second seek: in VLC and QuickTime the frame matches the chosen point at every jump, and the file stays compressed the whole time.

Reliability

It comes back identical, on every machine

The same bytes on three architectures

The same input, with the same profile, produces the same archive on Apple Silicon, on x86-64 and on server-class ARM64, with the graphics accelerator on or off. Anyone can verify it with one command on their own machine.

Integrity per block and per file

Every block carries the BLAKE3 fingerprint of its content, and every file its own: verification says which file is damaged and in which block. tsr t --profonda also rebuilds the files taken apart; tsr scrub does the same check slowly, stops and resumes where it was, and can run once a week.

The 1.0 format, frozen

Every archive written by any version is read by all later ones, forever. The format has a specification verified by a reader written from it alone, and 49 test archives read by three independent readers. A reader that meets something it does not know says so, instead of returning wrong bytes.

When the power goes

The program was cut off abruptly 2,752 times at random moments while creating, extending and compacting archives: zero archives lost. On an error or a cancellation the disk stays as it was before the job.

Protection

Encryption and repair

Encrypted whole, names included

With a password the archive is encrypted with XChaCha20-Poly1305, index included: file names, sizes, dates and permissions stay secret. The key comes from the password through Argon2id. Encryption is per block, so preview, streaming and the mounted volume work on encrypted archives too; in the worst measured case it costs two hundredths of a second and 4.2 KB on half a gigabyte.

A wrong password and a tampered archive give two different errors.

It repairs without the password

On request the archive carries 1 to 30% Reed–Solomon parity: damage within the quota, scattered or contiguous, is repaired in full into a new file, and the original stays as it is. Parity covers the physical bytes, so whoever keeps an encrypted archive can repair it without being able to read it.

Reference measurement: 34 MB with 10% parity, 46 damaged fragments out of 8,732 put back in a tenth of a second.

Backups

The second backup costs what changed

A file identical to one already there becomes a reference, even months later when the archive is extended; a block identical to one already written is recalled instead of rewritten. With the backup profile blocks are cut where the content says, so an insertion in the middle of a file does not shift everything else.

Scenarios from a deterministic script, reproducible by anyone; July 2026. Against a dedicated backup tool (restic), the backup profile saves between 97 and 111% of what it saves.
ScenarioTSR7-Zip at maximum
408 MB SQLite database, two versions after twelve changes100.0 MB109.8 MB
A log that grows at the end29.2 MB in 26.2 s35.3 MB in 136.8 s
Disk image changed by mounting it247.1 MB427.6 MB
389.5 MB folder plus its full backup36.6% (the second: 2,190 bytes)74.8%

What it runs on

Three systems

macOS on Apple Silicon, 64-bit Windows 10 and 11, Linux x86-64 and ARM64: a graphical application and a command line, which read the same archives.

The graphics card, if any

Part of the work can run on the GPU (Metal, Vulkan): every result is checked on the CPU, and the archive stays identical byte for byte. On the balanced profile it is 1.4 to 2.9 times faster; tsr gpu-check proves it on your machine.

On servers too

Command line with JSON output, streaming service, daemon with a job queue, C library, .deb and .rpm packages, container images.

TSR for business

Three commands to start

tsr c archive.tsr folder/ -t lento
Compress a folder at the Slow level (lento); -t 300 spends 300 seconds.
tsr t archive.tsr --profonda
Verify everything, also rebuilding the files taken apart (--profonda means deep).
tsr serve archive.tsr
Open the archive as a network volume, on the local interface only.

Try it on your own files

Beta 0.10.2 is free until 31 January 2027. The archives you create open forever, even after the beta ends.