Теоретическая основа проекта собрана в главном концепте [«учиться-легко.рф — обучение чтению как дешифровке письменного кода»](/concepts/uchitsya-legko-rf-obuchenie-chteniyu-kak-deshifrovke-pismennogo-koda). Он является центральной точкой проекта: описывает общую модель, текущее состояние и связывает частные концепты.

Сейчас проект находится на стадии **Idea**. Сформирована базовая теория чтения как восстановления информации по письменному коду. Зафиксированы информационные сущности, на которых строится обучение: объект и ситуация, понятие, изображение, устное слово, звучание, написанное слово, буквы и более крупные структурные части слова.

Ключевые составляющие теории:

- [Чтение — это распознавание слова и восстановление смысла, а не последовательное озвучивание букв](/concepts/chtenie-eto-raspoznavanie-slova-i-vosstanovlenie-smysla).
- [Письменное слово связывает несколько представлений одного и того же содержания](/concepts/pismennoe-slovo-svyazyvaet-neskolko-predstavleniy).
- [Обучение чтению должно идти от известных опор к неизвестному коду](/concepts/obuchenie-chteniyu-ot-izvestnyh-opor-k-neizvestnomu-kodu).
- [Устный словарь — база распознавания при обучении чтению](/concepts/ustnyy-slovar-baza-raspoznavaniya-pri-obuchenii-chteniyu).
- [Длинное слово должно раскрываться через знакомые структурные части](/concepts/dlinnoe-slovo-cherez-znakomye-strukturnye-chasti).
- [Подсказки должны постепенно исчезать по мере освоения связей](/concepts/podskazki-dolzhny-postepenno-ischezat).

Практическое направление — интерактивная система, в которой ребёнок начинает с узнаваемых объектов и слов, подтверждает их звучание, знакомится с написанием, обнаруживает повторяющиеся элементы письменного кода и затем применяет найденные соответствия для дешифровки новых слов.

Критический принцип: система не должна одновременно требовать освоения нескольких неизвестных уровней. Если ребёнок не знает понятие, устное слово, его звучание и буквы, такое слово плохо подходит как начальный материал. Следующее задание должно опираться на уже подтверждённые знания конкретного ребёнка.

Следующий этап проекта — превратить теорию в минимальную интерактивную механику и проверить главный критерий: способен ли ребёнок переносить освоенные соответствия на ранее не встречавшиеся слова, а не только запоминать показанные примеры.

Интерактивный проект обучения чтению как постепенной дешифровке письменного кода через уже знакомые ребёнку смыслы, изображения и звучащие слова.

учиться-легко.рф

## Цель

Найти и изучить существующие технические реализации качественного программного синтеза человеческого голоса в браузере или в близком к браузерному стеку.

Нас интересует не обычный TTS и не воспроизведение готовых аудиозаписей, а процедурный/параметрический синтез, где звук формируется программно и может управляться на низком уровне.

## Связь с основной задачей

Родительская задача — [исследование универсального параметрического синтеза русских звуков и переходов](/tasks/cmtzfmwqs07rwqw0q6l7d5izg).

Эта задача должна проверить техническую реализуемость ключевой части гипотезы до дальнейшего усложнения основной архитектуры.

## Что искать

Нужны реальные работающие примеры, а не только теоретические описания:

- браузерные синтезаторы речи на Web Audio / AudioWorklet / WASM;
- формантный, артикуляционный, physical-model и другие DSP-подходы;
- проекты, способные воспроизводить хотя бы несколько слогов или коротких речевых фрагментов;
- проекты, где можно увидеть код и понять, за счёт каких параметров получается звук;
- решения без жёсткой привязки ядра к конкретному алфавиту, языку или таблице букв;
- механизмы, допускающие непрерывное управление звуком и переходами.

## Ключевой вопрос

Существует ли практически применимая техническая реализация, которая показывает, что качественную человеческую речь можно программно воспроизводить из компактного управляемого набора параметров, а не из записанного waveform или закрытой нейросетевой модели?

Особенно важно понять, существует ли обратный путь: можно ли взять конкретный реальный звук, автоматически определить параметры такого генератора и затем воспроизвести этот звук обратно.

## Что не считать решением

- Web Speech API и другие готовые TTS API;
- neural voice cloning без доступного управляемого внутреннего представления;
- словари заранее записанных звуков;
- системы, где ядро основано на заранее заданных буквенных/фонемных пресетах и не решает универсальную задачу;
- демонстрации отдельных гласных без возможности показать качественные переходы или короткую речь.

## Результат исследования

Нужно получить одно из двух:

1. Найти хотя бы один воспроизводимый технический кейс, который можно изучить и использовать как ориентир архитектуры.
2. Если такого кейса найти не удаётся — зафиксировать, какие части задачи закрывают существующие проекты, чего именно в них не хватает и почему оставшаяся часть является отдельной сложной инженерной задачей.

Найти и изучить браузерные проекты и DSP-подходы, которые программно воспроизводят хотя бы несколько человеческих слогов или голосовых звуков с высоким качеством, без генеративного TTS и без привязки ядра к буквам/слогам.

Исследовать качественный программный синтез человеческого голоса в браузере

## Цель

Сделать визуальный редактор сценариев синтезатора, чтобы перестать править код ради каждой итерации и перенести работу на уровень самих `VoiceScenario`.

## Что должен уметь редактор

- загрузить существующий JSON сценария;
- создать сценарий с нуля;
- редактировать начальное состояние;
- редактировать команды общей timeline (`set`, `animate` и другие поддерживаемые операции);
- менять длительности, уровни, частоты, шумовые параметры, резонансы и другие доступные параметры;
- проигрывать результат сразу после изменения;
- сохранять и экспортировать изменённый JSON;
- быстро переключаться между вариантами.

## Человек как perceptual validator

Качество результата пока надёжнее всего оценивает человек на слух. Поэтому редактор должен минимизировать цикл:

`изменить параметры → проиграть → услышать результат → изменить снова`.

Цель — убрать из этого цикла обязательное редактирование исходного кода ИИ.

## Автоматизация через ИИ-агента

Следующий слой редактора:

1. человек загружает/записывает эталонный звук;
2. система получает его аналитический лог;
3. проигрывается текущий `VoiceScenario` и строится его лог;
4. по кнопке оба лога вместе с текущим JSON отправляются ИИ-агенту;
5. агент сравнивает их и возвращает изменённый JSON сценария;
6. редактор применяет вариант;
7. человек проверяет его на слух.

ИИ здесь не является финальным судьёй качества — он помогает искать изменения в структурированном пространстве параметров, а человек остаётся проверяющим perceptual quality.

## Отдельно проверить качество логов

Есть гипотеза, что текущие аналитические логи слишком сильно сжаты и теряют признаки, которые человек слышит. Нужно иметь возможность увеличивать разрешение анализа и сравнить, улучшает ли это способность ИИ предлагать полезные изменения.

## Важный режим исследования

Не выбрасывать случайно найденные полезные звуки.

Если при поиске `Ха` получается узнаваемое `Ва` или другой нужный голосовой фрагмент:

- сохранить сценарий как отдельный результат;
- сохранить исходный и изменённый варианты;
- зафиксировать, какие изменения параметров привели к переходу;
- использовать это как знание о структуре параметрического пространства.

## Критерий результата

Редактор должен сделать итерации над звуком существенно дешевле: человек способен самостоятельно менять и проверять сценарии, а ИИ работает с JSON/логами вместо постоянного изменения кода.

Ускорить ручной поиск качественных звуков: редактировать сценарии визуально, проигрывать сразу и уметь отправлять эталонный и синтетический логи ИИ-агенту для возврата изменённого JSON.

Сделать визуальный редактор VoiceScenario и цикл человек ↔ ИИ

## Цель

Проверить гипотезу о практической обратимости нашей параметрической модели:

`VoiceScenario → генератор → звук`

и обратно:

`звук → дешифратор → VoiceScenario`.

## Ключевой принцип проверки

Начинать не с человеческой речи, а с собственных сценариев, где правильный ответ заранее известен.

Для сценария `S`:

`S → G(S) = X`

затем:

`X → D(X) = S'`

Первый строгий критерий:

> если дешифратор не способен стабильно восстанавливать исходные сценарии из звуков, которые создал наш собственный генератор, говорить о дешифровке реальной речи преждевременно.

Проверять нужно на всём доступном наборе разных сценариев, а не на одном удачном кейсе.

## Этап 1. Синтетический ground truth

Собрать набор существующих и новых сценариев:

- устойчивые голосовые звуки;
- шумовые;
- взрывные;
- переходы;
- слоги/фрагменты;
- короткие слова.

Для каждого хранить:

- исходный JSON;
- точный сгенерированный звук;
- подробный аналитический лог;
- результат дешифратора;
- различия между исходным и восстановленным сценарием;
- результат повторного синтеза из восстановленного сценария.

Нужно понять, какие параметры восстанавливаются устойчиво, какие неоднозначны и какое разрешение логов необходимо.

