vst-bench-ml: Auditable Dataset Generation for Audio Plugins
Organizations: St. Thomas University
Abstract
Generating datasets with audio plugins requires preserving how each audio observation was produced. vst-bench-ml is a Python package that samples plugin parameters, coordinates rendering through a separately installed host, and records software identities, rendering settings, and output hashes for later verification. A sealed manifest binds this evidence and supports offline integrity checks without loading the plugin. A companion repository provides a sample-free VST3 test plugin, a deterministic offline host, and additional checks linking rendering attempts to recorded outputs. On a pinned macOS arm64 and Python 3.12 stack, functional validation of the pre-release versions reproduced package and host tests. Two runs in fresh processes reproduced the same render-plan hash and all eight expected output hashes, covering four sampled parameter configurations and two fixed MIDI signals; 12 negative cases also passed. Later licensed 0.1.0 release candidates passed producer-run continuous integration and local validation. Version 0.1.1 adds public Git source repositories, package-index installation, and user documentation; a separate release check reproduced the expected plan and output hashes. These checks establish integrity and repeatability within the tested setup; they do not establish portability, scientific suitability, or perceptual quality.
Figures & tables
| Component | Distributed boundary | Rights and evidence boundary |
|---|---|---|
| vst-bench-ml | Python orchestration and offline verification | MIT source; no host, plugin, dataset, audio, model, private research module, or third-party binary. |
| Companion repository | Fixture source, offline host, validation scripts, and expected metadata | MIT source; CC0-1.0 applies only to qualifying sample-free generated fixture outputs. |
| External execution inputs | Separately installed VST3 SDK, lawful plugins, and user-selected data | Not relicensed or redistributed; each use must establish its own compatibility and rights. |
| Layer | Bound fields | Implementation boundary |
|---|---|---|
| Execution | Package version and source hashes, Python/runtime identity, dependency versions, normalization method | Core manifest; companion adds Git commit/tree/dirty state or source-archive manifest/file-list hashes, installed-wheel provenance, lock hash, and native-library identities. |
| Host/plugin | Protocol, host source, build and executable identity, reported plugin path and hash, format, name, vendor, identifier | Host-reported identities bound by core; reset/readback capabilities checked at preflight. Companion adds fixture checks. |
| Plan and observation | Parameter-definition hashes, varied indices, seed derivation, plan hash, MIDI signal names, timestamps, kept records, drop/failure events | Core plan metadata, records, event ledger, and sealed manifest. |
| Attempt evidence | Ordered parameter definitions, MIDI hashes, attempt IDs, trace/record correspondence, readback, reset policy, kept disposition, negative cases | Companion-only evidence and complete ledger for the controlled fixture. |
| Artifact integrity | Relative path, byte count, SHA-256, aggregate hashes, count reconciliation | Core offline verification plus stricter companion validation. |
| Gate | Observed result on pinned stack |
|---|---|
| Package tests | 31 passed; wheel/source build and clean wheel installation passed. |
| Host tests | Four passed (pre-release); fixture and offline runner built externally to the repository. |
| Deterministic workflow | Two fresh processes each rendered and kept eight records from four parameter configurations and two MIDI signals; both reproduced the same expected plan hash and all eight expected output-byte hashes. |
| Negative cases | 12 passed, covering substituted package artifacts, wrong plugin identity, unreachable host, malformed parameters, missing normalization, out-of-range values, reset/readback mismatch, duplicate attempts, corrupted output, and incomplete-ledger evidence. |
| Static quality | Configured Ruff lint checks passed with cache disabled. |
| Reuse path | Requirements | Evidence and limits |
|---|---|---|
| Generate observations | Lawful plugin, compatible host, parameter manifest, pinned environment | Demonstrated with the controlled fixture; other plugins, hosts, and cross-machine output identity are unverified. |
| Verify a core dataset | Manifest, records, drop/failure events, and referenced artifacts | Demonstrated integrity checks; no complete kept-attempt trace or assessment of scientific fitness or perceptual quality. |
| Run companion conformance | Pinned fixture, host trace, package wheel/lock, expected metadata | Demonstrated on the pinned stack; the fixture does not establish representativeness of commercial plugins or musical data. |
| Implement another host | Protocol identity, reset, readback, and render behavior | Proposed extension; each implementation requires compatibility and behavioral validation. |
| Extend quality rules | Explicit thresholds, versions, tests, and provenance | Proposed extension; each rule set requires validation for its intended research task. |
Data Provenance
Data provenance tracks where data and AI outputs come from, how they are transformed, and what evidence supports their attribution and use.
See all 191 papers