Зафиксирован отдельный концепт «Структура отдельного предмета обучения»: признаки предмета обучения, критерии освоения, зависимости, перенос, обратная связь и минимальное ядро проектирования цель → исходное состояние → необходимые зависимости → практика с обратной связью → проверка переноса. Концепт нужен как общий каркас для позиционирования «Учиться - Легко!» шире текущей механики чтения.
На текущем этапе уже появились несколько устойчивых признаков того, что базовая механика продукта считывается правильно и вызывает нужное поведение.
Продукт понятен практически без инструктажа. Пользователь может открыть страницу, увидеть карточки и сразу начать взаимодействовать с ними. Не требуется проходить onboarding, читать правила или понимать внутреннюю методику до первого полезного действия.
Это соответствует исходной идее продукта: вход должен быть максимально дешёвым, а любой доступный элемент интерфейса — осмысленным сам по себе.
Первые внешние реакции показали, что смысл взаимодействия считывается за очень короткое время. Пользователь успевает открыть продукт, начать нажимать на элементы и понять, что здесь происходит, без дополнительных пояснений.
Важно, что после этого внимание переключается уже не на вопрос «что это такое?», а на само взаимодействие и второстепенные детали интерфейса. Это хороший признак того, что основная механика прозрачна.
Есть ранний признак того, что взаимодействие само по себе удерживает внимание. Пользователь не просто понимает продукт, а продолжает исследовать его дальше.
Это особенно важно, потому что продукт не опирается на отдельный игровой слой, сложную систему наград или обязательный сценарий. Вовлечение возникает из возможности исследовать знакомые слова и получать мгновенную звуковую обратную связь.
Один из потенциальных рисков состоял в том, что ребёнок будет просто многократно нажимать на слова, слоги и буквы ради звука.
Первое наблюдение этого не подтвердило. Ребёнок сначала пытался прочитать самостоятельно и использовал озвучку как средство проверки собственной гипотезы, а не как самоцель.
То есть фактическая деятельность выглядит так:
попытка распознать → проверка через озвучку → сопоставление → переход дальше.
Это хорошо совпадает с задуманной ролью клика: не заменить чтение, а дать мгновенную обратную связь в момент сомнения.
Шестилетний ребёнок быстро разобрался, как пользоваться карточками, без сложного объяснения системы уровней. Это подтверждает, что одновременное присутствие слова, слогов и букв не обязательно создаёт перегрузку.
Ребёнок может сам выбирать, какой уровень использовать в конкретный момент.
После начала взаимодействия ребёнок не завершил сессию после нескольких карточек, а продолжал до тех пор, пока не прошёл весь доступный набор слов.
Это ранний положительный признак того, что сама форма исследования вызывает желание продолжать, даже без дополнительного сценария прохождения.
Сильной стороной текущей реализации является отсутствие обязательной последовательности действий.
Можно начать со слова, слога, отдельной буквы или следующей карточки. Ошибка в порядке действий не приводит пользователя в тупик, потому что каждый элемент остаётся рабочей точкой входа.
Это отличает продукт от сценарных систем, где ценность раскрывается только при правильном прохождении заранее заданной последовательности.
Коммерческая страница не отделена от пользовательского опыта. Пользователь не обязан сначала читать продающий текст, понимать преимущества и только затем переходить к обучению.
Основная механика доступна сразу, поэтому страница сама демонстрирует продукт через действие.
Для текущей модели распространения это особенно ценно: человек, пришедший по рекомендации, может практически мгновенно проверить продукт самостоятельно.
Текущий MVP использует одну основную механику, но она не воспринимается как незавершённая только из-за отсутствия большого числа режимов.
Наоборот, простота делает назначение продукта очевидным и снижает когнитивную нагрузку. Пользователю не нужно выбирать режим обучения, урок, уровень или сценарий до начала взаимодействия.
Текущий продукт воспринимается не как последовательный курс, а как среда исследования.
В ней одновременно доступны:
Ребёнок получает доступ к целому слову сразу и при необходимости может исследовать его внутреннюю структуру.
Это хорошо согласуется с основной теорией проекта: использовать уже знакомое ребёнку слово, его смысл и звучание как опору для формирования визуальной связи с письменной формой.
У коммерческого MVP уже наблюдаются следующие положительные свойства:
На текущем этапе это уже даёт основание считать, что базовая механика коммерческого MVP считывается пользователями так, как была задумана.
Перед внесением изменений сначала был написан отдельный терминальный TypeScript-скрипт, который делает HTTP-запрос к странице, парсит HTML через cheerio и проверяет обязательные Open Graph-теги. Это дало объективный baseline до начала правок и готовый критерий приёмки для ИИ-агента.
import * as cheerio from "cheerio";
const REQUIRED_TAGS = [
"og:title",
"og:description",
"og:image",
"og:url",
"og:type",
] as const;
function isAbsoluteHttpUrl(value: string): boolean {
try {
const url = new URL(value);
return url.protocol === "http:" || url.protocol === "https:";
} catch {
return false;
}
}
async function main() {
const targetUrl = process.argv[2];
if (!targetUrl) {
console.error("Usage: npx tsx check-open-graph.ts <url>");
process.exit(2);
}
const response = await fetch(targetUrl, {
redirect: "follow",
headers: {
"User-Agent": "OpenGraphChecker/1.0",
},
});
if (!response.ok) {
console.error(`HTTP ${response.status} ${response.statusText}`);
process.exit(1);
}
const html = await response.text();
const $ = cheerio.load(html);
let hasErrors = false;
console.log(`HTTP: ${response.status}\n`);
const values = Object.fromEntries(
REQUIRED_TAGS.map((property) => {
const value =
$(`meta[property="${property}"]`).first().attr("content")?.trim() ?? "";
if (!value) {
console.log(`✗ ${property}: missing`);
hasErrors = true;
} else {
console.log(`✓ ${property}: ${value}`);
}
return [property, value];
}),
);
const image = values["og:image"];
const ogUrl = values["og:url"];
if (image && !isAbsoluteHttpUrl(image)) {
console.log(`✗ og:image is not absolute: ${image}`);
hasErrors = true;
}
if (ogUrl && !isAbsoluteHttpUrl(ogUrl)) {
console.log(`✗ og:url is not absolute: ${ogUrl}`);
hasErrors = true;
}
console.log(
hasErrors
? "\nRESULT: invalid or incomplete"
: "\nRESULT: OK",
);
process.exit(hasErrors ? 1 : 0);
}
main().catch((error) => {
console.error(error);
process.exit(1);
});
Первый запуск дал ожидаемо отрицательный результат:
HTTP: 200
✗ og:title: missing
✗ og:description: missing
✗ og:image: missing
✗ og:url: missing
✗ og:type: missing
RESULT: invalid or incomplete
После этого задача была передана ИИ-агенту уже не в абстрактной формулировке «добавить Open Graph», а вместе с конкретным скриптом проверки и воспроизводимым способом проверить результат.
Агент сообщил о следующих изменениях:
Готово. Изменения:
index.tsx — добавлены props image и ogType, выводятся og:title, og:description, og:image, og:url, og:type
index.tsx — вычисляется imageUrl и передаётся в SeoHeaders с ogType="product"
Можешь проверить скриптом:
npx tsx scripts/check-page-image/index.ts "http://localhost:3000/catalog/product.html"
После изменений тот же проверочный подход дал:
HTTP: 200
✓ og:title: Мелкогабаритная площадка Корабль
✓ og:description: Размер 3.48 х 1.78 х 2.32 м.
✓ og:image: http://localhost:3000/images/resized/middle/images/img.jpg
✓ og:url: http://localhost:3000/catalog/product.html
✓ og:type: product
RESULT: OK
Подход оказался полезным: сначала создаётся маленькая исполнимая проверка, фиксирующая текущее состояние и критерий готовности, а затем эта же проверка передаётся исполнителю вместе с задачей. Это уменьшает неоднозначность постановки и делает результат проверяемым не по отчёту агента, а по фактическому поведению системы.
Следующий шаг — усиливать этот шаблон: если агенту даётся проверочный скрипт, в постановке сразу требовать не только внести изменения, но и самостоятельно запустить этот скрипт после реализации и приложить фактический результат. Тогда цикл становится замкнутым: reproduce → implement → verify, а человеку остаётся уже контрольная, а не первичная проверка.
При проверке озвучки на iPhone выяснилась занятная особенность: и Safari, и Chrome фактически используют один и тот же системный голосовой движок iOS.
Для одиночных заглавных букв он ведёт себя крайне неудачно для учебного сценария: вместо самой буквы/её обычного произношения проговаривает фразу вида «Заглавная буква Б».
Для карточек с буквами это ломает механику, поэтому перед отправкой текста в TTS пришлось нормализовать его в нижний регистр.
Практический вывод: визуальное представление и строка, отправляемая в speechSynthesis, не обязаны совпадать. На экране буква может оставаться заглавной, а в TTS передаваться её lowercase-вариант.
Проверена встроенная браузерная озвучка на отдельных словах, слогах и буквах. Для целых слов API в ряде случаев работает приемлемо, но на коротких слогах и отдельных буквах проявляются заметные и непредсказуемые ошибки интерпретации текста.
Собака — произносится нормально.Ры — произносится нормально.Свинья — произносится нормально.Пель — неожиданно произносится нормально.Со — звучит примерно как просто С.Р — звучит скорее как Э.Ре — тоже звучит примерно как Э.Свинь — вместо слога начинает читать как названия букв: примерно Эс Вэ Ен Мягкий знак. При этом И и Н отдельно не проговариваются ожидаемо, а часть последовательности интерпретируется как Ен.Ковь — тоже разваливается на чтение по буквам.Солн — также читается по буквам/не как слог.Ко — звучит как Ка.Ар — звучит как А.Де — звучит как Дэ.SpeechSynthesisUtterance хорошо подходит для обычных слов и фраз, но не гарантирует корректное произношение искусственно выделенных слогов и отдельных букв.
TTS-движок пытается интерпретировать короткую строку как естественный текст, название буквы, аббревиатуру или неизвестную лексему. Поэтому одинаковая последовательность символов может озвучиваться по-разному в зависимости от длины и контекста.
Особенно проблемны:
ь;Нельзя считать браузерный TTS универсальным источником правильного произношения для учебной механики буква → слог → слово.
Для целых слов его можно использовать напрямую, но для букв и слогов потребуется один из вариантов:
Эти наблюдения относятся к фактическому поведению текущего браузерного/системного голоса. На другой ОС, браузере или другом SpeechSynthesisVoice результат может отличаться, поэтому подобные исключения нельзя считать универсальными для всех устройств.
На текущем этапе ни один из реализованных/предложенных сенсоров не дал хоть сколько-нибудь полезной, визуально устойчивой или интерпретируемой информации для различения речевых звуков.
Это важно зафиксировать как отрицательный результат, а не пытаться «дожимать» эксперимент оптимистичными эвристиками.
Обсуждались и/или предлагались сенсоры по временной области:
Затем была попытка построить грубый sibilanceSensor для С/Ш через:
После этого предложен грубый frequency-band sensor с 12 логарифмическими полосами примерно от 60 Hz до 14 kHz.
Практический результат: никакой из этих подходов пока не показал даже приблизительно полезной картины, которая позволяла бы уверенно сказать, что измерения отражают различия между известными произнесёнными звуками.
Главная ошибка — преждевременный переход от вопроса «что мы реально видим в данных?» к вопросу «какой сенсор должен детектить С/Ш?».
В результате появились эвристики вроде условной границы 5.5 kHz, sibilance-presence, набора заранее выбранных frequency bands и ожидаемых графиков до того, как была получена хоть одна подтверждающая серия реальных измерений.
Это повторяет уже наблюдавшуюся проблему: код выглядит правдоподобно, но основание под ним не доказано экспериментом.
RMS, ZCR, |Δx|, autocorrelation и спектральные метрики действительно вычисляются корректно как свойства waveform. Но из этого не следует, что они полезны для различения фонем/механизмов речи в конкретной записи.
Например два разных звука могут иметь очень похожие RMS/ZCR, а один и тот же звук — сильно менять эти значения в зависимости от громкости, расстояния до микрофона и контекста.
Попытка в каждом кадре нормализовать band energies так, чтобы сумма была около 1, делает удобной визуализацию спектрального распределения, но одновременно удаляет абсолютную информацию об интенсивности.
Для сравнения сибилянтов и несибилянтов абсолютная шумовая энергия сама может быть важным признаком.
Нельзя заранее решать, какие компоненты сигнала являются «мешающим масштабом», пока мы не проверили их экспериментально.
Фиксированное окно 20–40 ms удобно технически, но разные речевые механизмы живут на разных масштабах:
Один масштаб окна неизбежно скрывает часть событий.
12 полос типа 2.5–4 kHz, 4–6.3 kHz, 6.3–10 kHz могут быть настолько широкими, что реальные локальные спектральные различия внутри них просто исчезают.
При этом переход сразу к десяткам полос без доказанной пользы тоже создаст только больше данных, а не больше понимания.
Пока отсутствует строгий набор сравнительных записей:
Без этого невозможно отличить устойчивый признак фонемы от случайной вариации записи.
Один график почти ничего не доказывает.
Нужно минимум несколько повторов каждого класса и сравнение распределений признаков:
Если разброс одного и того же звука больше, чем разница между двумя звуками, сенсор бесполезен для нашей задачи.
С, Ш, Ф — полезные тестовые классы, но сенсор не должен начинаться с предположения о букве.
Правильнее сначала находить объективные различия между наборами записей, а потом уже смотреть, чему они соответствуют артикуляционно и фонетически.
audioDataДо дальнейших выводов необходимо отдельно проверить:
audioData;Uint8, Float32, другое);sampleRate;audioData уже результатом AnalyserNode с ограниченной/изменённой семантикой.Если входной сигнал уже автоматически нормализуется или фильтруется браузером, это может полностью менять наблюдаемые признаки.
Если каждый sensor сам выбирает normalized 0..1, визуально любые маленькие различия могут выглядеть значительными, а большие абсолютные различия — одинаково.
Для исследовательского инструмента первичными должны быть сырые значения с единицами измерения, а визуальная нормализация должна быть отдельным, прозрачным слоем.
Не писать очередной «умный сенсор».
Сначала построить минимальную экспериментальную инфраструктуру:
Главный вывод текущего этапа:
пока нет оснований утверждать, что предложенные сенсоры дают полезную информацию для распознавания звуков. Эксперимент нужно вернуть на более низкий уровень: сначала честно наблюдать waveform и спектр реальных записей, затем извлекать только те метрики, полезность которых подтверждена повторяемыми данными.
Фактическая проверка показала, что текущий компонент нельзя считать пригодной основой для дальнейших экспериментов со звуком.
Основные проблемы:
requestAnimationFrame (~60 Hz) непригодно для коротких акустических событий, burst и быстрых переходов; дополнительное сглаживание ещё сильнее размывает события.useReducer/finite state machine с явными состояниями stopped/playing/paused и детерминированными переходами.Вывод: точечное исправление текущей реализации нецелесообразно. Компонент нужно переписать с нуля, сохранив только общую идею визуальной лаборатории: timeline, дорожки параметров, keyframes, loop и ручной поиск звучаний. Новая версия должна строиться вокруг единой машины состояния и предварительного вычисления аудиобуфера из сценария.
Создан отдельный новый экспериментальный синтезатор и визуальный редактор, намеренно не связанный с прежним VoiceSynthesizer и его накопившейся сложной DSP-моделью.
Это важное архитектурное решение было сделано сознательно: цель текущего этапа — не сохранять совместимость со старыми сценариями и не воспроизводить прошлые эксперименты, а получить максимально чистый лабораторный стенд для ручного исследования звука.
Текущая структура включает:
hold, linear, bezier, sine, burst, noise;sawtooth + noise + formant filters + gain.В UI сейчас представлены основные экспериментальные дорожки:
Интерфейс визуально получился удачным как лабораторный инструмент: временная ось читается, события видны, параметры можно быстро менять, а общая длительность не привязана к последней точке. Это позволяет строить длинные удерживаемые звуки и последовательности состояний.
Новый редактор НЕ должен сейчас быть интерфейсом к старому DSP.
Он задуман как независимый чистый эксперимент:
простые источники + простые фильтры + временные траектории -> слышимый результат.
Основной исследовательский вопрос:
Можно ли вообще вручную, методом контролируемого перебора и прослушивания, найти хоть какие-то узнаваемые речеподобные звуки?
То есть текущая задача — не воспроизводимость старых VoiceScenario, а поиск самой минимальной работающей акустической модели.
Предыдущая ветка синтеза накопила много взаимозависимых экспериментов и параметров. Сейчас сложно понять, где именно ошибка, и изменение одного механизма легко может сломать другой.
Поэтому чистый стенд нужен как контролируемая среда, где каждый новый механизм добавляется осознанно и его эффект можно услышать отдельно.
Принцип дальнейшей работы:
минимальный движок -> ручной поиск -> наблюдение -> обнаружение недостающего механизма -> добавить только его -> повторить эксперимент.
По словам разработавшего агента набор возможностей выглядит завершённым, но фактическая проверка результата показала, что отчёт был слишком оптимистичным.
На текущем этапе:
С;А, М, Р, Т и другие звуки ещё не получены вручную и не подтверждены слухом.Это не считается провалом эксперимента. Напротив, стенд теперь позволяет выяснять, какие именно механизмы минимально необходимы для появления конкретных классов звуков.
Практическая ценность редактора пока не доказана окончательно.
Сейчас проверяется более базовая вещь:
Если эти пункты подтверждаются, лаборатория уже полезна как исследовательский инструмент, даже если качество звука пока далеко от человеческой речи.
Не нужно заранее строить сложную физиологическую модель речи.
Правильнее сначала искать минимальные акустические механизмы вручную.
Например:
Р невозможно получить без периодического модулятора, это станет экспериментальным основанием добавить такой механизм;Т требует последовательности silence -> burst -> noise tail, это тоже должно вытекать из ручного эксперимента;F0 + F1/F2/F3, это должно быть найдено и подтверждено слухом.То есть новые возможности добавляются не по предположению, а по наблюдаемому дефициту текущей модели.
burst, sine, повторяющиеся колебания и шумовые модуляции концептуально могут оказаться не просто интерполяциями, а отдельным классом временных модуляторов. Возможно, позже стоит разделить:
Не «синтезатор уже умеет говорить» и не «пресеты совпадают с буквами».
Ближайший критерий успеха намного проще:
Пользователь может включить Loop, двигать keyframe-точку или параметр, слышать несколько вариантов подряд и устойчиво находить хотя бы некоторые узнаваемые речеподобные звучания, понимая, какое изменение к ним привело.
После нахождения интересных звучаний сценарий и логи будут использоваться для последующего анализа и для принятия решений о том, какие новые механизмы действительно стоит добавлять.
Проведены одиночные эксперименты по VoiceControlState -> DSP -> acoustic features для всех основных управляющих параметров.
При одиночном sweep, когда изменяется только один control при фиксированных остальных, многие параметры дают сильную корреляцию с наблюдаемыми акустическими признаками.
Наиболее выраженные результаты:
sourceLevel сильно связан с peak, rms, величиной спектрального пика;periodicity также сильно отражается в peak/rms, но эти признаки совпадают с амплитудными controls;f0Hz хорошо проявляется через pitch-related признаки, ZCR и распределение высокочастотной энергии;resonance1Freq хорошо проявляется через положение первого спектрального пика;resonance2Freq проявляется через rolloff/formant-related признаки;resonance*Gain хорошо наблюдаются через амплитудные признаки;outputLevel практически идеально отражается в peak/rms.При этом noiseLevel, glottal-параметры, bandwidth-параметры и resonance3Freq текущим набором признаков наблюдаются значительно хуже.
Высокая корреляция в одиночном sweep НЕ означает прямую восстанавливаемость параметра.
Нужно различать:
Например:
sourceLevel, outputLevel и resonanceGain все сильно меняют rms/peak;periodicity в текущем эксперименте тоже сильно влияет на те же амплитудные признаки.Следовательно, эти controls чувствительны и наблюдаемы, но пока не доказано, что они различимы между собой в реальном сценарии, где несколько параметров изменяются одновременно.
1. Частотные координаты — наиболее перспективны для прямого восстановления:
f0Hz;resonance1Freq;resonance2Freq;resonance3Freq после улучшения спектрального анализа.Они меняют не только общую энергию, но и структуру спектра.
2. Амплитудные/масштабирующие controls — наблюдаемы, но смешиваются:
sourceLevel;outputLevel;resonance1Gain;resonance2Gain;resonance3Gain;periodicity.Для них требуется совместное восстановление или дополнительные признаки, потому что похожий эффект может достигаться разными комбинациями параметров.
3. Формообразующие controls — текущий лог видит плохо:
glottalOpenPhase;glottalReturnPhase;resonance*Bandwidth;noiseLevel;resonance3Freq.Для них, вероятно, нужны признаки формы периода, spectral envelope, harmonic/noise structure, LPC или иные более специализированные измерения.
Во всех одиночных экспериментах реакция обнаруживалась практически сразу (~0.2 ms), а окно 20 ms оказалось достаточным для текущего набора признаков. Однако одинаковый лаг для всех параметров, вероятно, отражает прежде всего разрешение методики измерения и временную привязку окон, а не реальную физическую константу DSP.
Отдельно обнаружена длительная память резонаторов (~250 ms в текущем эксперименте). Эту величину нельзя пока считать универсальной: время затухания должно зависеть от frequency/bandwidth/Q и требует отдельного sweep по параметрам резонатора.
Сценарий и акустический лог находятся на разных уровнях представления:
VoiceControlState -> внутреннее DSP-состояние -> waveform -> spectrum/features.
Управляющие параметры могут почти не меняться во времени, но порождать сложный высокочастотный waveform. Поэтому control-график не должен быть похож на график акустических признаков.
Для восстановления параметров нужно исследовать не соответствие одного control одному feature, а отображение:
vector(features over a time window) -> vector(controls).
Следующий принципиальный эксперимент должен проверять одновременные изменения нескольких controls. Именно он покажет реальную идентифицируемость, а не только чувствительность.
Одиночные sweeps уже ответили на вопрос: «реагирует ли звук на конкретный control и какими признаками это видно?».
Следующий вопрос: «можем ли мы отличить изменение одного control от другого, когда они действуют одновременно?».
Также исследования показывают, что для дальнейшей работы нужен удобный интерактивный временной редактор: не для редактирования уже найденных JSON-сценариев, а как лаборатория ручного поиска звучаний и причинных связей между временными траекториями параметров и результатом.
Перепроверена семантика VoiceScenario по фактической реализации synthesizeScenario.
animate.to после окончания duration НЕ сбрасывается. После завершения automation state[param] = to, сама automation удаляется, но новое значение остаётся активным до следующей команды.set также меняет состояние постоянно, пока параметр не будет изменён снова.animate начинается от фактического текущего значения параметра на момент команды.initial используется только у первого сценария, последующие продолжают текущее состояние без reset.Старый ScenarioVisualizer отображал только активные участки animate, из-за чего исходный сценарий визуально выглядел "рваным". Это не соответствовало реальному состоянию синтезатора.
Визуализатор перепроектирован на отображение полного VoiceControlState(t): значения идут непрерывно от начала до конца сценария, включая удержание последнего to после окончания duration, set, прерывание старых automation и продолжение состояния между составными сценариями.
Логика исполнения сценария (prepareScenario, evaluateBezier, updateAutomations, executeCommand) не должна дублироваться между синтезатором и визуализатором. Создана отдельная задача на вынос общего runtime-модуля, чтобы DSP и визуализатор использовали одну state machine.
Даже после исправления визуализации видно, что текущий лог и сценарий находятся на разных уровнях представления. Сценарий содержит управляющие параметры, а лог содержит наблюдаемые акустические признаки. Прямое соответствие вида RMS -> sourceLevel, dominantFrequency -> f0Hz и т.п. в общем случае некорректно.
Также подтверждено, что исходный сценарий имеет существенно больше управляющих параметров, чем текущий лог акустических метрик, поэтому обратимость Scenario -> Sound -> Log -> Scenario в текущей архитектуре физически недоопределена.
Проведён разбор полного пути VoiceScenario -> PCM.
Уточнено, что никакого внешнего скрытого звукового движка, который формирует PCM, нет. Конечный массив звуковой дорожки целиком вычисляется внутри synthesizeScenario:
VoiceScenario -> VoiceControlState(t) -> excitation -> resonators -> value -> Float32Array.
На каждом sample код самостоятельно вычисляет итоговое значение и записывает его в output[sampleIndex]. Браузерный AudioBufferSourceNode затем лишь воспроизводит уже готовый PCM.
Это означает, что весь DSP можно инструментировать и исследовать на каждом шаге.
После исправления представления сценария стало видно, что даже почти постоянные управляющие параметры дают высокочастотные изменения в измеряемом аудио. Это ожидаемо.
Причины:
f0Hz задаёт скорость изменения voicePhase, а не постоянное значение waveform;noiseLevel управляет амплитудой случайного источника, который меняется каждый sample;low, band) и продолжают динамически изменяться даже при постоянных параметрах;Поэтому control curve != measured acoustic curve.
Между VoiceControlState и PCM существуют внутренние состояния:
voicePhase;resonator1/2/3.low;resonator1/2/3.band;Именно этот слой объясняет, почему почти горизонтальные управляющие линии могут приводить к сложному высокочастотному waveform и неровным акустическим метрикам.
Нужно перейти от вопроса "какая метрика лога соответствует параметру" к задаче идентификации системы:
как изменение каждого параметра VoiceControlState влияет на waveform и на измеримые акустические признаки?
Предлагаемый эксперимент: parameter sweep по каждому управляющему параметру при фиксированных остальных и сбор waveform + спектральных/временных характеристик. Это позволит построить карту control -> acoustic features и понять, какие параметры реально наблюдаемы из аудио, какие зависят от комбинаций параметров, а какие текущим логгером вообще не видны.
Также обсуждена базовая теория PCM: постоянный unsigned 8-bit PCM уровень (например 255,255,255,...) не даёт устойчивого тона, потому что нет периодического изменения; слышимы в основном переходы. Это подчёркивает, что отдельное значение PCM — мгновенная амплитуда, а частота/тембр/громкость являются свойствами структуры последовательности во времени.
В рамках поиска существующих реализаций проверен встроенный браузерный SpeechSynthesis.
Минимальный пример:
const utterance = new SpeechSynthesisUtterance('Привет, это синтез речи!');
utterance.lang = 'ru-RU';
const voices = speechSynthesis.getVoices();
utterance.voice = voices.find(v => v.lang === 'ru-RU');
speechSynthesis.speak(utterance);
Этот код показывает важный факт: современный браузер уже умеет воспроизводить вполне нормальную человеческую речь по тексту без нашей собственной DSP-реализации.
Но архитектурно это совсем другой класс системы и для нашей основной задачи он не подходит.
SpeechSynthesisUtterance принимает текст и настройки вроде языка/голоса, после чего передаёт их встроенному speech engine браузера/операционной системы.
Условная схема:
text
→ SpeechSynthesisUtterance
→ language / voice selection
→ hidden TTS engine
→ audio
Для пользователя доступен результат, но не внутренняя программа формирования звука.
API принимает текст, а не артикуляционную или акустическую траекторию.
Например:
мама
обычно произносится нормально.
Но попытка написать:
ммммммааамама
не означает для движка:
удерживать /м/
→ плавно перейти в /а/
→ продолжить слог
Движок интерпретирует строку как текст и может начать читать её примерно как последовательность названий букв или слогов:
эм-эм-эм-эм... а... ма-ма...
Аналогично:
шшшшшшшш
может превращаться в что-то вроде:
ша-ша-ша-ша...
То есть через этот API нельзя надёжно задать:
Поэтому API практически не пригоден для экспериментов вида:
М ─────────→ А
где именно сам переход является объектом исследования.
Поскольку входом является текст, а не звуковой сценарий, нельзя свободно задавать:
Изменение общей rate или pitch не решает эту проблему: оно меняет поведение всего utterance, а не даёт управление внутренними звуковыми событиями.
SpeechSynthesisUtterance опирается на lang и конкретный voice.
Это означает, что движок ожидает текст в рамках некоторой языковой системы.
Проблемными становятся:
Даже если движок пытается что-то произнести, он делает это через собственные правила интерпретации текста, а не как универсальный генератор произвольного звука.
Корректнее говорить не только о «словаре» в буквальном смысле, а о более широком ограничении:
движок умеет произносить то, что способен интерпретировать в рамках своей языковой модели произношения.
То есть неизвестную строку он может попытаться прочитать, но это всё равно будет интерпретация как текста, а не прямое воспроизведение заданного акустического объекта.
Для нашей задачи это принципиально важно.
Нам нужен механизм уровня:
sound scenario
→ exact parameter trajectories
→ sound
а здесь используется:
text
→ hidden linguistic interpretation
→ hidden TTS model
→ sound
Даже если движок произносит слово очень качественно, наружу не выдаётся структурное описание того, как именно был построен звук.
Нет доступного представления вида:
initial state
+ timeline
+ source parameters
+ noise parameters
+ resonances
+ transitions
Поэтому SpeechSynthesis не помогает решить центральную задачу исследования:
получить компактное управляемое описание звука и уметь переходить между звуком и этим описанием.
Он демонстрирует только способность системы воспроизводить хорошую речь из текста.
Несмотря на архитектурную непригодность для нашей задачи, SpeechSynthesis полезно рассматривать как отдельный готовый вариант для других проектов.
Если задача звучит просто как:
текст → нормальная речь
то браузерный API может полностью закрыть её без собственного синтезатора.
Он особенно полезен там, где:
SpeechSynthesis показывает, что качественная речь в браузере как конечный результат доступна уже сейчас.
Но он не подходит нам архитектурно, потому что:
sound → scenario.Поэтому для нашей исследовательской задачи это не конкурент VoiceScenario, а отдельный готовый TTS-инструмент для гораздо более узкого класса задач.
Поиск внешних проектов был нужен прежде всего для ответа на один вопрос:
насколько пространство реальной человеческой речи лежит внутри пространства звуков, которое способен воспроизвести компактный процедурный генератор.
Прямого подтверждения этому пока не найдено.
AudioContext способен качественно воспроизвести любой заранее записанный цифровой звук, если передать ему полный массив samples. Значит, проблема не в браузере как среде воспроизведения.
Проблема — в представлении.
Полный waveform универсален, но дорог: даже сильно сжатая секунда речи остаётся последовательностью из тысяч значений. Наша модель заменяет эту последовательность компактным сценарием из осмысленных параметров и команд во времени.
Поэтому исследуемая граница выглядит так:
полный waveform ← больше данных / выше универсальность ... структурный VoiceScenario → меньше данных / выше управляемость
Нужно понять, где на этой оси появляется качество, достаточное для естественной речи.
Pink Trombone и похожие физические модели показывают, что можно процедурно генерировать часть voice-like пространства, но:
запись → компактный сценарий.Формантные демо ещё уже: они показывают отдельные статические или почти статические звуки, но не отвечают на вопрос о покрытии реальной речи.
Klatt-подобные системы не являются ориентиром для нашей архитектуры, потому что уже опираются на фонемные/языковые пресеты и не решают универсальную дешифровку произвольного звука.
Neural TTS/codec systems демонстрируют высокое качество, но скрывают внутреннее представление и не дают прозрачного управляемого сценария, который можно исследовать и редактировать.
Отсутствие найденного примера не означает, что компактный сценарный генератор не способен приблизиться к человеческой речи. Оно означает только, что у нас пока нет внешнего доказательства нужного уровня качества.
Поэтому следующий практический путь — не продолжать бесконечный поиск аналогов, а измерять пределы собственной модели:
Главный объект исследования теперь — компромисс между компактностью структурного описания и perceptual quality.
Зафиксированы несколько обнадёживающих признаков текущего прототипа.
Текущий синтезатор оперирует отдельными переменными начального состояния и отдельными сценариями на общей timeline. Это принципиально отличается от прямого хранения нескольких тысяч/десятков тысяч отсчётов.
Несмотря на грубость модели, из сравнительно малого числа параметров уже получаются звуки, которые человек иногда распознаёт как буквы/фонемные фрагменты или слоги. Это ещё не доказывает достаточность модели для естественной речи, но показывает, что параметрическое пространство не является полностью хаотичным.
ИИ не имеет надёжного эталона того, насколько натурально звучит синтез. Поэтому текущий рабочий цикл выглядит так:
ожидаемый звук → сценарий → синтез → человек слушает → оценивает качество → ИИ предлагает изменения параметров → новый синтез.
Человек здесь даёт финальную perceptual feedback, а ИИ помогает анализировать структурные различия и двигаться по пространству параметров.
При поиске звука Ха была использована запись слова/фразы КуХаРе, где нужный участок реально присутствует. ИИ получил:
Далее он сравнивает структурные признаки и предлагает, какие параметры сценария можно изменить, чтобы приблизиться к нужному участку.
Это не даёт мгновенного результата, но выглядит как рабочий человеко-ИИ цикл приближения к целевому звуку.
Есть подозрение, что качество аналитических логов недостаточно для точного сравнения. Если человек слышит различия, которых ИИ не может вывести из лога, bottleneck может находиться не только в генераторе, но и в разрешении анализа.
Нужно отдельно проверять, как меняется качество предложений ИИ при уменьшении сжатия логов и увеличении числа временных/спектральных признаков.
При поиске Ха один из вариантов был воспринят как Ва.
Это полезно по двум причинам:
Ва показывает направление в параметрическом пространстве.Такие случайные находки нужно сохранять вместе с изменениями параметров, потому что они помогают картировать пространство возможных звуков.
Несмотря на потенциальную универсальность AudioContext, при изменениях параметров текущего voice-oriented генератора мы пока в основном сталкиваемся со звуками, которые воспринимаются как голосовые/фонетические или близкие к ним, а не как случайные реальные звуки вроде лая, птичьего пения или стука копыт.
Это не доказывает универсальность и не доказывает полноту покрытия человеческой речи. Более осторожный вывод:
текущая архитектура генератора уже содержит сильный inductive bias в сторону voice-like sound space.
Это может быть полезным свойством, потому что поиск происходит не по всему возможному аудиопространству, а по более узкой области.
Теперь основной вопрос не только «какие параметры нужны для синтеза речи», а:
насколько компактно можно описать нужную область человеческой речи, не возвращаясь обратно к тысячам samples.
Крайние точки уже понятны:
VoiceScenario — компактность и управляемость, но пока неизвестные пределы качества.Дальнейшая работа должна исследовать промежуток между ними и зависимость:
качество ↑ ↔ сложность/размер представления ↑.
Возможный путь — постепенно добавлять только те механизмы, которые дают заметный perceptual gain, сохраняя структурность модели.
Проверили гипотезу о том, что для нашей задачи должен существовать практически применимый пример вида:
реальная запись звука/слога → автоматический анализ → компактная параметрическая траектория универсального генератора → обратный синтез узнаваемого звука
Процедурный синтез сам по себе существует. Web Audio даёт осцилляторы, шум, фильтры и AudioWorklet; Pink Trombone показывает browser-native physical vocal tract; формантные демо позволяют получать отдельные гласноподобные звуки из малого числа параметров.
Обычное waveform-представление очень велико. Около 1 секунды записи с микрофона может занимать порядка 200 KB в Float32Array. Даже после агрессивного μ-law @ 8 kHz остаётся около 11 KB и более 10 000 значений на секунду, хотя речь всё ещё воспринимается нормально. Это создаёт сильную интуицию, что воспринимаемая структура звука должна иметь существенно более компактное представление.
В литературе есть много методов анализа речи. LPC, source-filter analysis, formant tracking, spectral-envelope estimation, vocoders, analysis-by-synthesis и др. По названиям и описаниям они выглядят близко к нужному механизму.
LLM первоначально оценивали задачу слишком оптимистично. Концептуальная схема выглядит простой: generator + parameters + target sound + optimizer. Это создало ложное впечатление, что практический inverse mapping должен быть давно решён и доступен в открытых проектах.
Есть множество примеров, где sawtooth/impulse source проходит через несколько band-pass фильтров и получается звук, напоминающий гласную.
Это доказывает только прямую генерацию из заранее известных параметров. Нужной нам обратной дешифровки такие примеры не дают.
Это наиболее интересный из найденных генераторов, потому что:
Но для нашей задачи не хватает главного:
recording → tract trajectory;МА или любого другого звука;То есть Pink Trombone даёт генератор, но не дешифратор.
Не являются архитектурным ориентиром для нашей задачи.
Причины:
Для нас это слишком узкий слой: мы ищем универсальную дешифровку звука, а не таблицу фонем.
Позволяют оценивать отдельные характеристики: спектральную огибающую, резонансы, источник возбуждения и т.п.
Но не найден end-to-end кейс, где эти характеристики автоматически превращаются в компактную управляющую программу достаточно универсального генератора, после чего воспроизводится звук, близкий к исходному.
То есть это отдельные части решения, а не готовая система.
Нашлись работы, где параметры синтезатора подбираются по естественной речи оптимизацией.
Это полезно не как готовое решение, а как подтверждение инженерной сложности: обратное отображение нелинейно, неоднозначно и требует поиска в большом пространстве параметров.
Готового универсального browser-friendly решения нужного качества при этом не найдено.
Высокое качество есть, но это другой класс решения:
VoiceState;Не найден ни один убедительный открытый технический пример, который одновременно:
Это сейчас главный отрицательный результат исследования.
Похожий выходной waveform может быть получен разными внутренними состояниями генератора. Из записи нельзя просто однозначно восстановить один «правильный» набор параметров.
Два waveform могут иметь большую sample-by-sample разницу, но звучать почти одинаково. И наоборот, небольшая ошибка в критической временной или спектральной области может сильно менять восприятие.
Значит, обычный MSE не является достаточной целевой функцией.
Звук — динамический процесс. Меняются источник возбуждения, резонансы, шум, атака, закрытия и раскрытия, носовой канал и другие параметры.
Поэтому реальная переменная поиска — временная программа параметров, а не одна статическая точка.
Если выбранная модель недостаточно выразительна, никакой оптимизатор не восстановит исходный звук. Чем выразительнее генератор, тем больше пространство параметров и сложнее обратный поиск.
Для качественной речи могут быть существенны glottal source, spectral tilt, aspiration, turbulence, antiresonances, nasal coupling, jitter/shimmer, динамика vocal tract, source-filter interaction и другие механизмы.
Добавление каждого механизма улучшает выразительность, но одновременно усложняет дешифровку.
Подобрать параметры одного А вручную можно. Универсально восстанавливать произвольный звук таким методом невозможно.
Это похоже на ручной подбор точного цвета через CMYK без преобразования из целевого цвета в параметры: можно добиться отдельных примеров, но это не решает общую задачу.
Главная задача теперь формулируется не как «сделать синтезатор русских букв» и не как «подобрать хорошие пресеты».
Она универсальнее:
Научиться автоматически находить компактную временную программу параметров достаточно универсального генератора для заданного реального звука.
Буквы, фонемы и языки должны быть только возможными категориями поверх найденного звукового пространства, а не частью ядра.
Кейс показал отдельный риск: LLM легко принимают понятную архитектурную декомпозицию за признак низкой инженерной сложности.
Несколько моделей первоначально описывали задачу как практически простую, потому что все компоненты по отдельности знакомы: Web Audio, filters, interpolation, optimization.
Но наличие понятных компонентов не доказывает существование работающей системы из них.
Только попытка найти конкретный воспроизводимый end-to-end кейс показала, что критический inverse mapping среди найденных решений фактически отсутствует.
Для дальнейшей работы техническую реализуемость нужно проверять минимальными proof-of-feasibility экспериментами, а не уверенностью LLM.
Исследован базовый физический предел для качественного воспроизведения речи и ориентиры для русского языка.
Ключевые выводы:
Важно различать bitrate хранения/передачи и сложность синтезатора: один выходной аудиоканал может быть получен из многих внутренних источников/фильтров (glottal source, aspiration, frication, resonances, nasal branch и т.д.). Число внутренних DSP-компонентов не равно числу выходных аудиоканалов.
Зафиксирован и экспериментально проверен основной архитектурный подход: человеческий звук описывается как непрерывный сценарий изменения универсального состояния DSP во времени, а не как специальный renderer буквы/фонемы.
VoiceScenario с initial и общей timeline.set и animate, включая cubic bezier.VoiceScenario, так и VoiceScenario[].Привет как [PRI_SCENARIO, VET_SCENARIO], а не создавать отдельный сценарий слова.Используется схема:
живая запись → лог → анализ → сценарий → синтез → тот же логгер → сравнение → корректировка
Текущий logger измеряет RMS, peak, ZCR, spectral centroid, spectral flatness, dominant frequency и несколько энергетических диапазонов. Он пока грубый: анализ на 128 samples даёт частотный шаг около 375 Hz, поэтому его нужно в дальнейшем улучшать.
Протяжное А уже получилось относительно естественным. Это подтвердило, что timeline + периодический источник + универсальные резонансы в принципе подходят для части устойчивых голосовых состояний.
После нескольких итераций выяснилось, что субъективное «шипение» нельзя сводить к избытку высоких частот. Живая сильная С имеет одновременно высокий ZCR, высокий spectral centroid и интенсивную высокочастотную турбулентность. Усиление только общей амплитуды не решает задачу качества источника.
Ш рассматривается как близкое к С непрерывное шумовое состояние, но с более низким и широким распределением спектральной энергии.
Т подтвердило наличие кратковременных событий, которые нельзя тянуть как устойчивое состояние. Для живой Т характерен очень короткий высокочастотный выброс и быстрое затухание; в нескольких записях основной максимум часто оказывался около 15–16 kHz. Это удалось выразить той же timeline-моделью без специального типа T.
Созданы сценарии При и Вет, затем проверена их композиция через массив сценариев. Они уже узнаваемы, но качество звучания остаётся явно компьютерным.
После сравнения с живым Привет выявлено:
sourceLevel для Р звучат механически;Т в одном из вариантов доходил до peak = 1, то есть попадал в hard clamp;Т ослаблен.Основной риск сейчас находится не в сценарной архитектуре, а в качестве самого звукового двигателя. Возможные недостающие универсальные механизмы:
Создана отдельная связанная исследовательская задача cmtzxmokp085eqw0qtb7vg7c2 про качественный программный синтез человеческого голоса в браузере. В ней нужно найти browser-native/browser-capable проекты и DSP-подходы, которые без генеративного TTS качественно воспроизводят хотя бы несколько человеческих звуков или слогов, и понять, какие универсальные механизмы стоит перенести в текущий движок.
После первого прохода по топикам обработка была расширена на весь ресурсный корпус: топики, комментарии, блоги и прочие сущности, унаследованные от общей модели Resource (исторически — от MODX site_content).
По данным OpenRouter итоговый пакет составил примерно 12 000 AI-запросов, 14,1 млн токенов и около $7.99 расходов. Почти вся массовая обработка выполнялась на Gemini 3.5 Flash Lite.
Это практически совпадает с масштабом текущего архива: только Topic + Comment дают 11 890 сущностей (1 349 топиков и 10 541 комментарий), а с блогами и прочими типами общий объём естественно выходит примерно к 12 тысячам ресурсов.
Практический вывод оказался важнее самой миграции Markdown: полный управляемый AI-проход по многолетнему публичному архиву стоит единицы долларов. Изначально ожидался порядок 8.
Это меняет экономику контента. Теперь можно не ограничиваться одноразовой миграцией, а делать специализированные повторные проходы по всему корпусу: нормализацию, классификацию, выделение сущностей и утверждений, построение связей, поиск изменений позиций, тематические ретроспективы, provenance и подготовку новых публикаций. Стоимость полного машинного прочтения корпуса становится сопоставима с обычной технической операцией, а не с редакционной работой.
На уровне модели распространения это даёт ещё один вывод: человек может передать AI ядро мысли, AI — догуглить и собрать контекст, затем опубликовать управляемый набор материалов на одном или нескольких сайтах. Дальше эти материалы становятся доступными другим AI-агентам и могут входить в их ответы через GEO/AI-search. То есть дешёвая массовая генерация здесь используется не ради спама, а как управляемая публикационная инфраструктура для распространения проверяемых идей и экспертизы.