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

Прогресс исследования

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

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

Почему такой пример казался вполне существующим

1. Процедурный синтез сам по себе существует. Web Audio даёт осцилляторы, шум, фильтры и AudioWorklet; Pink Trombone показывает browser-native physical vocal tract; формантные демо позволяют получать отдельные гласноподобные звуки из малого числа параметров.

2. Обычное waveform-представление очень велико. Около 1 секунды записи с микрофона может занимать порядка 200 KB в Float32Array. Даже после агрессивного μ-law @ 8 kHz остаётся около 11 KB и более 10 000 значений на секунду, хотя речь всё ещё воспринимается нормально. Это создаёт сильную интуицию, что воспринимаемая структура звука должна иметь существенно более компактное представление.

3. В литературе есть много методов анализа речи. LPC, source-filter analysis, formant tracking, spectral-envelope estimation, vocoders, analysis-by-synthesis и др. По названиям и описаниям они выглядят близко к нужному механизму.

4. LLM первоначально оценивали задачу слишком оптимистично. Концептуальная схема выглядит простой: generator + parameters + target sound + optimizer. Это создало ложное впечатление, что практический inverse mapping должен быть давно решён и доступен в открытых проектах.

Что удалось найти

Формантные/Web Audio демо

Есть множество примеров, где sawtooth/impulse source проходит через несколько band-pass фильтров и получается звук, напоминающий гласную.

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

Pink Trombone / Modular Pink Trombone

Это наиболее интересный из найденных генераторов, потому что:

• звук создаётся процедурно;
• ядро не обязано оперировать буквами;
• состояние голосового тракта можно менять непрерывно;
• реализация работает в браузере;
• можно получать промежуточные звуки вне фиксированного словаря.

Но для нашей задачи не хватает главного:

• нет найденного механизма recording → tract trajectory;
• нет автоматического восстановления траектории параметров из реального МА или любого другого звука;
• качество самого синтеза остаётся заметно синтетическим и не демонстрирует естественную речь даже при ручном управлении.

То есть Pink Trombone даёт генератор, но не дешифратор.

Klatt и Klatt-подобные реализации

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

Причины:

• многие реализации уже строят интерфейс вокруг фонем, ARPABET, пресетов и языковых правил;
• язык и буквы становятся частью архитектуры ядра;
• параметры часто handcrafted;
• качество близко к старым синтезаторам;
• нет универсального inverse mapping из произвольного звука в параметры;
• нет демонстрации автоматического восстановления качественной реальной речи.

Для нас это слишком узкий слой: мы ищем универсальную дешифровку звука, а не таблицу фонем.

LPC / source-filter analysis

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

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

То есть это отдельные части решения, а не готовая система.

Analysis-by-synthesis

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

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

Готового универсального browser-friendly решения нужного качества при этом не найдено.

Neural TTS / codec models

Высокое качество есть, но это другой класс решения:

• внутреннее представление скрыто внутри обученной модели;
• нет явного универсального управляемого VoiceState;
• невозможно использовать систему как прозрачный физический/процедурный генератор;
• это не отвечает исследовательской цели дешифровки звука в компактную понятную программу управления.

Чего не удалось найти

Не найден ни один убедительный открытый технический пример, который одновременно:

1. Берёт реальную запись конкретного звука или короткого слога.
2. Не требует заранее знать букву/фонему/язык.
3. Автоматически восстанавливает компактную временную траекторию параметров.
4. Использует универсальный процедурный генератор, а не neural TTS/codec decoder.
5. Обратно синтезирует звук с качеством, достаточным хотя бы для нормальной узнаваемой речи и заметно лучшим, чем демонстрационные физические синтезаторы.
6. Позволяет увидеть и изучить реализацию дешифровки.
7. Реалистично переносится в браузерный стек.

Это сейчас главный отрицательный результат исследования.

Почему задача оказалась сложной инженерно

Обратная задача неоднозначна

Похожий выходной waveform может быть получен разными внутренними состояниями генератора. Из записи нельзя просто однозначно восстановить один «правильный» набор параметров.

Нужна метрика восприятия, а не просто waveform error

Два waveform могут иметь большую sample-by-sample разницу, но звучать почти одинаково. И наоборот, небольшая ошибка в критической временной или спектральной области может сильно менять восприятие.

Значит, обычный MSE не является достаточной целевой функцией.

Искать нужно не вектор, а траекторию

Звук — динамический процесс. Меняются источник возбуждения, резонансы, шум, атака, закрытия и раскрытия, носовой канал и другие параметры.

