Kenapa Aplikasi Dikte Memakan Kata Pertamamu

Tekan hotkey-nya. Mulai bicara. Lihat transkripnya dimulai dari kata keduamu — kadang ketiga. "Refactor logika retry-nya" keluar sebagai "logika retry-nya". "Jangan merge itu dulu" keluar sebagai "merge itu dulu", yang benar-benar merupakan kalimat berbahaya untuk diketikkan atas namamu. Kegagalan ini gampang direproduksi di berbagai pipeline mikrofon dengan cold start, dari fitur bawaan sistem operasi sampai alat dikte khusus.

Orang menggambarkannya dengan cara berbeda-beda — "ia memotong awalnya", "saya harus berhenti sejenak sebelum bicara", "kata pertamanya selalu hilang" — tapi ini satu fenomena, dan begitu kamu pernah tergigit, kamu mengembangkan solusi darurat yang dikembangkan semua orang: tekan tombolnya, tunggu sesaat, lalu bicara. Artinya kamu sekarang menjalankan ritual takhayul kecil puluhan kali sehari untuk mengompensasi alatmu, dan alat itulah yang melatihmu, bukan sebaliknya.

Saya menjalankan ritual itu berbulan-bulan dengan alat lain. Saat membangun Keebye, membunuhnya adalah salah satu hal pertama dalam daftar, karena perbaikannya ternyata menuntut kompromi tidak nyaman yang tidak mau diambil kebanyakan aplikasi — dan saya ingin membicarakan komprominya seterus terang perbaikannya.

Kenapa kata pertama terpotong?

Ini masalah di level kategori, bukan kecerobohan satu vendor, dan fisikanya sederhana: mikrofon tidak instan.

Saat sebuah aplikasi dikte memulai perekaman dengan cara naif — tekan hotkey, lalu buka mikrofonnya — ada seluruh rantai yang harus berjalan sebelum sampel pertama ucapanmu tertangkap. Sesi audio OS harus diinisialisasi. Perangkat input harus bangun, yang untuk sebagian perangkat keras berarti waktu pemanasan yang harfiah. Format streaming dinegosiasikan, buffer dialokasikan, dan buffer pertama yang tiba sering berupa sampah yang dibuang. Bergantung pada mesin dan perangkatnya, rantai itu butuh antara "sekejap" dan beberapa detik.

Sementara itu kamu — manusia dengan pikiran yang sudah terbentuk — mulai bicara persis saat jarimu menyentuh tombolnya. Biasanya sedikit sebelum saat itu, sebenarnya: niat untuk menekan dan niat untuk bicara meninggalkan otakmu bersamaan, dan awal ucapan rutin mendahului kesiapan aplikasinya. Semua yang kamu ucapkan sebelum stream-nya hidup tidak pernah ada sejauh yang aplikasinya tahu. Modelnya tidak bisa mentranskripsi audio yang tidak pernah ditangkap. Karena itu: "logika retry-nya".

Kenapa aplikasi menyalakan mikrofon saat dibutuhkan saja alih-alih menjaganya tetap siap? Kebanyakan karena kesopanan. Menahan mikrofon tetap terbuka memakan sedikit daya dan — jauh lebih penting — ia menyalakan indikator mikrofon OS, yang wajar dibaca pengguna sebagai "aplikasi ini sedang mendengarkan saya". Membuka mikrofon hanya saat dibutuhkan menjaga indikatornya jujur dan aplikasinya terlihat sopan. Biayanya adalah risiko cold start di awal setiap perekaman.

Perbaikannya: mikrofon yang sudah mendengarkan saat kamu menekan tombolnya

Keebye menyerang ini dari kedua ujungnya, dan kedua mekanismenya layak dipisahkan karena mereka memecahkan dua separuh masalah yang berbeda.

Mikrofon yang hangat. Setelah perekaman pertamamu dalam sebuah sesi, Keebye menjaga stream input audio tetap terbuka. Artinya rantai cold start — inisialisasi sesi, membangunkan perangkat, negosiasi stream — sudah terjadi sebelum dikte berikutnya selama stream itu tetap sehat. Stream-nya hidup sebelum jarimu bergerak.

Pre-roll. Stream yang hangat memperbaiki keterlambatan aplikasinya, tapi bukan keterlambatanmu — ingat, awal ucapanmu bisa mendahului tekananmu pada tombol. Jadi Keebye menyimpan buffer bergulir 500 milidetik dari audio terbaru (8.000 sampel pada 16 kHz, dalam sebuah ring). Saat kamu menekan hotkey-nya, setengah detik audio-sesaat-sebelumnya itu dialirkan ke bagian depan ucapanmu. Audio yang dimulai di dalam buffer itu tersedia untuk transkriber alih-alih dibuang sebelum tombolnya ditekan.

