Skip to main content
Back to About

Transparency

Editorial and testing methodology

The process used to keep published claims aligned with what the tool actually does.

Verification workflow

1. Verify the product

The capability matrix records tested inputs, output formats, controls, observable results, and limitations. Published copy must not expand that scope.

2. Test the change

Changes go through type checking, static analysis, unit tests, and browser flows. Audio operations use controlled files and check duration, samples, peak, or state as appropriate.

3. Review the experience

Essential flows are exercised in desktop and mobile profiles. Emulated tests are not presented as validation on every physical device or browser.

4. Publish with limits

Landing copy, metadata, FAQ, HowTo, and structured data must describe the same behavior. Known limits remain visible and unsupported claims are removed.

A worked example

Describing a process is easy. This is the real path of one claim about cutting, from how it is phrased to what the test checks — and what it deliberately leaves out.

The claim
“Cutting removes exactly the selected range.” Phrased that way it is checkable: there is an expected number of samples in the result.
The test file
A WAV generated by the project, with a known duration and sample rate. A controlled file keeps the source encoding from hiding an arithmetic error.
The check
The test opens the file in a browser, applies the selection, and compares the frame count of the resulting buffer against the expected value. Reversal and gain are checked the same way: reversal must preserve the frame count, and per-channel gain must show up in both the preview and the exported WAV.
What this does not prove
That the result sounds good, or that every browser decodes the same input file. Sample accuracy and codec compatibility are different things, and only the first is tested this way.

Editorial rules

  • Separate general audio concepts from features available in the editor.
  • Use reproducible tests for product behavior and primary sources for external concepts where applicable.
  • Write EN and PT-BR independently for meaning and natural phrasing rather than word-for-word translation.
  • Identify the responsible person, review date, method, and limitations in technical articles.
  • Correct content when the product changes or a statement can no longer be reproduced.

Product evidence

Repository tests and controlled audio files.

External sources

Official documentation, standards, and primary technical sources.

Corrections

Material changes are recorded in the changelog; issues can be submitted through Contact.

Last reviewed: 29 August 2026.