Speed · measured, not claimed
The number that decides whether a night goes well is not how long the first write of a drive takes — that happens at home, once — but how long adding a track to it takes at five to midnight. rekordbox users report hours. These are Booth's figures, taken by the test suite and republished with every measurement, so the claim is a number with a date on it.
Loading the last measurement…
Every row is one drive: written from nothing, then written again with nothing changed but the databases, then written once more with one track added, then read back the way the dock reads a stick that has just been plugged in — both databases walked, every analysis file checked, every track's cues and grid read.
| Tracks on the drive | First write | of which preparing | Databases alone | Add one track | Read it all back | Analysis files |
|---|---|---|---|---|---|---|
| No measurement has been published yet. | ||||||
Preparing is decoding a record and listening to it — tempo, grid, key, phrases, cues, waveforms — and it scales with how long the records are. The records here are short on purpose, so that the drive is what is being timed; a real record takes longer to listen to and exactly as long to put on the stick. Databases alone is a write that changes nothing but the two databases: a playlist reordered, a track taken off. Add one track is a full drive carried as it is, one file prepared, both databases rebuilt and read back.
The medium these were taken on is named above the table. A runner's disk is not a USB stick, and a stick's small-file write speed is the thing rekordbox's own forum blames most. The figure that counts is the one taken on a real stick — here is how to take it.
rekordbox's Sync overwrites the whole data set on the stick every time, so adding one track costs what writing the drive cost. These are not benchmarks of rekordbox — nobody publishes those — but what DJs reported on AlphaTheta's own forum, with the threads linked so the comparison can be checked.
Two things make the difference, and neither is clever. A second write carries every row the drive already has and prepares only what changed, so the cost of adding a track is the cost of one track. And both databases are built from one description of the drive and written in one pass, so there is no reconciliation step and nothing to re-walk — the read-back afterwards is a check, not a repair.
The measurement is a test —
proto/musicai/tests/speed.rs
— that builds drives of several sizes from synthetic records, times each phase with a wall
clock around the same calls the window makes, and writes what it saw to
speed.json. This page reads that file; nothing on it is
typed in by hand.
A smaller version of the same test runs with every build and makes the structural claim by counting rather than timing: adding one track to a drive copies that one track and nothing the drive already has, and rewriting the databases copies nothing. A timing would depend on the machine — the first write prepares its tracks in parallel and the second prepares one, so the more cores, the closer the two times come — and a count does not.
The speed workflow takes the published measurement on a GitHub-hosted runner whenever the code that writes a drive changes, and once a week so the date never goes stale. Its disk is a fast one and not a stick, which is why the medium is printed beside the numbers.
Point the same test at a mounted drive and it measures that drive. The result is the same file this page reads, so committing it publishes it.
scripts/speed.sh /Volumes/STICK # macOS scripts/speed.sh /media/$USER/STICK # Linux BOOTH_SPEED_SIZES=50,500 scripts/speed.sh /Volumes/STICK
It is a release build and several minutes of writing drives. Everything it writes goes under
a booth-speed-N folder on the drive and is removed afterwards; nothing already on
the stick is touched.