Поэтому реальная переменная поиска — временная программа параметров, а не одна статическая точка.

Генератор сам может не уметь воспроизвести нужный звук

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

Голос сложнее нескольких формант

Для качественной речи могут быть существенны glottal source, spectral tilt, aspiration, turbulence, antiresonances, nasal coupling, jitter/shimmer, динамика vocal tract, source-filter interaction и другие механизмы.

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

Ручная настройка не масштабируется

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

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

Уточнённая постановка ключевой проблемы

Главная задача теперь формулируется не как «сделать синтезатор русских букв» и не как «подобрать хорошие пресеты».

Она универсальнее:

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

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

Мета-вывод по работе с LLM

Кейс показал отдельный риск: LLM легко принимают понятную архитектурную декомпозицию за признак низкой инженерной сложности.

Несколько моделей первоначально описывали задачу как практически простую, потому что все компоненты по отдельности знакомы: Web Audio, filters, interpolation, optimization.

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

Только попытка найти конкретный воспроизводимый end-to-end кейс показала, что критический inverse mapping среди найденных решений фактически отсутствует.

Для дальнейшей работы техническую реализуемость нужно проверять минимальными proof-of-feasibility экспериментами, а не уверенностью LLM.

Уточнение вывода поиска существующих реализаций

Поиск внешних проектов был нужен прежде всего для ответа на один вопрос:

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

Прямого подтверждения этому пока не найдено.

Что при этом известно точно

AudioContext способен качественно воспроизвести любой заранее записанный цифровой звук, если передать ему полный массив samples. Значит, проблема не в браузере как среде воспроизведения.

Проблема — в представлении.

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

Поэтому исследуемая граница выглядит так:

полный waveform ← больше данных / выше универсальность ... структурный VoiceScenario → меньше данных / выше управляемость

Нужно понять, где на этой оси появляется качество, достаточное для естественной речи.

Почему найденные проекты не дали ответа

Pink Trombone и похожие физические модели показывают, что можно процедурно генерировать часть voice-like пространства, но:

• они не универсальны;
• в основном демонстрируют гласноподобные состояния и ограниченную артикуляцию;
• звучание остаётся компьютерным;
• нет полноценной демонстрации слогов и качественной связной речи;
• нет обратного декодера запись → компактный сценарий.

Формантные демо ещё уже: они показывают отдельные статические или почти статические звуки, но не отвечают на вопрос о покрытии реальной речи.

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

Neural TTS/codec systems демонстрируют высокое качество, но скрывают внутреннее представление и не дают прозрачного управляемого сценария, который можно исследовать и редактировать.

Новый вывод

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

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

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

Главный объект исследования теперь — компромисс между компактностью структурного описания и perceptual quality.

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

Ключевые выводы:

• Для воспроизведения человеческого голоса достаточно одного аудиоканала (mono): в одной точке пространства давление воздуха описывается одной скалярной временной функцией. Stereo нужно для пространственных признаков, а не для тембра/фонемной разборчивости самого голоса.
• ITU wideband speech: примерно 50–7000 Гц. По Найквисту для сохранения этой полосы нужно >14 кГц sample rate; практический стандарт — 16 кГц. Это даёт raw PCM 16-bit mono = 16,000*16 = 256 кбит/с.
• ITU super-wideband: 50–14,000 Гц; практический sample rate >=32 кГц, raw PCM 16-bit mono = 512 кбит/с. 48 кГц/16-bit mono = 768 кбит/с и уже покрывает fullband человеческой слышимости гораздо шире, чем обычно необходимо для речи.
• Для сжатой речи Opus RFC 6716 указывает sweet spots: 8–12 кбит/с narrowband speech, 16–20 кбит/с wideband speech, 28–40 кбит/с fullband speech.
• G.722 определяет high-quality wideband speech 50–7000 Гц при 64 кбит/с (старый SB-ADPCM codec); современный Opus достигает сопоставимой/лучшей субъективной эффективности при заметно меньшем битрейте.
• Русский OpenSTT (~20 тыс. часов) использует mono, 16 кГц, int16 как основной практический формат; их прежний MP3-профиль был 16 кГц mono 32 кбит/с. Это полезный русский эмпирический baseline, хотя не фундаментальный минимум.

Важно различать bitrate хранения/передачи и сложность синтезатора: один выходной аудиоканал может быть получен из многих внутренних источников/фильтров (glottal source, aspiration, frication, resonances, nasal branch и т.д.). Число внутренних DSP-компонентов не равно числу выходных аудиоканалов.

