-
Notifications
You must be signed in to change notification settings - Fork 0
How to add a new analysis
This document describes step by step how to add a new analysis method to the project, in a way that is compatible with the existing architecture, configurable, and optionally visualizable.
The goals are to guarantee:
- objective measurements only (no automatic interpretation),
- full integration into the pipeline,
- results usable by the visualization layer without tight coupling.
YAML Configuration
↓
Registry (identifier → function)
↓
Runner (orchestration)
↓
Analysis Method
↓
AnalysisResult
↓
JSON Export (+ optional visualization)
When adding a new analysis, the following files may be involved:
-
audio_toolkit/analyses/<category>.py→ method implementation -
audio_toolkit/engine/registry.py→ registry API (do not modify) -
audio_toolkit/engine/context.py→ input data structure -
audio_toolkit/engine/results.py→ result structure -
audio_toolkit/engine/runner.py→ execution + visualization trigger -
audio_toolkit/visualization/plots.py→ graph generation (if needed)
The category determines:
- the Python file to modify,
- the key used in the YAML configuration.
Existing categories:
temporalspectraltime_frequencymodulationinformationinter_channelsteganographymeta_analysis
Implement the method in the corresponding file.
def my_analysis(context, params) -> AnalysisResult:
...-
contextmust be treated as immutable -
paramscomes from the configuration (merged defaults + overrides)
- Explicitly validate input parameters
- Process all channels present in
context.audio_data - Never call another analysis method
- Never produce conclusions or automatic labels
-
method: method identifier -
measurements: raw, serializable data -
metrics: derived scalars (optional) -
anomaly_score: optional numeric indicator -
visualization_data: plot-ready data (optional)
- Critical information must always be stored in
measurements -
visualization_datamay be dropped during export - Avoid verdict-style fields (e.g. detected / encoded)
visualization_data must contain only ready-to-plot structures:
- axes
- series
- matrices
No computation should be redone in the visualization layer.
Time Series
visualization_data[channel] = {
"time": t,
"value": y
}Spectrum
visualization_data[channel] = {
"frequencies": freqs,
"magnitudes": mags
}Time-Frequency Representation
visualization_data[channel] = {
"times": times,
"frequencies": freqs,
"matrix": tf
}Each analysis method must be registered to be executable.
Registration is done inside the analysis module itself, by calling register_method(...) at import time:
register_method(
identifier="my_analysis",
category="information",
function=my_analysis,
default_params={...}
)Rules:
-
identifiermust be unique and is used in the YAML configuration. -
categorymust match the configuration section. -
functionmust return anAnalysisResult. -
default_paramsmust be serializable.
Notes:
- Do not edit
engine/registry.py. - Registration relies on module import side effects; the runner imports the
analysespackage at startup.
Without registration, the method cannot be executed.
analyses:
<category>:
enabled: true
methods:
- name: "my_analysis"
params:
...Checklist:
- the method runs without visualization
- the method runs with
visualization.enabled = true - results are present in
results.json - no critical information is lost
| Element | Location |
|---|---|
| Computation | analyses/*.py |
| Activation | registry + YAML |
| Data | AnalysisResult |
| Plots | plots.py via the runner |
This guide defines the contract that every new analysis must respect.