How we test

Most plugin reviews describe a sound. We are not against describing sounds, but a description is not checkable, and a page full of adjectives is worth about as much as the press release it was written from.

So the rule here is simple, and the site is built so it cannot be broken:

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

That is enforced by the build, not by good intentions. A review that does not name the version tested, state how the plugin reached us, cite a rig, carry at least three of our own screenshots, at least two level-matched audio examples and at least one measurement will not compile. There is no override flag.

What we measure

These are the numbers nobody else publishes, which is the entire reason this site exists.

• Reported versus actual latency. A plugin reports its delay to the host so the host can compensate. Sometimes the report is wrong, and when it is wrong your mix is smeared in a way no amount of ear training will find. We measure the real figure at every oversampling setting.
• CPU to first dropout. Not a percentage, which depends on the meter you read it from. The number of instances we can run at 32, 64, 128, 256 and 512 samples before audio breaks, three runs, one machine.
• Null tests against the maker’s own claims. If a developer says their new version is bit-identical to the old one in a given mode, that is a testable statement. We test it and publish the null depth in dB, whether it holds or not.
• Apple Silicon and Windows-on-ARM status. Native, Rosetta, or unsupported. No such list exists anywhere else, which tells you how many people have needed one and not found it.

Every measurement is published with its method attached, so somebody with the same gear can repeat it and tell us we are wrong. That is the point of a number.

The bench

Every review names the machine it was tested on, because a CPU figure from one machine is not comparable with a figure from another, and a table that mixes them is worse than no table. The rigs are listed on each review and they do not change silently.

Where a computer helps and where it does not

We use language models in this workflow, and we would rather say exactly how than let you guess.

They are allowed to touch anything derived from what a human already did: pulling the testable claims out of a manual so we know what to test, drafting prose from a completed 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, or what it does, or how it compares, before a human has installed it and run it. The test we apply before publishing is blunt: delete every sentence a model wrote, and if the substance of the review survives, the model was a tool. If the review disappears, it was the author, and it does not go up.

How plugins reach us

Every review states it, near the verdict, in plain English: bought, supplied, loaned, or a subscription we pay for. When a developer gives us a licence we say so on that review, not in a footer somewhere. They do not see the review before it goes up and they have no approval over it.

We do not sell sponsored reviews. If a maker wants bench time they can buy bench time, and the results publish whatever they say.