Dlaczego aplikacje do dyktowania zjadają pierwsze słowo

Naciśnij skrót. Zacznij mówić. Popatrz, jak transkrypt zaczyna się od drugiego słowa — czasem od trzeciego. „Zrefaktoryzuj logikę ponawiania” wychodzi jako „logikę ponawiania”. „Nie mergeuj tego jeszcze” wychodzi jako „mergeuj to jeszcze”, co jest naprawdę niebezpiecznym zdaniem do wpisania w Twoim imieniu. Tę awarię łatwo odtworzyć w potokach mikrofonowych z zimnym startem, od narzędzi wbudowanych w system po dedykowane aplikacje do dyktowania.

Ludzie opisują to różnie — „ucina początek”, „muszę zrobić pauzę przed mówieniem”, „pierwszego słowa zawsze brakuje” — ale to jedno zjawisko, a gdy raz Cię ugryzie, wypracowujesz obejście, które wypracowują wszyscy: naciśnij klawisz, odczekaj chwilę, potem mów. Co znaczy, że wykonujesz teraz mały przesądny rytuał kilkadziesiąt razy dziennie, żeby zrekompensować swoje narzędzie, a to narzędzie wytresowało Ciebie, a nie odwrotnie.

Robiłem ten rytuał przez miesiące w innych narzędziach. Przy budowaniu Keebye jego zabicie było jedną z pierwszych rzeczy na liście, bo lekarstwo okazało się wymagać niewygodnego kompromisu, na który większość aplikacji nie pójdzie — i chcę mówić o tym kompromisie tak wprost jak o samym lekarstwie.

Dlaczego pierwsze słowo zostaje ucięte?

To problem na poziomie kategorii, a nie niechlujstwo jednego dostawcy, a jego fizyka jest prosta: mikrofony nie są natychmiastowe.

Kiedy aplikacja do dyktowania zaczyna nagrywanie w naiwny sposób — naciśnij skrót, a potem otwórz mikrofon — cały łańcuch musi się wykonać, zanim zostanie przechwycona pierwsza próbka Twojej mowy. Sesja audio systemu musi się zainicjować. Urządzenie wejściowe musi się obudzić, co dla części sprzętu oznacza dosłowny czas rozgrzewania. Format strumienia jest negocjowany, alokowane są bufory, a pierwsze przychodzące bufory to często śmieci, które się odrzuca. Zależnie od maszyny i urządzenia ten łańcuch trwa od „chwili” do paru sekund.

Tymczasem Ty — człowiek z już uformowaną myślą — zaczynasz mówić w chwili, gdy palec dotyka klawisza. Zwykle właściwie o włos przed tą chwilą: zamiar naciśnięcia i zamiar mówienia wychodzą z mózgu razem, a początek mowy rutynowo wyprzedza gotowość aplikacji. Wszystko, co powiedziałeś, zanim strumień ożył, nigdy nie istniało z punktu widzenia aplikacji. Model nie może przetranskrybować dźwięku, którego nigdy nie przechwycono. Stąd: „logikę ponawiania”.

Dlaczego aplikacje włączają mikrofon na żądanie, zamiast trzymać go gotowego? Głównie z przyzwoitości. Trzymanie otwartego mikrofonu kosztuje trochę energii, a — co dużo ważniejsze — zapala systemowy wskaźnik mikrofonu, który użytkownicy zrozumiale odczytują jako „ta aplikacja mnie słucha”. Otwieranie mikrofonu tylko na żądanie utrzymuje wskaźnik uczciwym, a aplikację grzeczną. Kosztem jest ryzyko zimnego startu na początku nagrania.

Lekarstwo: mikrofon, który już słucha, gdy naciskasz klawisz

Keebye atakuje to z obu stron, a te dwa mechanizmy warto rozdzielić, bo rozwiązują dwie różne połowy problemu.

Ciepły mikrofon. Po pierwszym nagraniu w sesji Keebye trzyma strumień wejścia audio otwarty. To znaczy, że łańcuch zimnego startu — inicjalizacja sesji, wybudzenie urządzenia, negocjacja strumienia — wykonał się już przed późniejszym dyktowaniem, dopóki ten strumień pozostaje sprawny. Strumień jest żywy, zanim ruszy Twój palec.

Pre-roll. Ciepły strumień naprawia spóźnienie aplikacji, ale nie Twoje — pamiętaj, początek Twojej mowy może wyprzedzić naciśnięcie klawisza. Keebye trzyma więc kroczący bufor 500 milisekund najnowszego dźwięku (8000 próbek przy 16 kHz, w buforze cyklicznym). Gdy naciskasz skrót, ta półsekunda dźwięku sprzed naciśnięcia jest wypychana na początek wypowiedzi. Dźwięk, który zaczął się wewnątrz tego bufora, jest dostępny dla transkrybera, zamiast zostać odrzucony przed naciśnięciem klawisza.