## Этап 2. Проверка повторного синтеза

Недостаточно получить похожий JSON. Восстановленный сценарий нужно снова проиграть:

`S → X → D(X)=S' → G(S')=X'`

И сравнить:

- структуру сценариев;
- аналитические признаки `X` и `X'`;
- восприятие человеком на слух.

## Этап 3. Перенос на человеческую речь

Только после стабильной работы на собственных синтетических данных перейти к записи человека.

Цель здесь уже не обязательно восстановить некий «истинный» физический сценарий человека, которого у нас нет. Практический критерий:

> дешифратор создаёт такой `VoiceScenario`, который при воспроизведении даёт узнаваемый и достаточно близкий человеческий звук.

## Главный открытый вопрос

Насколько пространство человеческой речи покрывается текущим пространством звуков нашего генератора.

`AudioContext` технически способен воспроизвести любой цифровой waveform, если дать ему полный массив отсчётов. Но наша система намеренно заменяет тысячи отсчётов компактным структурным описанием.

Поэтому исследуем не возможность воспроизведения вообще, а границу:

> **какая минимальная сложность структурного представления достаточна для приемлемого качества человеческой речи?**

## Возможное развитие модели

Если текущего `VoiceScenario` недостаточно, не считать это автоматическим опровержением подхода. Исследовать постепенное увеличение выразительности:

- более богатый source model;
- дополнительные резонансы/антирезонансы;
- turbulence/noise;
- локальные спектральные детали;
- более плотные временные управляющие точки;
- при необходимости короткие residual-компоненты.

В пределе представление может приближаться к waveform. Практическая цель — найти точку, где качество уже достаточно, а описание всё ещё существенно компактнее и структурнее массива samples.

## Связь с редактором

Даже несовершенный дешифратор может быть полезен, если выдаёт хороший черновой сценарий:

`запись → черновой VoiceScenario → визуальный редактор/ИИ → человек доводит на слух`.

## Критерии успеха

1. Дешифратор устойчиво восстанавливает собственные сценарии хотя бы на ограниченном наборе классов звука.
2. Повторный синтез из восстановленного сценария perceptually близок к исходному синтетическому звуку.
3. Понятно, какие данные теряются при текущем анализе и нужно ли уменьшать сжатие логов.
4. На реальных записях получаются хотя бы полезные стартовые сценарии.
5. Можно оценить зависимость `качество ↔ сложность/размер представления` и приблизиться к практической границе системы.

Проверить, можно ли автоматически восстанавливать сценарий генератора из записанного звука, сначала на собственных синтетических примерах с известным ground truth, затем на человеческой речи.

Исследовать обратный дешифратор: звук → VoiceScenario

## Цель

Исследовать не мгновенное соответствие вида `parameter[t] -> sample[t]`, а временную причинность в цепочке:

`VoiceControlState(t) -> внутреннее DSP-состояние -> PCM -> акустические признаки на временном окне`.

Нужно понять, **какой управляющий параметр на что реально влияет**, через какое время это влияние проявляется, как долго сохраняется и какие наблюдаемые признаки позволяют его восстановить.

Это необходимо для корректного обратного декодирования `Sound -> VoiceScenario`.

---

## Контекст и проблема

Текущий `VoiceScenario` задаёт управляющие параметры, но выходной PCM формируется динамической системой с внутренним состоянием:

- `voicePhase`;
- `resonator1.low`, `resonator1.band`;
- `resonator2.low`, `resonator2.band`;
- `resonator3.low`, `resonator3.band`;
- состоянием PRNG;
- активными automation.

Поэтому даже постоянные управляющие параметры дают сложный, высокочастотный waveform.

Примеры:

- постоянный `f0Hz` не означает постоянный waveform — он задаёт скорость вращения `voicePhase`;
- постоянный `noiseLevel` управляет амплитудой случайного источника, который меняется каждый sample;
- постоянные `resonance*` управляют stateful-фильтрами, внутреннее состояние которых меняется каждый sample;
- наблюдаемые признаки (`RMS`, `spectralFlatness`, `dominantFrequency` и т.д.) зависят сразу от нескольких управляющих параметров и истории DSP.

Следовательно, прямые эвристики типа:

`RMS -> sourceLevel`

`dominantFrequency -> f0Hz`

не являются корректной моделью обратного преобразования.

---

## Основная гипотеза

Для речи и данного синтезатора нужно анализировать **не отдельный sample и не отдельный лог-фрейм**, а временное окно.

Вместо:

`parameter[t] -> sample[t]`

исследовать:

