Task: Investigate the inverse decoder: audio → VoiceScenario
Investigate the inverse decoder: audio → VoiceScenario
Verify whether generator scenarios can be automatically reconstructed from recorded audio, first using our own synthetic examples with a known ground truth, and then on human speech.
Goal
Test the hypothesis of the practical reversibility of our parametric model:
VoiceScenario → generator → audio
and vice versa:
audio → decoder → VoiceScenario.
Key verification principle
Start not with human speech, but with our own scenarios where the correct answer is known in advance.
For a scenario S:
S → G(S) = X
then:
X → D(X) = S'
The first rigorous criterion:
if the decoder is unable to reliably reconstruct the original scenarios from the audio created by our own generator, speaking of decoding real speech is premature.
Verification must be performed on the entire available set of different scenarios, rather than on a single successful case.
Stage 1. Synthetic ground truth
Gather a set of existing and new scenarios:
- sustained vocal sounds;
- noise;
- plosives;
- transitions;
- syllables/fragments;
- short words.
For each, store:
- original JSON;
- exact generated audio;
- detailed analytical log;
- decoder result;
- differences between the original and reconstructed scenario;
- result of re-synthesis from the reconstructed scenario.
We need to understand which parameters are restored reliably, which are ambiguous, and what log resolution is necessary.
Stage 2. Re-synthesis verification
It is not enough to get a similar JSON. The reconstructed scenario must be played back again:
S → X → D(X)=S' → G(S')=X'
And compare:
- scenario structure;
- analytical features of
XandX'; - human auditory perception.
Stage 3. Transfer to human speech
Only after stable performance on our own synthetic data should we move on to recording a human.
The goal here is no longer necessarily to reconstruct some "true" physical human scenario, which we do not have. Practical criterion:
the decoder creates a
VoiceScenariowhich, when played back, produces a recognizable and sufficiently close human sound.
Main open question
To what extent the space of human speech is covered by the current audio space of our generator.
AudioContext is technically capable of reproducing any digital waveform if given a full array of samples. But our system intentionally replaces thousands of samples with a compact structural description.
Therefore, we are investigating not the possibility of reproduction in general, but the boundary:
what is the minimum complexity of the structural representation sufficient for an acceptable quality of human speech?
Potential model evolution
If the current VoiceScenario is not enough, do not consider this an automatic refutation of the approach. Explore a gradual increase in expressiveness:
- richer source model;
- additional resonances/anti-resonances;
- turbulence/noise;
- local spectral details;
- denser temporal control points;
- short residual components if necessary.
Ultimately, the representation can approach a waveform. The practical goal is to find the point where the quality is already sufficient, while the description is still significantly more compact and structural than an array of samples.
Connection with the editor
Even an imperfect decoder can be useful if it produces a good draft scenario:
recording → draft VoiceScenario → visual editor/AI → human refines by ear.
Success criteria
- The decoder reliably restores its own scenarios at least on a limited set of sound classes.
- Re-synthesis from the restored scenario is perceptually close to the original synthetic sound.
- It is clear what data is lost during the current analysis and whether log compression needs to be reduced.
- On real recordings, at least useful starting scenarios are obtained.
- It is possible to estimate the dependency
quality ↔ complexity/representation sizeand approach the practical boundary of the system.
Ворклоги
Progress on Visualization and Inverse Decoding
The semantics of VoiceScenario have been re-verified against the actual implementation of synthesizeScenario.
What was confirmed
animate.tois NOT reset afterdurationends. Upon completion of the automation,state[param] = to, the automation itself is removed, but the new value remains active until the next command.setalso changes the state permanently until the parameter is changed again.- A new
animatestarts from the actual current value of the parameter at the moment of the command. - For an array of scenarios,
initialis used only for the first scenario; subsequent ones continue the current state without a reset.
Identified Visualizer Issue
The old ScenarioVisualizer only displayed active sections of animate, which made the original scenario look visually "jagged". This did not correspond to the actual state of the synthesizer.
The visualizer has been redesigned to display the full VoiceControlState(t): values run continuously from the beginning to the end of the scenario, including holding the last to after duration ends, set, interruption of old automations, and the continuation of the state between compound scenarios.
Architectural Conclusion
The scenario execution logic (prepareScenario, evaluateBezier, updateAutomations, executeCommand) must not be duplicated between the synthesizer and the visualizer. A separate task has been created to extract a common runtime module so that the DSP and the visualizer use the same state machine.
Conclusion on the Current Decoder
Even after fixing the visualization, it is clear that the current log and scenario are at different representation levels. The scenario contains control parameters, while the log contains observable acoustic features. A direct correspondence such as RMS -> sourceLevel, dominantFrequency -> f0Hz, etc., is generally incorrect.
It was also confirmed that the original scenario has significantly more control parameters than the current log of acoustic metrics, so the reversibility of Scenario -> Sound -> Log -> Scenario is physically underdetermined in the current architecture.