Конвейеры записи и транскрипции: где аудио покидает звонок

Кратко

Живой звонок держит голос каждого участника на собственном пути, чтобы разговор ощущался мгновенным, но как только вам нужна запись или транскрипт, это аудио должно покинуть звонок и пойти по второму конвейеру, который почти никто не проектирует осознанно. Этот второй конвейер может начаться ровно в трёх местах – на устройстве самого говорящего (на клиенте), на сервере с раздельными голосами (на сервере, по участникам) или на сервере с голосами, сведёнными в один (на сервере, в миксе), – и каждый вариант по-своему меняет цену, качество и юридический риск. Для транскрипции аудио делает ещё один шаг: движок распознавания речи выбрасывает звук уровня записи и оставляет лишь урезанный отпечаток – лог-мел-спектрограмму, поэтому транскрипт и запись сделаны из одного голоса, но это никогда не один и тот же файл. Эта статья проводит аудио от микрофона к сохранённому файлу и к субтитру на экране, показывает арифметику стоимости каждой ветки и даёт вопросы, которые стоит задать до того, как аудио покинет ваш звонок.

Почему это важно

Если вы ведёте телемедицинскую платформу, онлайн-класс, контакт-центр или любой конференц-продукт, то функции записи и транскрипции – те, что клиенты просят первыми, и те, на которые инженеры закладывают меньше всего ресурсов. Живой звонок настроен на минимальную задержку; запись и транскрипция – совершенно другая задача с совершенно другой кривой стоимости, и команды регулярно прикручивают их сбоку, не осознавая, что только что удвоили счёт за серверы или тихо создали папку с незашифрованным аудио пациентов. Эта статья – для продакт-менеджера, основателя или операционного руководителя, которому нужно понять, куда уходит аудио после того, как покидает живой звонок, чтобы читать архитектуру записи, спрашивать, почему она микширует или нет, и видеть, какая ветка создаёт проблему соответствия требованиям до того, как её найдёт регулятор. Старший инженер тоже найдёт здесь каждое утверждение со ссылкой на спецификацию W3C MediaStream Recording, на соответствующие IETF RFC и на опубликованное поведение Whisper, WhisperX, LiveKit Egress и крупных API транскрипции в реальном времени. К концу вы будете знать три ветки записи, улицу с односторонним движением, превращающую голос в транскрипт, и точный момент, когда каждый выбор перестаёт быть дешёвым.

Звонок и копия – это две разные задачи

Удержите одну мысль прежде всего остального, потому что на ней держится вся статья. У живого звонка одна задача: доставить мой голос к вашему уху как можно быстрее. Всё в конвейере аудио реального времени – буфер джиттера, маскировка потерь пакетов, прерывистая передача, которая перестаёт слать, когда вы замолкаете, – существует, чтобы экономить миллисекунды и пережить плохую сеть. Никому из них не важно хранить идеальную копию. Это построено, чтобы услышать один раз и забыть.

У записи задача обратная: сохранить точную копию, которую кто-то воспроизведёт позже, возможно в суде, возможно через годы. У транскрипта снова третья задача: превратить звук в слова и звук выбросить. Это три разные задачи с тремя разными определениями «хорошо», и аудио, идеальное для одной, неправильно для других. Живое аудио, которое отбросило тихие полсекунды ради экономии полосы, нормально слушать и плохо транскрибировать. Запись, оптимизированная под размер хранения, нормальна для архива и проблемна для старой телефонной линии.

Поэтому вопрос, на который отвечает эта статья, – не «как записать звонок», а «где аудио покидает живой путь и что с ним происходит после». Эта развилка – самое важное архитектурное решение в функции записи, и большинство команд принимают его случайно.

Нажмите, чтобы увеличить

Ветка первая: запись на клиенте (аудио не покидает устройство)