Efekt łączny: przy powtórnych dyktowaniach ciepły strumień i 500 ms pre-rollu pokrywają typowy przypadek, w którym mowa zaczyna się tuż przed naciśnięciem klawisza albo razem z nim. Rytualna pauza staje się w tych granicach niepotrzebna. Nie odzyska słowa wypowiedzianego ponad pół sekundy przed startem nagrywania, a pierwsze dyktowanie w sesji wciąż płaci normalne opóźnienie startu strumienia.

Kompromis, powiedziany wprost

Oto część, której odmawiam zakopania, bo to uczciwa cena tego projektu: skoro strumień audio zostaje otwarty między dyktowaniami, macOS pokazuje mikrofon jako aktywny nawet wtedy, gdy nie dyktujesz. Pomarańczowa kropka się świeci. Jeśli zajrzysz do Centrum sterowania, Keebye jest tam wymienione jako używające mikrofonu, właśnie w tej chwili, gdy nic nie robisz.

Co się w tym czasie naprawdę dzieje: dźwięk płynie do 500-milisekundowego bufora cyklicznego i jest ciągle odrzucany. Nic nie jest transkrybowane. Nic nie jest przechowywane. Nic nie opuszcza bufora, dopóki nie naciśniesz klawisza — a wszystko starsze niż pół sekundy jest bezpowrotnie stracone, nadpisane przez bufor. Ale nie zamierzam udawać, że wskaźnik kłamie, bo nie kłamie: strumień jest otwarty, a „zdolny do ciągłego słuchania” to uczciwy opis tej architektury, mimo że nic nie słucha w żadnym sensownym sensie, dopóki nie poprosisz.

Poszedłem na ten kompromis świadomie, z otwartymi oczami, i oto uzasadnienie. Otwieranie mikrofonu na żądanie wprowadza za każdym razem ryzyko zimnego startu: ucięte słowa, złe zdania, wytresowaną pauzę. Projekt z ciepłym strumieniem ma koszt, który spada na Twój komfort z pomarańczową kropką, podparty architekturą, którą możesz przemyśleć: lokalna historia zawierająca sam tekst (którą opisaliśmy w Twoje dyktowanie nigdy nie powinno po prostu zniknąć), transkrypcja na urządzeniu, żaden dźwięk nigdy nieprzechowywany, pół sekundy pamięci w buforze. Ja biorę tę kropkę. Jeśli Ty nie weźmiesz — to uzasadnione stanowisko i może naprawdę sprawić, że właściwym wyborem będzie dla Ciebie inne narzędzie; nasze strony Keebye vs Superwhisper i Keebye vs Wispr Flow są napisane tak, żeby pomóc dokładnie w tej decyzji.

Dwie granice, żeby nikt się nie zdziwił

Pierwsze dyktowanie w sesji wciąż ma normalne opóźnienie startu strumienia. Mikrofon jest ciepły, bo nagranie już się odbyło; to pierwsze wciąż płaci koszt konfiguracji. Późniejsze dyktowania korzystają, dopóki strumień pozostaje otwarty.

Pre-roll to 500 milisekund, a 500 milisekund to chwila, nie zdanie. Bufor pokrywa naturalny przypadek — słowo zaczęte nieco przed naciśnięciem klawisza. Jeśli wygłosisz całe zdanie, a dopiero potem przypomnisz sobie o klawiszu, wcześniejsze słowa przepadły, i to z założenia: bufor cykliczny trzyma zawsze tylko pół sekundy, właśnie po to, by aplikacja nie zatrzymywała znaczącego dźwięku, gdy nic nie robi. Dłuższy pre-roll łapałby więcej Twoich roztargnionych startów i trzymałby w pamięci więcej dźwięku otoczenia. Pół sekundy to miejsce, w którym postawiłem tę granicę.

Dlaczego pół sekundy znaczy więcej, niż brzmi

Ucięte pierwsze słowo wygląda na drobny błąd. W pracy na równoległych torach, pod którą zbudowano Keebye — głos jako kanał sterowania kilkoma agentami AI i kilkoma rozmowami z ludźmi naraz, dzień pracy opisany w Dwoje dzieci, trzy startupy, jeden głos — dyktowanie zdarza się kilkadziesiąt razy dziennie, seriami, w środku przełączania kontekstu. Narzędzie, które domaga się rytualnej pauzy, opodatkowuje każdą serię, a co gorsza, od czasu do czasu odwraca Twój sens i go wysyła. „Mergeuj to jeszcze” było zabawne dokładnie raz.

Niezawodność w tej kategorii nie jest jedną wielką funkcją. Jest sumą mniejszych zabezpieczeń: pre-roll na otwierający dźwięk, historia za transkryptem i odzyskiwalna ścieżka wstawiania. Ten tekst jest o pierwszym z nich; tekst o historii obejmuje drugie.

Keebye jest we wczesnym dostępie na macOS. Zacznij bezpłatny okres próbny poniżej, powiedz „Nie mergeuj tego jeszcze” przy powtórnym dyktowaniu i sprawdź, czy pierwsze słowo przetrwa. To cały test.