Stability and Reproducibility

DecayCore is designed to avoid the classic failure mode:

small measurement or setting changes -> large unstable filter changes

The system stays predictable because it is deterministic, bounded, and observable.

1) Deterministic pipeline and versioned behavior

Given the same:

DecayCore produces repeatable outputs.

The pipeline keeps its behavior deterministic for fixed inputs and settings. Automatic mode may use seeded Optuna-backed search, but the seed is derived deterministically from the measurement/signature context so identical runs remain reproducible. Current releases keep this deterministic model while retaining smarter cache reuse around automatic-mode target and preset search.

2) Input robustness: TXT and WAV/IR

Modern workflows mix REW text exports and WAV/IR measurements.

Stability improvements include:

This reduces source-format-dependent surprises.

3) Bounded correction prevents inverse-filter runaway

DecayCore keeps each stage bounded:

Magnitude bounds:

Shape bounds:

Decay bounds:

When limits are active, behavior remains controlled instead of extreme.

4) Confidence-guided correction improves repeatability

Room data confidence is frequency-dependent. DecayCore uses confidence-aware behavior to avoid overreacting to artifacts:

Practical effect: small mic-position changes usually alter details, not the whole correction profile.

5) Phase-domain safeguards

Phase processing is constrained by design:

These controls prevent unstable phase behavior and reduce ringing risk.

6) Headroom reproducibility and stereo consistency

Level handling is deterministic and tied to realized correction:

This keeps output gain decisions consistent across repeated runs.

7) Comparable evaluation across fs/taps

Changing fs/taps can change analysis grids even when audible behavior is similar. DecayCore addresses this with:

So you can compare settings more fairly without grid-induced score drift.

8) Observability and audit trail

Reproducibility needs traceability. DecayCore provides:

If two runs differ, diagnostics help explain why.


Reproducible-run checklist

  1. Use the same single pinned app version.
  2. Use identical measurement sources and source type (TXT vs WAV) per comparison.
  3. Keep base fs/taps fixed, or enable comparison mode.
  4. Keep correction guardrails fixed (boost/cut/slope/regularization/phase limit).
  5. Keep phase strategy fixed.
  6. Keep headroom margin and stereo-link policy fixed.
  7. Verify System Health is clean before exporting.
  8. Compare Summary outputs and timing data when validating repeated runs.

Bottom line: DecayCore is reproducible because correction strength is bounded, phase is safety-limited, and the full run is observable end-to-end.

Disclaimer

AI was used to translate this document from Finnish to English.