Самое простое место для захвата звонка – устройство, которое его уже воспроизводит. Браузер даёт для этого готовый инструмент – MediaRecorder, встроенный рекордер, определённый в спецификации W3C MediaStream Recording, который берёт живой аудио- или видеопоток и пишет его в файл без участия сервера. Вы направляете его на тот же поток микрофона, что и звонок, жмёте «старт», и он отдаёт вам куски закодированного файла по ходу дела.

Две детали этой спецификации важны для всех, кто проектирует функцию вокруг неё. Во-первых, рекордер по умолчанию не отдаёт весь файл целиком в конце. Можно попросить выдавать запись кусками, передав значение timeslice – число миллисекунд, после которых он порождает событие dataavailable с очередным куском записи в виде Blob. timeslice в 1000 означает «отдавай мне кусок записи каждую секунду». Так клиентский рекордер выгружает длинный звонок по ходу, а не держит весь файл в памяти до конца. Спецификация прямо предупреждает, что слишком большой timeslice заставляет браузер буферизовать большой объём данных – это хрестоматийный способ уронить вкладку браузера длинной записью.

Во-вторых, выбирать любой формат аудио нельзя. Рекордер пишет тот контейнер и кодек, что поддерживает браузер, объявленные через mimeType – обычно контейнер WebM с аудио Opus, тем же кодеком, что уже использует живой звонок. Список идентификаторов кодеков, определённый W3C, включает opus и pcm, но какие из них реально доступны – решает браузер, а не вы.

Чего стоит запись на клиенте

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

Издержек три, и из-за них запись на клиенте редко переживает встречу с реальным продуктом. Во-первых, она ломается в момент закрытия вкладки. Если человек ушёл со страницы, обновил её или ноутбук уснул – запись останавливается, и то, что было в буфере, может пропасть. Во-вторых, она захватывает взгляд только одного человека. Клиентская запись на моём устройстве содержит мой микрофон и микс аудио, который я получил; это не чистая отдельная копия каждого участника. В-третьих, она не масштабируется на многих участников – каждое устройство пишет свою копию, значит много частичных файлов нужно собрать, согласовать и сшить, а клиентские подходы, по широко описанному опыту, разваливаются выше пары сотен участников. Запись на клиенте – правильный ответ для одного пользователя, фиксирующего свою сессию, и неправильный для всего, что нужно гарантировать.

Ветка вторая: запись на сервере по участникам (держим каждый голос отдельно)

Как только вы ставите сервер в путь аудио – а выше горстки участников вы делаете это всегда, почти всегда Selective Forwarding Unit (SFU), – у вас появляется второе, куда более надёжное место для захвата. SFU уже получает голосовой поток каждого участника. Запись на сервере по участникам просто велит серверу писать каждый из этих потоков в свой файл.

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

Есть важная тонкость в том, как сервер захватывает эти потоки. SFU пересылает аудио без декодирования – в этом весь смысл SFU, он никогда не превращает сжатые пакеты обратно в звук. Поэтому у рекордера по участникам два варианта. Он может хранить сырые пересланные пакеты как есть – это дёшево, но даёт файл с зашитыми пробелами и причудами живого потока, включая тихие участки, оставленные DTX. Или он может подписаться на каждую дорожку как участник, декодировать её и писать непрерывный чистый файл – это стоит CPU, но даёт запись, которую реально можно воспроизвести и надёжно транскрибировать. Продакшн-системы, обещающие пригодную запись, делают второе.

Цена раздельного хранения голосов

Запись по участникам стоит хранения и оркестрации, а не CPU на микширование. Каждый говорящий – отдельный файл, поэтому хранение растёт линейно с числом говорящих. Для инструмента вроде сервиса LiveKit Egress отдельный компонент записи входит в комнату как скрытый участник, подписывается только на нужные дорожки и пишет их – поэтому запись на SFU никогда не бесплатна, хотя живая пересылка была. Вы платите за второго потребителя каждого потока.

Цифры важны, когда звонки длинные. Одна голосовая дорожка Opus на типичных 32 тысячах бит в секунду даёт за час:

32 000 бит/с ÷ 8 бит/байт = 4 000 байт/с
4 000 байт/с × 3 600 с = 14 400 000 байт ≈ 14,4 МБ в час