Web Speech API / SpeechSynthesis как отдельный класс решения

В рамках поиска существующих реализаций проверен встроенный браузерный 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-реализации.

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

Что реально делает API

SpeechSynthesisUtterance принимает текст и настройки вроде языка/голоса, после чего передаёт их встроенному speech engine браузера/операционной системы.

Условная схема:

text
→ SpeechSynthesisUtterance
→ language / voice selection
→ hidden TTS engine
→ audio

Для пользователя доступен результат, но не внутренняя программа формирования звука.

Критичное ограничение 1. Нет прямого управления самим звуком

API принимает текст, а не артикуляционную или акустическую траекторию.

Например:

мама

обычно произносится нормально.

Но попытка написать:

ммммммааамама

не означает для движка:

удерживать /м/
→ плавно перейти в /а/
→ продолжить слог

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

эм-эм-эм-эм... а... ма-ма...

Аналогично:

шшшшшшшш

может превращаться в что-то вроде:

ша-ша-ша-ша...

То есть через этот API нельзя надёжно задать:

• длительность конкретного согласного;
• удержание фонемы;
• плавный переход между звуками;
• форму артикуляционного перехода;
• отдельную временную траекторию шума, voicing, формант и других параметров.

Поэтому API практически не пригоден для экспериментов вида:

М ─────────→ А

где именно сам переход является объектом исследования.

Критичное ограничение 2. Пение и произвольная временная структура

Поскольку входом является текст, а не звуковой сценарий, нельзя свободно задавать:

• растягивание отдельных звуков;
• произвольные длительности слогов;
• мелодическую траекторию каждого звука;
• вокальные переходы;
• нестандартную ритмику;
• нормальное «пение» через прямое управление фонемами.

Изменение общей rate или pitch не решает эту проблему: оно меняет поведение всего utterance, а не даёт управление внутренними звуковыми событиями.

Критичное ограничение 3. Языковая привязка

SpeechSynthesisUtterance опирается на lang и конкретный voice.

Это означает, что движок ожидает текст в рамках некоторой языковой системы.

Проблемными становятся:

• смешение нескольких языков внутри одной фразы;
• произвольные межъязыковые звуки;
• искусственные слова;
• нестандартные последовательности букв;
• звуки, которые вообще не являются словами языка.

Даже если движок пытается что-то произнести, он делает это через собственные правила интерпретации текста, а не как универсальный генератор произвольного звука.

Критичное ограничение 4. Ограничение языковой моделью произношения

Корректнее говорить не только о «словаре» в буквальном смысле, а о более широком ограничении:

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

То есть неизвестную строку он может попытаться прочитать, но это всё равно будет интерпретация как текста, а не прямое воспроизведение заданного акустического объекта.

Для нашей задачи это принципиально важно.

Нам нужен механизм уровня:

sound scenario
→ exact parameter trajectories
→ sound

а здесь используется:

text
→ hidden linguistic interpretation
→ hidden TTS model
→ sound

Критичное ограничение 5. Чёрный ящик

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

Нет доступного представления вида:

initial state
+ timeline
+ source parameters
+ noise parameters
+ resonances
+ transitions

Поэтому SpeechSynthesis не помогает решить центральную задачу исследования:

получить компактное управляемое описание звука и уметь переходить между звуком и этим описанием.

Он демонстрирует только способность системы воспроизводить хорошую речь из текста.

Почему это всё равно полезно зафиксировать

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

Если задача звучит просто как:

текст → нормальная речь

то браузерный API может полностью закрыть её без собственного синтезатора.

Он особенно полезен там, где:

• не требуется управлять отдельными фонемами;
• не нужны нестандартные звуки;
• не нужно пение;
• не требуется дешифровка или доступ к внутреннему представлению;
• достаточно обычного TTS на поддерживаемом языке.

Итог для нашего проекта

SpeechSynthesis показывает, что качественная речь в браузере как конечный результат доступна уже сейчас.

Но он не подходит нам архитектурно, потому что:

1. вход — текст, а не звуковой сценарий;
2. нет точного управления внутренней временной структурой звука;
3. нет нормального управления длительностью отдельных фонем;
4. плохо подходит для пения и произвольных вокальных траекторий;
5. зависит от языка и конкретного voice engine;
6. не является универсальным генератором произвольных звуков;
7. не раскрывает внутреннее представление;
8. не решает обратную задачу sound → scenario.

Поэтому для нашей исследовательской задачи это не конкурент VoiceScenario, а отдельный готовый TTS-инструмент для гораздо более узкого класса задач.