`parameter trajectory[t0:t1] -> audio response[t0:t1+Δ]`

где `Δ` — возможный лаг реакции и/или время затухания внутреннего DSP-состояния.

Рабочие масштабы окон для проверки:

- 5 ms;
- 10 ms;
- 20 ms;
- 30 ms;
- 50 ms;
- при необходимости 100 ms.

Для каждого параметра нужно определить, на каком масштабе времени его влияние наблюдается наиболее устойчиво.

---

## Что исследовать для каждого VoiceControlState-параметра

Минимально:

- `sourceLevel`
- `periodicity`
- `noiseLevel`
- `f0Hz`
- `glottalOpenPhase`
- `glottalReturnPhase`
- `resonance1Freq`
- `resonance1Bandwidth`
- `resonance1Gain`
- `resonance2Freq`
- `resonance2Bandwidth`
- `resonance2Gain`
- `resonance3Freq`
- `resonance3Bandwidth`
- `resonance3Gain`
- `outputLevel`

Для каждого параметра определить:

1. **Чувствительность** — насколько сильно его изменение влияет на PCM и признаки.
2. **Лаг** — через сколько времени после изменения control это влияние становится наблюдаемым.
3. **Время затухания** — сколько сохраняется эффект после изменения параметра.
4. **Локальность** — влияет ли параметр в основном на конкретный диапазон спектра/временную характеристику или глобально.
5. **Однозначность** — можно ли по наблюдаемому эффекту отличить изменение этого параметра от изменения другого.
6. **Взаимодействия** — какие пары параметров дают неаддитивный эффект.

---

## Эксперимент 1: одиночный parameter sweep

Для каждого параметра:

1. Зафиксировать все остальные параметры в одном baseline-состоянии.
2. Изменять только исследуемый параметр по сетке значений.
3. Для каждого значения синтезировать одинаковый по длительности PCM.
4. Собирать одновременно:
   - полный `VoiceControlState(t)`;
   - внутренний DSP trace;
   - PCM;
   - акустические признаки по окнам.
5. Сравнивать результат с baseline.

Пример для `f0Hz`:

- 80 Hz
- 100 Hz
- 120 Hz
- 150 Hz
- 180 Hz
- 220 Hz
- 300 Hz

Пример для `resonance1Freq`:

- фиксировать source и остальные резонаторы;
- двигать только `resonance1Freq`;
- смотреть, какой спектральный пик реально перемещается и как.

---

## Эксперимент 2: ступенчатое изменение во времени

Проверить динамический отклик системы.

Пример:

`t < 100 ms: resonance1Freq = 600`

`t >= 100 ms: resonance1Freq = 800`

Анализировать окна:

- 60–80 ms
- 80–100 ms
- 100–120 ms
- 120–140 ms
- 140–160 ms
- 160–200 ms

Цель:

- определить момент начала наблюдаемого изменения;
- измерить лаг;
- понять форму переходного процесса;
- измерить время стабилизации.

Повторить для остальных параметров.

---

## Эксперимент 3: импульсное/кратковременное возмущение

Для stateful-параметров особенно важно измерить память системы.

Схема:

`baseline -> parameter + δ на короткий интервал -> baseline`

Например:

- 100 ms baseline;
- 10–20 ms изменение;
- возврат к baseline;
- наблюдение ещё 100–200 ms.

Измерить:

- насколько быстро появляется эффект;
- сохраняется ли он после возврата параметра;
- сколько времени DSP возвращается к исходному состоянию.

Для резонаторов это должно показать реальную длительность памяти `low/band` состояний.

---

## Эксперимент 4: пары параметров

После одиночных sweep проверить взаимодействия минимум для наиболее связанных пар:

- `sourceLevel × outputLevel`
- `periodicity × noiseLevel`
- `f0Hz × glottalOpenPhase`
- `f0Hz × glottalReturnPhase`
- `resonanceFreq × resonanceGain`
- `resonanceFreq × resonanceBandwidth`
- `sourceLevel × resonanceGain`

Цель — понять, можно ли считать эффекты параметров независимыми или их нужно восстанавливать совместно.

---

## Какие данные логировать

### Управляющий уровень

- все значения `VoiceControlState(t)`;
- активные automation;
- момент каждой команды `set` / `animate`.

### Внутренний DSP trace

Минимально:

- `voicePhase`;
- `periodicSource`;
- `noiseSource`;
- `excitation`;
- `resonator1.low` / `resonator1.band`;
- `resonator2.low` / `resonator2.band`;
- `resonator3.low` / `resonator3.band`;
- отдельный выход каждого резонатора до суммирования;
- `value` до clamp;
- `value` после clamp.