Это один говорящий. Звонок на четверых, записанный по участникам, – четыре таких файла, около 57,6 МБ в час, плюс любое сохранённое видео. Умножьте на каждый записываемый звонок, каждый день, хранимый столько, сколько требуют ваши правила соответствия, – и налог за запись по участникам станет реальной статьёй расходов. Подробная версия этой арифметики – по нескольким языкам и кодекам – в статье Стоимость хранения и CDN для аудио.

Ветка третья: запись на сервере в миксе (сводим все голоса в один)

Третья ветка – та, что большинство представляет, говоря «запиши звонок»: один файл с голосами всех, готовый играть в любом плеере. Чтобы его выдать, сервер должен сделать дорогое, от чего SFU обычно отказывается, – декодировать аудио каждого участника обратно в сырой звук, сложить звуки в один микс и заново закодировать микс в один файл. Это та же работа «декодировать-смешать-перекодировать», что делает Multipoint Control Unit (MCU), чтобы вести звонок, применённая здесь только к записи.

Выход – самый удобный возможный артефакт. Один файл играет где угодно. Нет сшивания, нет согласования меток времени между дорожками, нет клиента для координации. Для архива вебинара, записи в стиле подкаста или любого случая, где человек просто нажмёт «play», запись в миксе – естественный выбор. Это ещё и единственный формат, который потянет «тупой» потребитель: если вашу запись должна воспроизвести система, способная управлять ровно одним аудиопотоком, микширование обязательно.

Почему запись в миксе – дорогая ветка

За удобство платят CPU и потерянной информацией, и оба платежа необратимы. Цена CPU – декодирование и перекодирование каждого потока, непрерывно, весь звонок, та же нагрузка, что делает MCU куда дороже SFU в расчёте на комнату. Запись room-composite у LiveKit, например, буквально запускает экземпляр headless Chrome, который входит в комнату, рисует раскладку и кодирует результат через GStreamer; это целый браузер на запись, а не дешёвое копирование байтов.

Информационная цена хуже, потому что её не отменить. Как только четыре голоса сложены в одну форму волны, их уже никогда не разделить начисто. Нельзя надёжно транскрибировать «кто что сказал» из микса – можно лишь догадываться диаризацией говорящих, а это сам по себе ошибочный лишний шаг (подробнее ниже). Нельзя приглушить одного человека. Нельзя отредактировать одного участника без перезаписи. Любая последующая функция, которой нужно знать, кто говорил, теперь борется с форматом, намеренно выбросившим эту информацию.

Это самая частая ошибка записи, что мы видим: команда выбирает запись в миксе, потому что это лёгкое демо, выкатывает её, а потом клиент просит потранскриптам по говорящим или возможность убрать одного участника ради приватности – и ответ «нам пришлось бы переделать архитектуру записи». Решите, нужна ли вам информация по говорящим, до микширования, потому что микширование – дверь в одну сторону.

«Подводный камень: сюрприз микса с молчащим микрофоном. Запись в миксе на звонке с DTX может дать файл, где у дорожки говорящего есть пробелы – DTX перестаёт передавать в тишине ради экономии полосы, а наивный микшер пишет эти пробелы как мёртвый эфир или резкий скачок. Корректный микшер записи вставляет комфортный шум или удерживает уровень через пробелы DTX. Если ваши записи звучат так, будто люди пропадают на паузах, подозревайте стык DTX и микса, а не микрофоны.»

Сравнение трёх веток записи

Закономерность в этой таблице – всё решение целиком. Если человек нажмёт «play» и знать, кто говорил, не нужно, – сводите. Если запись прочитает машина, или ею может заинтересоваться регулятор, или вам нужно что-либо по говорящим – держите голоса отдельно и платите за хранение. Если это один человек, фиксирующий свою сессию, и надёжность неважна, – делайте на устройстве.

Развилка внутри развилки: запись против транскрипции

