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

Кратко

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

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

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

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

Если вы управляете телемедицинской платформой, онлайн-курсом, контакт-центром или любым конференц-продуктом, функции записи и транскрипции – это то, о чём чаще всего просят клиенты, и то, на что инженеры тратят меньше всего ресурсов. Прямой звонок оптимизируется под минимальную задержку; запись и транскрипция – совершенно другая задача с иной кривой затрат, и команды зачастую подключают их как дополнение, не осознавая, что удваивают расходы на серверы или создают папку с незашифрованным аудио пациентов. Эта статья предназначена для продуктового менеджера, основателя или операционного руководителя, которому важно понять, куда уходит аудио после завершения звонка, как устроена архитектура записи, почему она микширует или не микширует потоки, и какая ветка может вызвать проблемы с соответствием требованиям до того, как их обнаружит регулятор. Старший инженер найдёт здесь каждое утверждение с ссылкой на спецификацию 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) при проведении звонка, только здесь она применяется исключительно к записи.

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

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

За удобство приходится платить 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 отсчётов на секунду в моно, то есть за 30 секунд – 14,4 миллиона отсчётов. Лог-мел-спектрограмма описывает те же полминуты всего 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 для аудио – арифметика расходов на хранение по участникам.