Почему приложения диктовки съедают ваше первое слово

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

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

Я исполнял этот ритуал месяцами в других инструментах. Когда я делал Keebye, избавиться от него было одним из первых пунктов списка, потому что решение потребовало неудобного компромисса, на который большинство приложений не идёт, — и об этом компромиссе я хочу говорить так же прямо, как о самом решении.

Почему первое слово обрезается

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

Когда приложение диктовки начинает запись наивным способом — сначала нажатие горячей клавиши, потом открытие микрофона, — до захвата первой выборки вашей речи должна отработать целая цепочка. Нужно инициализировать аудиосессию ОС. Нужно разбудить устройство ввода, а для части железа это буквально время прогрева. Согласуется формат потока, выделяются буферы, и первые пришедшие буферы часто оказываются мусором, который отбрасывается. В зависимости от машины и устройства эта цепочка занимает от «мгновения» до пары секунд.

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

Почему приложения включают микрофон по требованию, а не держат его наготове? В основном из добропорядочности. Держать микрофон открытым стоит немного энергии и — что гораздо важнее — зажигает системный индикатор микрофона, который пользователи вполне обоснованно читают как «это приложение меня слушает». Открытие микрофона только по требованию оставляет индикатор честным, а приложение — вежливым на вид. Ценой становится риск холодного старта в начале записи.

Решение: микрофон, который уже слушает, когда вы жмёте клавишу

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

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

Пред-запись. Прогретый поток чинит опоздание приложения, но не ваше — вспомните, что начало речи может опережать нажатие. Поэтому Keebye держит скользящий буфер последних 500 миллисекунд звука (8000 выборок при 16 кГц, в кольце). Когда вы нажимаете горячую клавишу, эта половина секунды «звука до» вливается в начало фразы. Звук, начавшийся внутри этого буфера, доступен распознавателю, а не отбрасывается до нажатия.

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

Компромисс, сказанный прямо

Вот часть, которую я отказываюсь прятать, потому что это честная цена такой конструкции: поскольку аудиопоток остаётся открытым между диктовками, macOS показывает микрофон активным даже тогда, когда вы не диктуете. Оранжевая точка горит. Если заглянуть в Пункт управления, Keebye будет там указан как использующий микрофон — прямо сейчас, пока вы ничего не делаете.

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

Я пошёл на этот компромисс сознательно, с открытыми глазами, и вот рассуждение. Открытие микрофона по требованию каждый раз вносит риск холодного старта: обрезанные слова, неверные фразы, выдрессированная пауза. У конструкции с прогретым потоком цена ложится на ваш комфорт рядом с оранжевой точкой, но её подкрепляет архитектура, которую можно продумать: локальная история только в виде текста (о ней мы написали в статье ваша диктовка не должна просто исчезать), распознавание на устройстве, звук нигде не сохраняется, полсекунды кольцевой памяти. Я согласен на точку. Если вы не согласны — это законная позиция, и вполне возможно, что вам подойдёт другой инструмент; наши страницы Keebye vs Superwhisper и Keebye vs Wispr Flow написаны как раз в помощь такому выбору.

Две границы, чтобы никто не удивился

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

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

Почему полсекунды значат больше, чем кажется

Обрезанное первое слово выглядит мелким багом. В рабочем процессе с параллельными дорожками, ради которого создавался Keebye, — голос как канал управления сразу несколькими ИИ-агентами и несколькими человеческими разговорами, тот самый день, описанный в статье двое детей, три стартапа, один голос, — диктовка случается десятки раз в день, короткими очередями, в момент переключения контекста. Инструмент, требующий ритуальной паузы, облагает налогом каждую очередь и, что хуже, иногда переворачивает смысл сказанного и отправляет его. «Мерджи это пока» было смешно ровно один раз.

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

Keebye находится в раннем доступе для macOS. Начните бесплатный пробный период ниже, скажите «Не мерджи это пока» на повторной диктовке и проверьте, уцелеет ли первое слово. Вот и весь тест.