До сих пор мы шли за аудио, которое остаётся аудио. Транскрипция – другой пункт назначения, и аудио, идущее туда, делает поворот, удивляющий большинство: движок распознавания речи не хочет вашу красивую запись. Ему нужно что-то меньше, грубее и заточенное под машину, и он делает эту форму, намеренно разрушая почти всё, из-за чего запись хорошо звучит.

Это стоит сказать прямо, потому что переосмысляет всю функцию. Запись и транскрипт – не один файл на разных уровнях качества. Это два продукта одного голоса, расходящиеся рано и больше не встречающиеся. Ветка записи пытается сохранить звук. Ветка транскрипции пытается извлечь слова и звук намеренно выбрасывает.

Как аудио становится текстом: путь аудио в ASR

Автоматическое распознавание речи, ASR (automatic speech recognition) – технология, превращающая произнесённое аудио в письменные слова, – прогоняет аудио по короткому конвейеру до того, как вообще случится какое-либо «распознавание». Понимание этого конвейера объясняет, почему транскрипт может быть неверен, даже когда запись звучит идеально, и почему аудио для ASR нужно готовить иначе, чем аудио для архива.

Шаг первый: ресемплинг до 16 кГц

Живой звонок WebRTC почти всегда несёт аудио Opus. Внутри, как задаёт RFC 6716, Opus гоняет своё основное преобразование на 48 тысячах отсчётов в секунду – высокой частоте, что охватывает весь диапазон слуха, именно то, что нужно музыке и точной записи. Распознаванию речи это не нужно. Человеческая речь живёт почти целиком ниже 8 тысяч колебаний в секунду, а фундаментальный результат цифрового аудио (см. Что такое цифровой звук) гласит, что нужно сэмплировать лишь вдвое выше высшей интересной частоты. Поэтому почти каждый современный движок ASR – Whisper в том числе – сначала ресемплирует аудио вниз до 16 тысяч отсчётов в секунду. Всё выше 8 кГц выбрасывается. Для музыки это был бы вандализм; для речи это бесплатно, потому что слов там никогда и не было.

Шаг второй: режем аудио на крошечные перекрывающиеся кадры

Дальше движок рубит 16-кГц аудио на очень короткие перекрывающиеся окна. Whisper, широко используемая открытая модель речи от OpenAI, использует окно в 25 миллисекунд, сдвигающееся вперёд на 10 миллисекунд за раз. Каждое окно достаточно коротко, чтобы звук внутри был примерно стабилен – отдельный фрагмент гласной или согласной, а не целое слово. Сдвиг в 10 миллисекунд означает, что окна перекрываются, поэтому ничего не проваливается в щели между кадрами. Это та же идея кадров и пакетов, что лежит под всем цифровым аудио, разобранная в статье Кадры, пакеты, гранулы; ASR просто использует свой размер кадра, настроенный на ритм речи.

Шаг третий: превращаем каждый кадр в лог-мел-спектрограмму

Вот шаг, выбрасывающий звук. Каждый крошечный кадр превращается из волны во времени в меру того, сколько энергии сидит в каждой полосе частот, затем эти полосы сжимаются на перцептивную шкалу, а их громкость сжимается логарифмом. Результат называется лог-мел-спектрограммой, и именно она – настоящий вход модели распознавания, а не аудио.

Часть «мел» – это шкала частот, построенная под человеческий слух, а не под физику. Наши уши различают низкие тона куда лучше высоких, поэтому мел-шкала упаковывает много узких полос внизу и несколько широких вверху, расставляя их так, как мы реально воспринимаем высоту. Whisper использует 80 таких мел-полос. Часть «лог» сжимает диапазон громкости так же, как наши уши, так что шёпот и крик оказываются ближе, чем подсказала бы их сырая энергия, – то же логарифмическое восприятие, что лежит под измерением громкости в LUFS.

Сложите цифры – и видно, сколько именно выброшено. Whisper обрабатывает аудио кусками по 30 секунд. При шаге кадра в 10 миллисекунд 30 секунд – это 3 000 кадров, и каждый кадр описывается 80 мел-числами:

30 с ÷ 0,010 с/кадр = 3 000 кадров
3 000 кадров × 80 мел-полос = 240 000 чисел на кусок в 30 с

30-секундный отрезок 16-кГц аудио – это 480 000 сырых отсчётов на секунду моно, то есть 14,4 миллиона отсчётов за 30 секунд. Лог-мел-представление описывает те же полминуты 240 000 числами. Движок сжал звук примерно в шестьдесят раз и, что важно, сжатие одностороннее. Лог-мел-спектрограмму нельзя превратить обратно в слышимое аудио. Транскрипт построен из отпечатка голоса, а не из голоса.

Почему лог-мел, а не более старый MFCC

Если читать старые материалы по распознаванию речи, встретится близкий родственник – MFCC (mel-frequency cepstral coefficients), добавляющий ещё один математический шаг (дискретное косинусное преобразование) поверх лог-мел-спектрограммы, чтобы сжать и декоррелировать её сильнее. Десятилетиями MFCC были непререкаемым стандартом. Современные ASR на глубоком обучении, Whisper среди них, отбросили этот последний шаг и подают лог-мел-спектрограмму напрямую. Причина проста: большая нейросеть достаточно мощна, чтобы выучить закономерности сама, поэтому подача менее обработанных лог-мел-признаков даёт ей найти корреляции, которые фиксированная математика MFCC выбросила бы. Тренд в области – кормить модель меньшим количеством рукотворного аудио, а не большим.

Нажмите, чтобы увеличить

Кто это сказал? Диаризация – шаг, который микс делает трудным

Транскрипт, читающийся как сплошная стена текста, куда менее полезен, чем тот, где перед каждой строкой стоит «Д-р Ли:» и «Пациент:». Понять, кто говорил каждый отрезок, – отдельная задача от того, что было сказано, и у неё своё имя: диаризация говорящих – разбиение аудио на отрезки и пометка каждого говорящим. Инструменты диаризации вроде pyannote и NeMo выдают ответ в стандартном формате RTTM, который просто перечисляет для каждого отрезка время начала, длительность и метку говорящего. Конвейер вроде WhisperX затем сливает эту временную шкалу с тайм-кодами слов Whisper, чтобы каждое слово несло метку говорящего.

Теперь решение о записи из начала возвращается, чтобы укусить. Если вы записали по участникам, диаризация не нужна вовсе – каждая дорожка есть один говорящий, поэтому «кто что сказал» уже отвечено идеально и бесплатно. Если вы записали в миксе, говорящие смешаны в одну форму волны, и диаризации приходится восстанавливать границы на слух, а это ошибочно: она путает похожие голоса, спотыкается на перекрывающейся речи, добавляет задержку и стоимость. Это конкретная последующая цена микширования, на которую намекала таблица сравнения. Выбор записи по участникам – это, среди прочего, выбор никогда не иметь проблемы диаризации.

Другие часы: субтитры в реальном времени

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

Это вынуждает дизайн, общий для всех систем транскрипции реального времени: частичные и финальные результаты. Частичный результат – лучшая догадка движка на данный момент, показанная сразу и допускающая изменение по мере прихода аудио; финальный результат – зафиксированный транскрипт законченного отрезка речи. Субтитр, что обновляется по слову, – это частичные; версия, что перестаёт дрожать и остаётся, – финальная. Промышленные движки реального времени обычно выдают частичные за 200–500 миллисекунд, а финальные – на пару сотен миллисекунд позже паузы говорящего, при этом частичные менее 300 миллисекунд и финальные около 700 миллисекунд – частый ориентир на коротких высказываниях.

В этом тайминге зашит настоящий компромисс, и его стоит понять до того, как задавать ожидания пользователям. Показать частичный быстрее – значит показать менее уверенную догадку, что может на глазах исправиться. Ждать финальный – значит более устойчивый субтитр, отстающий сильнее. Живые субтитры доступности обычно выбирают скорость и терпят редкое самоисправление, потому что субтитр, пришедший после момента, хуже того, что себя поправляет. Юридический транскрипт выбирает финальный и принимает отставание. Тот же движок умеет и то, и другое; какие часы он включит, решает продукт.