### Акустические признаки по окнам

Минимально:

- RMS / energy;
- zero crossing rate;
- autocorrelation;
- pitch estimate;
- periodicity estimate;
- spectral centroid;
- spectral flatness;
- спектральные пики;
- энергия по диапазонам;
- формантоподобные пики / спектральная огибающая;
- при необходимости LPC.

Важно: `dominantFrequency` рассматривать только как один из спектральных признаков, а не как прямой `f0Hz`.

---

## Временные окна и частота логирования

Нужно отдельно проверить влияние throttling.

Текущий лог может скрывать значимую временную структуру. Поэтому для исследования желательно иметь максимально частый внутренний trace, а затем уже программно агрегировать его в окна.

Рекомендуемый подход:

- DSP trace — максимально близко к sample-level либо с контролируемым decimation;
- акустические признаки — вычислять по окнам 5/10/20/30/50 ms;
- overlap окон: 50–75% для плавного временного анализа;
- не смешивать частоту сбора данных и размер аналитического окна.

---

## Что должно получиться

Построить экспериментальную карту:

`VoiceControl parameter -> observable consequences`

Для каждого параметра зафиксировать:

- какие признаки реагируют;
- направление реакции;
- масштаб реакции;
- лаг;
- длительность памяти;
- зависимость от других параметров;
- насколько параметр восстанавливаем из аудио.

Желательно оформить это в таблицу вида:

| Control | Наблюдаемые признаки | Лаг | Окно | Однозначность | Комментарий |
|---|---|---:|---:|---|---|
| f0Hz | autocorrelation peak, harmonic spacing | ... | ... | высокая/средняя/... | ... |
| resonance1Freq | spectral envelope / peak shift | ... | ... | ... | ... |
| ... | ... | ... | ... | ... | ... |

---

## Критерий результата

После исследования должно стать понятно:

1. Какие параметры `VoiceControlState` можно восстанавливать непосредственно из аудио.
2. Какие можно восстанавливать только совместно с другими параметрами.
3. Какие параметры текущим набором признаков вообще не наблюдаются.
4. Какие дополнительные признаки нужно добавить в логгер.
5. Какой временной контекст нужен decoder'у для каждого класса параметров.
6. Можно ли строить decoder как аналитическое/эвристическое преобразование или нужен оптимизационный/обучаемый подход.

Главный результат — не просто новый decoder, а **физически и экспериментально подтверждённая модель соответствия между управляющим пространством синтезатора и наблюдаемым звуком во времени**.

Построить экспериментальную карту того, как изменения управляющих параметров во времени проявляются в PCM и акустических признаках с учётом лагов и памяти DSP.

Исследовать временную причинность VoiceControlState → DSP → акустические признаки

## Цель

Создать новый визуальный интерфейс не для косметического редактирования уже готового `VoiceScenario`, а как **экспериментальную лабораторию синтеза речи**.

Основная задача интерфейса — дать возможность вручную исследовать:

- какие параметры синтезатора;
- в какой последовательности;
- в какие моменты времени;
- с какими значениями и законами изменения

дают тот или иной слышимый результат.

Мы заранее НЕ предполагаем, что знаем правильный сценарий для конкретного звука. Интерфейс нужен именно для поиска: пользователь двигает временные точки и параметры, слушает результат, а найденные интересные звучания затем можно сохранять и отдавать вместе с логами/сценарием на последующий анализ.

---

## Общая модель интерфейса

Интерфейс должен быть организован как многодорожечная временная диаграмма, логически похожая одновременно на:

- automation lanes в DAW;
- keyframe editor;
- диаграмму Ганта только в смысле общей временной оси и синхронизации событий.

Это НЕ классический Gantt и не список `set/animate` команд.

### Координаты

Для каждой дорожки:

- горизонтальная ось = время;
- вертикальная ось = значение параметра;
- параметр задаётся набором редактируемых точек `(time, value)`;
- точку можно перетаскивать горизонтально, меняя момент события;
- точку можно перетаскивать вертикально, меняя значение;
- между точками задаётся закон перехода.

UI может нормализовать вертикальную шкалу к `0..1`, но физическое значение параметра должно сохранять собственный диапазон и единицы (`Hz`, gain и т.п.).

---

## Отдельная общая длительность звучания

Нужен независимый параметр **общей длительности сценария**.

Это принципиально: управляющие параметры могут быть выставлены или изменены только в начале, но полученное состояние должно продолжать звучать долго.

Примеры смысловой модели:

- коротко выставили состояние и держим длинное `ААААА`;
- ранние события формируют `МА`, а затем состояние долго удерживает `ААААААА`;
- после последней keyframe-точки значение каждого control продолжает удерживаться до общей длительности сценария.

Длительность не должна автоматически обрезаться по последней управляющей точке.

---

## Циклическое воспроизведение

Обязательно предусмотреть переключатель **«Циклично»**.

В циклическом режиме:

- сценарий проигрывается снова сразу после окончания;
- пользователю не нужно каждый раз нажимать Play;
- изменения параметров/точек должны попадать в следующий цикл воспроизведения;
- пользователь может двигать точку или значение и за несколько повторов подряд услышать несколько вариантов результата.

Это ключевой режим именно для ручного поиска звучаний.

---

## Дорожки параметров

На первом этапе редактор должен работать со всеми существующими параметрами `VoiceControlState`.

Для каждой дорожки нужно видеть:

- имя control;
- его физическое значение;
- нормализованное положение в вертикальной шкале;
- keyframe-точки;
- удержание значения между событиями;
- форму перехода между точками.

Редактор должен показывать фактическую временную траекторию параметра, а не только активные участки `animate`.

---

## Типы переходов и преобразователей

Архитектуру сразу проектировать так, чтобы между точками существовал не только один вид `animate`.

Нужна расширяемая модель **преобразователя/модулятора** временного участка.

Минимально предусмотреть возможность в дальнейшем иметь разные типы:

- hold / постоянное значение;
- linear transition;
- bezier transition;
- периодический модуль;
- синусоидальная модуляция по формуле;
- импульс / burst;
- повторяющееся биение;
- шумовая или иная стохастическая модуляция;
- другие функции времени.

То есть на временную ленту в перспективе должен помещаться не только keyframe, но и **преобразователь**, который на заданном интервале формирует сложную траекторию параметра.

Пример смысла: параметр может иметь стабильную базу, но поверх неё на участке времени работает периодическая модуляция.

---

## Связь с физиологией речи

Архитектуру редактора нельзя проектировать так, будто каждый control полностью независим физически.

У человека один речевой аппарат:

- один язык;
- одна конфигурация губ;
- один рот/ротовая полость;
- один голосовой тракт;
- одна система голосовых связок и воздушного потока.

Нельзя одновременно задать взаимоисключающие артикуляционные состояния так, словно существуют два независимых языка или две независимые формы рта.

Пока текущий DSP работает в акустическом пространстве (`f0`, periodicity, noise, resonances, gains и т.д.), но редактор должен быть спроектирован так, чтобы в будущем можно было вводить **связанные физиологические/артикуляционные преобразователи**, которые управляют сразу несколькими DSP controls согласованно.

Примеры смысловых преобразователей, которые могут появиться позже:

- открытие/закрытие рта;
- изменение положения языка;
- накопление и release давления;
- краткий взрывной burst;
- устойчивый поток воздуха;
- дрожание/биение артикулятора для `Р`;
- переход между артикуляционными состояниями.

Важно: это не требование немедленно реализовать полноценную физиологическую модель. Требование — **не закрыть архитектурой такую возможность**.

---

## Особый смысл временной структуры

Редактор должен исходить из того, что звук имеет смысл только во времени.

Например, взрывной согласный — это не одно значение параметра, а последовательность фаз:

- подготовка/закрытие;
- накопление;
- release;
- burst;
- шумовой или голосовой хвост;
- переход в следующий звук.

А устойчивый звук может быть результатом стабильного состояния, которое после короткого входного перехода удерживается долго.

Поэтому пользователь должен видеть и редактировать **композицию фаз во времени**, а не только список чисел.

---

## Что сохранять

Найденный эксперимент должен быть воспроизводимым.

Нужно уметь сохранить:

- общую длительность;
- все дорожки и keyframes;
- типы переходов/преобразователей;
- их параметры;
- итоговый `VoiceScenario` или компилируемое представление;
- при необходимости метаданные эксперимента.

Существующий `VoiceScenario` можно использовать как runtime/формат исполнения, но UI не должен быть ограничен его текущей command-centric формой. Допустим отдельный экспериментальный/keyframe-формат, который компилируется в runtime-представление.

---

## Связь с существующим runtime

Редактор должен использовать тот же общий runtime `VoiceScenario`, который используется синтезатором и визуализатором, после соответствующего рефакторинга.

Нельзя иметь отдельную семантику исполнения параметров только внутри UI.

Фактическое звучание и фактически отображаемые траектории должны происходить из одной state machine.

---