Hasil gabungannya: pada dikte berulang, stream yang hangat dan pre-roll 500 ms menutup kasus umum di mana ucapan dimulai tepat sebelum atau bersamaan dengan tekanan tombol. Jeda ritualnya menjadi tidak perlu di dalam batas itu. Ia tidak bisa memulihkan kata yang diucapkan lebih dari setengah detik sebelum perekaman dimulai, dan dikte pertama dalam sebuah sesi tetap membayar latensi awal stream yang normal.

Komprominya, dinyatakan terus terang

Inilah bagian yang saya tolak untuk kubur, karena ini harga jujur dari rancangannya: karena stream audionya tetap terbuka di antara dikte, macOS menampilkan mikrofon sebagai aktif bahkan saat kamu tidak sedang mendikte. Titik oranyenya menyala. Kalau kamu melihat Control Center, Keebye tercantum sebagai sedang memakai mikrofon, saat itu juga, sementara kamu tidak melakukan apa-apa.

Yang sebenarnya terjadi selama waktu itu: audionya mengalir ke ring buffer 500 ms dan terus-menerus dibuang. Tidak ada yang ditranskripsi. Tidak ada yang disimpan. Tidak ada yang keluar dari buffer sampai kamu menekan tombolnya — dan segala yang lebih tua dari setengah detik hilang selamanya, ditimpa oleh ring-nya. Tapi saya tidak akan berpura-pura bahwa indikatornya berbohong, karena ia tidak: stream-nya terbuka, dan "mampu-selalu-mendengarkan" adalah deskripsi yang adil untuk arsitekturnya, meskipun tidak ada yang mendengarkan dalam arti yang berarti sampai kamu memintanya.

Saya mengambil kompromi ini dengan sengaja, dengan mata terbuka, dan inilah alasannya. Membuka mikrofon saat dibutuhkan saja memperkenalkan risiko cold start setiap kali: kata terpotong, kalimat yang salah, jeda yang terlatih. Rancangan stream-hangat punya biaya yang mendarat pada kenyamananmu dengan sebuah titik oranye, dengan dukungan arsitektur yang bisa kamu nalar: riwayat lokal teks-saja (yang kami tulis di dikte kamu tidak seharusnya lenyap begitu saja), transkripsi on-device, tidak ada audio yang pernah disimpan, setengah detik memori ring. Saya pilih titiknya. Kalau kamu tidak — itu posisi yang sah, dan itu mungkin memang membuat alat lain jadi pilihan yang tepat untukmu; halaman Keebye vs Superwhisper dan Keebye vs Wispr Flow kami ditulis untuk membantu persis keputusan itu.

Dua batas, supaya tidak ada yang terkejut

Dikte paling pertama dalam sebuah sesi tetap punya latensi awal stream yang normal. Mikrofonnya hangat karena sudah ada perekaman sebelumnya; yang pertama tetap membayar biaya setup-nya. Dikte berikutnya mendapat manfaatnya selama stream-nya tetap terbuka.

Pre-roll-nya 500 milidetik, dan 500 milidetik itu sekejap, bukan sekalimat. Buffer-nya menutup kasus alami — sebuah kata yang dimulai sedikit sebelum tombolnya ditekan. Kalau kamu menyampaikan satu kalimat penuh lalu ingat untuk menekan tombolnya, kata-kata sebelumnya hilang, memang dirancang begitu: ring-nya hanya pernah memuat setengah detik, justru supaya aplikasinya tidak menahan audio yang berarti saat menganggur. Pre-roll yang lebih panjang akan menangkap lebih banyak awalan pelupamu dan menahan lebih banyak audio sekitarmu di memori. Setengah detik adalah tempat saya menarik garis itu.

Kenapa setengah detik lebih penting daripada kedengarannya

Kata pertama yang terpotong terlihat seperti bug kecil. Dalam workflow lane paralel yang menjadi alasan Keebye dibangun — suara sebagai kanal kendali untuk beberapa agent AI dan beberapa percakapan manusia sekaligus, hari kerja yang digambarkan di dua anak, tiga startup, satu suara — dikte terjadi puluhan kali sehari, dalam rentetan, di tengah pergantian konteks. Alat yang menuntut jeda ritual memajaki setiap rentetan dan, lebih buruk lagi, sesekali membalik maknamu lalu mengirimkannya. "Merge itu dulu" lucu tepat sekali saja.

Keandalan di kategori ini bukan satu fitur besar. Ia akumulasi pengaman-pengaman kecil: pre-roll untuk audio pembuka, riwayat di belakang transkrip, dan jalur penyisipan yang bisa dipulihkan. Tulisan ini tentang yang pertama; tulisan tentang riwayat membahas yang kedua.

Keebye ada dalam akses awal untuk macOS. Mulai uji coba gratismu di bawah, ucapkan “Jangan merge itu dulu” pada dikte berulang, dan periksa apakah kata pertamanya selamat. Itulah seluruh tesnya.