«Подводный камень: кормить субтитратор аудио, прореженным DTX. Конвейер реального времени, отводящий живой поток, оптимизированный под полосу, наследует его компромиссы. Если живой поток использовал агрессивный DTX или тяжёлую маскировку потерь пакетов, субтитратор видит аудио с придуманными или пропавшими фрагментами и выдаёт уверенную чепуху. Там, где точность субтитров важна, отводите поток ASR от более чистой копии – декодированной дорожки по участнику, а не сырых пересланных пакетов.»

Куда аудио реально уходит после ухода: ветка соответствия

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

Два факта, которые должна знать каждая команда, делающая запись. Во-первых, согласие не единообразно. В США закон о согласии на запись делится по штатам: большинство допускает согласие одной стороны (достаточно одного участника звонка), но примерно дюжина штатов требует согласия всех сторон до записи звонка. Продукт, записывающий по умолчанию, может быть законен в одном штате и преступлением в другом. Безопасный дизайн – объявлять и фиксировать согласие всех, каждый раз. Во-вторых, хранимый голос – регулируемые данные. По GDPR ЕС запись – это персональные данные: согласие должно быть свободным и конкретным, люди могут запросить копию или удаление, а запись должна удаляться, когда больше не нужна. В здравоохранении запись, содержащая защищённую медицинскую информацию, должна шифроваться при передаче и в покое, иметь контроль доступа и храниться по применимым правилам хранения – например, шесть лет по HIPAA против «удалить, когда больше не нужно» у GDPR.

Архитектурный вывод конкретен: конвейер записи не завершён, когда файл записан. Ему нужны шифрование в покое, контроль доступа, политика хранения и удаления, способная исполнить запрос на удаление, и журнал аудита. Записи в миксе делают удаление одного участника невозможным по построению – это проблема GDPR в зародыше. Записи по участникам делают удаление по человеку чистым. Юридическая рамка должна влиять на выбираемую ветку записи, а не прикручиваться постфактум.

Где здесь Фора Софт

Мы делаем продукты, где этот конвейер несущий: телемедицинские платформы, где каждой консультации может понадобиться соответствующая требованиям, зашифрованная запись по говорящим; системы e-learning, где лекции записываются и автоматически субтитрируются ради доступности; сервисы видеоконференций и контакт-центров, где транскрипция и поиск по записям – ключевые функции; и видеонаблюдение, где захват аудио несёт свои правила согласия. Во всех этих вертикалях повторяется урок этой статьи – решите, где аудио покидает звонок и останется ли оно раздельным или будет сведено, до того, как писать функцию записи, потому что качество транскрипции, счёт за хранение и положение по соответствию – всё следует из этой одной развилки. Когда мы оцениваем функцию записи или транскрипции, разговор об архитектуре начинается там, а не с кодека.

Главное

• Живой звонок и его запись – две разные задачи с разным определением «хорошо».
• Аудио может покинуть звонок в трёх местах: устройство, сервер с раздельными голосами, сервер со сведением.
• Микширование – дверь в одну сторону: теряете «кто что сказал» и возможность отредактировать одного.
• Запись по участникам – сильнейший вход для транскрипции и чистейший для соответствия требованиям.
• ASR выбрасывает звук: ресемплинг до 16 кГц и только 80-полосный лог-мел-отпечаток.
• Живые субтитры идут на частичных (200–500 мс) и финальных; хранимый файл – регулируемые данные.

Что почитать дальше

• Аудио в SFU, MCU и P2P – архитектура, что решает, дешёвой будет запись или дорогой.
• VAD и DTX: детектор речевой активности и прерывистая передача – почему у записи живого звонка бывают пробелы.
• Стоимость хранения и CDN для аудио – арифметика налога за хранение по участникам.