## Что НЕ является целью первого этапа

Сейчас не требуется:

- автоматически угадать правильный звук;
- автоматически построить фонему;
- добавить новые акустические метрики только ради визуализации;
- сразу построить полноценную физиологическую модель речевого аппарата;
- заменить decoder.

Первая прикладная цель — **максимально упростить ручное экспериментирование**:

1. быстро расставить временные точки;
2. менять значения;
3. слышать результат в цикле;
4. понимать последовательность собственных действий;
5. сохранять удачные варианты;
6. отдавать найденный сценарий и его логи на дальнейший анализ.

---

## Критерий результата

Пользователь может открыть лабораторию, задать общую длительность, включить `Циклично`, расставлять и двигать keyframe-точки нескольких параметров по общей временной шкале и непрерывно слышать, как изменения влияют на звучание.

Интерфейс должен помогать именно **искать неизвестные заранее звучания**, а не требовать заранее понимать, какой JSON нужно написать.

Интерактивный многодорожечный редактор для ручного экспериментирования с параметрами синтезатора во времени, циклического прослушивания и поиска интересных звучаний.

Создать визуальную лабораторию временных сценариев VoiceSynthesizer

## Контекст

Сейчас не строим новый синтезатор и не пытаемся сразу распознавать буквы/фонемы. Цель этапа — понять фундаментально, **что именно мы можем гарантированно измерять из записи микрофона**, какими способами и с какой временной/частотной точностью.

Рабочая гипотеза: сначала нужно построить хороший decoder/analyzer как измерительный прибор, найти устойчивые признаки известных звуков и только потом идти в обратную сторону — строить генераторы, которые воспроизводят эти признаки.

---

## Базовая модель сигнала

При `sampleRate = 48 kHz` одна секунда mono PCM — это 48 000 последовательных отсчётов.

Каждый sample — одно итоговое мгновенное значение амплитуды. После сведения внутренних источников информация о том, **из каких конкретно составляющих получился отдельный sample**, потеряна.

Например одинаковый итог может быть получен разными внутренними суммами. Поэтому обратное восстановление отдельных причин из одного sample невозможно.

Полезная информация появляется только при анализе **траектории во времени**.

Важно различать:

- `x[n]` — текущее отклонение waveform;
- `Δx[n] = x[n] - x[n-1]` — направление и скорость изменения;
- `Δ²x[n]` — изменение скорости/резкость фронта;
- длительную временную структуру;
- частотную структуру.

Один `0` не означает тишину: внутри колебания это может быть прохождение равновесия с большой скоростью. Покой — длительная последовательность около нуля без существенного изменения.

---

## Что можно измерять прямо во временной области

До FFT уже можно гарантированно считать признаки по коротким окнам:

- RMS / общую энергию;
- peak amplitude;
- mean absolute amplitude;
- zero crossing rate;
- `mean(|Δx|)` — среднюю скорость изменения waveform;
- `max(|Δx|)` — резкость самого сильного фронта;
- вторую разность / локальную «ускоренность»;
- variance;
- crest factor;
- autocorrelation и её максимумы;
- длительность участков тишины/низкой энергии;
- onset / резкие появления энергии;
- decay / спад после события.

Эти метрики потенциально уже разделяют разные типы механики:

- длительный voiced звук;
- длительный шумовой/fricative участок;
- короткий burst/plosive;
- тишину/closure;
- периодическое дрожание.

---

## Частотный анализ

Частота не хранится в PCM отдельным полем. Она вычисляется из повторяемости waveform.

Для окна длиной `N` samples можно использовать:

- Fourier/FFT — какие периодические компоненты присутствуют;
- autocorrelation — через какой лаг waveform похож на себя;
- filter bank — энергия в заранее определённых диапазонах.

Для FFT важен компромисс:

- длинное окно → хорошее частотное разрешение, плохая временная локализация;
- короткое окно → хорошая временная локализация, более грубое частотное разрешение.

Примеры:

- 1 s → примерно 1 Hz;
- 100 ms → примерно 10 Hz;
- 20 ms → примерно 50 Hz;
- 10 ms → примерно 100 Hz.

Для речи вероятно потребуется многомасштабный анализ: быстрые burst видеть на 5–10 ms, pitch/formants — на 20–50 ms, длительные стабильные структуры — на 100+ ms.

---

## Частотные дорожки / auditory filter bank

Вместо тысяч FFT bins имеет смысл построить ограниченный набор perceptual bands, например 24–40 полос по логарифмической/ERB-подобной шкале.

Базовая идея:

`PCM -> короткие окна -> FFT/filter bank -> energy каждой полосы во времени`.

