How we test

Most plugin reviews describe a sound. There’s nothing wrong with describing a sound — but you can’t check a description, and a page of adjectives is usually a press release with the serial numbers filed off.

So there’s one rule here, and the site is built so it can’t be broken:

No review describes a plugin nobody on this team installed and measured.

The build enforces that, not our good intentions. A review that doesn’t name the version tested, say how the plugin reached us, cite a rig, and carry three of our own screenshots, two level-matched audio examples and at least one measurement will not compile. There’s no override flag, and we’re not adding one.

What we measure

• Reported versus actual latency. A plugin tells the host how much delay it introduces, and the host compensates by that amount. Sometimes the number is wrong. When it’s wrong your mix is smeared by an amount no ear training will find, because your ears are being handed the smeared version. We measure the real figure at every oversampling setting.
• CPU to first dropout. Not a percentage — that depends on which meter you read and what else the machine was doing. Instances until the audio breaks, at 32, 64, 128, 256 and 512 samples, three runs, one machine, lowest of the three.
• Null tests against the maker’s own claims. If a developer says version 3 is bit-identical to version 2 in a particular mode, that’s a testable sentence. We test it and publish the null depth in dB, whichever way it goes.
• Apple Silicon and Windows-on-ARM status. Native, Rosetta, or unsupported. We went looking for this list, couldn’t find it anywhere, and decided to keep it ourselves.

Every measurement is published with its method beside it, so somebody with the same gear can run it again and tell us we got it wrong. That’s what a number is for.

The bench

A CPU figure from one machine can’t be compared with a figure from another, so every review names the machine it came off. The rigs have IDs and they’re published. When one changes, the reviews taken on the old rig say which rig they were taken on, rather than being quietly folded in with the new ones.

Where a computer helps, and where it doesn’t

We use language models here, and we’d rather tell you exactly how than let you wonder.

They’re allowed to touch anything a human already did: pulling the testable claims out of a manual so we know what to go and test, drafting prose from a finished measurement sheet, turning our own CSVs into tables, copy-editing, alt text.

They never originate a claim about a product. No model writes a sentence about how something sounds, what it does, or how it compares, before a person has installed it and run it.

The test we apply before publishing is blunt: delete every sentence a model wrote. If the substance is still there, it was a tool. If the review goes with it, it was the author, and the review doesn’t go up.

How plugins reach us

Every review says it near the verdict, in plain words: bought, supplied, loaned, or a subscription we pay for ourselves. When a developer gives us a licence we say so on that review — not in a footer, and not on this page. They don’t see it before it goes up, and they get no approval over it.

We don’t sell reviews. A maker can buy bench time, and the results publish whatever they turn out to say.