Получаем фиксированный набор дорожек:

`Band 1 energy(t)`
`Band 2 energy(t)`
`...`

Количество дорожек фиксировано, а активность в них плавает во времени.

Первый визуальный слой может быть heatmap:

- X = время;
- Y = частотная полоса;
- яркость = энергия.

Не нужно сразу кодировать много метрик толщиной/цветом одной кривой. Базовая вертикальная величина дорожки может быть просто normalized energy `0..1`.

---

## Важное различие: общая энергия и её распределение

`Uint8 0..255` — формат мгновенного sample, а не «бюджет энергии» между полосами.

Для анализа полезнее разделить:

- `totalEnergy` окна;
- относительное распределение энергии по полосам.

Например:

`Frame { totalEnergy, bands[] }`

где при нормализации можно иметь:

`sum(bands) ≈ 1`.

Это позволяет отдельно видеть:

- насколько сигнал вообще сильный;
- куда по спектру ушла энергия.

---

## Поиск спектральных групп

Не стоит жёстко брать `top N` самых сильных полос.

Более осмысленная схема:

1. посчитать все полосы;
2. убрать значения ниже адаптивного noise floor/threshold;
3. найти локальные максимумы;
4. объединить соседние активные полосы в спектральные группы;
5. связать похожие группы между соседними временными окнами.

Так из фиксированных сенсорных дорожек получаются плавающие spectral objects:

- center frequency;
- bandwidth;
- energy;
- duration;
- stability;
- onset/decay;
- periodic/noise-like character.

Это ближе к тому, как слуховая система группирует компоненты в объекты, чем простой выбор десяти самых сильных bins.

---

## Гипотеза о механизмах речи

Вместо десятков скалярных controls будущего синтезатора предлагается мыслить отдельными физиологически/акустически осмысленными генераторами или механизмами.

Примеры:

- frication/constriction — длительный шумовой механизм;
- plosive release — очень короткий burst после closure/pressure build-up;
- voicing — устойчивый периодический источник;
- trill — повторяющиеся квазипериодические прерывания/модуляции;
- nasal coupling — характерная спектральная структура;
- guttural mechanism — отдельный тип возбуждения/резонанса.

Ключевая идея: механизмы должны отличаться **не только амплитудой**, но наблюдаемыми признаками:

- характерной длительностью;
- частотным диапазоном;
- periodicity;
- onset/decay;
- спектральной шириной;
- устойчивостью;
- временной повторяемостью.

Тогда decoder потенциально сможет выделять их из общего PCM по динамическим сигнатурам.

---

## Экспериментальный план

Сначала работать только с микрофоном и известным произносимым материалом.

Порядок:

1. Записывать короткие фрагменты 0.5–1.5 s.
2. Произносить известные звуки/слоги/слова.
3. Строить временные и частотные метрики.
4. Визуально искать устойчивые сигнатуры.
5. Проверять те же сигнатуры в других словах и соседних контекстах.
6. Проверять различимость близких классов (`С/Ш`, `П/Т/К`, voiced/unvoiced и т.п.).
7. Не называть паттерн «буквой», пока он не переносится между разными контекстами.
8. Добиваться высокой различимости сначала для одного человека, одного микрофона и контролируемых условий.
9. Только после этого проектировать обратный generator.

Decoder должен стать измерительным прибором и затем автоматическим тестом генератора:

`human audio -> decoder -> mechanism signature`

`synthetic audio -> decoder -> mechanism signature`

Сравнение проводится в пространстве измеримых признаков, а не только субъективно «похоже/не похоже».

---

## Главный критерий текущего этапа

Не распознавание текста и не синтез речи.

Нужно понять:

> какие признаки мы действительно можем стабильно и воспроизводимо измерять из PCM, на каких временных масштабах, и какие из них позволяют различать устойчивые речевые механизмы.

На этом этапе важнее подтвердить измеримость и различимость, чем добавлять новые сущности в генератор.

Теоретически исследовать, какие свойства PCM и речевого сигнала мы можем гарантированно измерять во времени и частоте, прежде чем проектировать новый генератор.

Задачи

Исследовать измеримые признаки речевого сигнала до построения нового синтезатора

Создать визуальную лабораторию временных сценариев VoiceSynthesizer

Исследовать временную причинность VoiceControlState → DSP → акустические признаки

Исследовать обратный дешифратор: звук → VoiceScenario

Сделать визуальный редактор VoiceScenario и цикл человек ↔ ИИ

Исследовать качественный программный синтез человеческого голоса в браузере