Sebagian besar jeda dalam terjemahan langsung adalah waktu menunggu: menunggu aliran, kata berikutnya, lalu kalimat. Satu bagian yang bisa Anda atur adalah mode latensi: jeda lebih singkat, atau revisi lebih sedikit.
Pendengar yang membaca terjemahan langsung melihat setiap baris beberapa detik setelah pembicara mengucapkannya. Jeda itu bukan satu tundaan, melainkan beberapa tundaan yang terakumulasi sepanjang rantai, dan sebagian besarnya adalah bentuk menunggu. Memahami menunggu yang mana membuat pilihan mode latensi menjadi mudah, dan memberi tahu pengembang pembaca apa yang harus ditampilkan, dan kapan.
Sebagai tolok ukur sebelum melihat angka: juru bahasa simultan manusia biasanya berbicara dua sampai empat detik di belakang pembicara. Juru bahasa menyebut jeda itu ear-voice span, dan untuk bahasa yang kata kerjanya berada di akhir, mereka tidak menunggu kata kerja, melainkan mengantisipasinya, atau memecah kalimat menjadi potongan-potongan yang bisa berdiri sendiri. Jeda satu atau dua detik bukan cacat perangkat lunak; itu kira-kira yang dilakukan penerjemah manusia yang sangat baik.
Setiap transkripsi langsung di VocalStack melewati tahap-tahap yang sama, dengan urutan yang sama, dan setiap tahap menunggu tahap sebelumnya.
Teks bahasa asli sampai ke pembaca hampir bersamaan dengan saat diucapkan. Terjemahan menyusul satu atau dua detik kemudian, dan kalimat yang diucapkan datang setelah terjemahannya, itulah sebabnya klip suara selalu tiba paling akhir. Namun, efek pertama yang terlihat dari rantai ini muncul jauh sebelum suara apa pun: teksnya sendiri yang bergerak.
Hal pertama yang disadari orang dalam transkrip langsung adalah kata-kata terbaru yang terus bergeser. Sebuah frasa muncul, berubah, lalu mapan. Itu adalah tahap draf yang bekerja, dan keberadaannya punya alasan yang berlaku untuk setiap pengenal ucapan.
Pengenal ucapan memastikan sebuah kata dengan melihat kata yang datang sesudahnya. Dalam bahasa Inggris, "I scream" dan "ice cream" terdengar sama sampai kata berikutnya datang; huruf "s" di akhir bisa milik kata ini atau kata berikutnya. Selama belum ada audio di sebelah kanan sebuah kata, ejaannya masih tebakan, sehingga kata-kata paling baru dalam transkrip langsung selalu yang paling kurang pasti. Draf pada dasarnya adalah tebakan itu, yang ditampilkan lebih awal alih-alih disembunyikan.
Setiap draf menggantikan seluruh ekor langsung: kata-kata yang terdengar sejak komit terakhir dan masih berubah. Komit bersifat final. Ia tidak pernah berubah, membawa waktu per kata, dan komit diberi nomor tanpa celah agar pembaca bisa tahu jika ada yang terlewat.
Bagi pengembang, inilah satu aturan yang diwajibkan oleh API realtime: tampilkan setiap segmen yang sudah dikomit, lalu draf terbaru setelahnya, dan kosongkan draf ketika komit datang. Jika draf ditambahkan alih-alih diganti, teks akan terduplikasi dan berkedip; komit cukup menghabiskan ekornya. Tutorial WebSocket membangun pembaca tepat di sekitar aturan ini.
Bagi host, teks yang terus bergeser adalah harga dari latensi rendah. Menampilkan kata sebelum frasanya selesai itulah yang membuat transkrip terasa langsung. Namun, terjemahan tidak bisa memakai trik itu, karena sebuah kata bisa ditebak dari separuh frasa, tetapi sebuah terjemahan tidak bisa.
Urutan kata adalah alasan terjemahan tidak bisa mengimbangi draf. Dalam bahasa Jerman, kata kerja bisa berada di akhir klausa, dan dalam bahasa Jepang kata kerja selalu di akhir. Penerjemah mana pun membutuhkan seluruh klausa sebelum menyampaikannya dengan setia. Menerjemahkan kata demi kata hanya menghasilkan serpihan yang harus dibaca ulang saat klausa selesai. Juru bahasa sudah menunggu kata kerja dalam bahasa Jerman jauh sebelum perangkat lunak mencoba melakukannya.
Karena itu VocalStack menerjemahkan kalimat, bukan segmen. Kalimat aktif secara default, dan saat aktif, server merangkai komit menjadi kalimat lalu menerjemahkan keseluruhannya. Selama kalimat masih terbuka, terjemahannya bersifat sementara; setelah tertutup, terjemahannya final. Pembaca menyimpan satu entri per kalimat dan menggantinya setiap kali pembaruan datang.
Ucapan menunggu lebih lama lagi. Hanya kalimat yang sudah tertutup yang dibacakan, karena kalimat yang masih berubah akan disintesis ulang di setiap revisi. Kalimat panjang dibacakan per potongan, sehingga bagian pertama bisa diputar sementara sisanya sedang dibuat.
Dengan kalimat dimatikan, setiap komit mendapat bingkai terjemahannya sendiri. Jalur ini tidak menunggu apa pun, tetapi kalimat utuh jauh lebih enak dibaca.
Semua tunggu ini diukur sejak audio tiba di VocalStack. Untuk banyak siaran, audionya sudah terlambat ketika sampai di sana.
Jika sumbernya aliran, bukan mikrofon, audionya sudah tertinggal sebelum ada yang ditranskripsikan. Audio itu tertinggal dari live edge, yaitu momen terbaru yang sudah dipublikasikan aliran.
Aliran audio HTTP biasa, jenis yang paling banyak dipublikasikan oleh stasiun radio internet, umumnya tertinggal satu sampai tiga detik. Server menyimpan burst buffer: beberapa detik audio terbaru yang dikirim sekaligus agar pemutar pendengar baru bisa mulai tanpa tersendat. Setiap pendengar, termasuk VocalStack, ikut bergabung dari titik sejauh itu ke belakang. HLS lebih buruk: daftar putarnya memulai klien tiga segmen di belakang live edge, yang dalam praktik berarti beberapa detik sampai setengah menit, tergantung panjang segmen. DASH standar biasanya berada di rentang yang sama dengan HLS; hanya varian low-latency-nya yang jauh lebih rendah. Aliran "langsung" sebuah stasiun mungkin hanya "langsung" dalam arti sebuah surat disebut "terkini".
Angka-angka ini perkiraan, dan angka itu milik aliran, bukan milik transkripsi: tidak ada pengaturan di sisi VocalStack yang bisa mengembalikannya. Jika detik-detik itu penting untuk sebuah acara, masukkan audio ke tahap dari mikrofon atau encoder, bukan dari aliran publik. Jeda aliran sudah tetap sebelum VocalStack mendengar satu kata pun; mode latensi adalah yang benar-benar bisa Anda ubah.
Mode latensi hanya melakukan satu hal: mengatur keseimbangan antara jeda dan akurasi. Pengaturannya ada di bawah Advanced saat transkripsi langsung dibuat, dan di tab Speed saat transkripsi berjalan. Di sana chip-nya bertuliskan AUTO, SPEED, atau ACCURACY (Fast tampil sebagai SPEED). Lewat API, session.update mengubahnya di tengah aliran.
Pertukarannya sesuai dengan nama-namanya. Fast mengeluarkan teks lebih cepat tetapi merevisi lebih banyak; Accuracy membutuhkan sedikit lebih lama dan merevisi lebih sedikit. Penonton yang duduk membaca subtitle terjemahan jarang menyadari tambahan satu detik, tetapi pasti menyadari kata-kata yang terus berubah. Karena itu Accuracy sering kali pilihan yang lebih baik, selama grafik jeda tetap datar. Auto menunjukkan cara kerjanya: baris yang dipercepatnya untuk menutup celah diberi lencana FAST MODE di transkrip host, dengan catatan bahwa akurasinya mungkin lebih rendah di sana.
Apa pun modenya, transkripsi harus sudah siap sebelum kata pertama, dan persiapan itu adalah satu-satunya jeda yang dibayar rantai ini hanya sekali.
Pada sebagian paket, transkripsi langsung membutuhkan beberapa detik untuk mulai. Lamanya bergantung pada paket: baris Start-up speed di halaman harga berkisar dari awal dingin hingga 15 detik di Bayar Sesuai Pemakaian sampai selalu siap di Enterprise.
Lewat API, tunggu itu tampak sebagai frame session.loading selama sesi dimulai, lalu session.ready; klien hanya mengirim audio setelah itu. Pendengar yang membuka tautan dalam masa tunggu melihat "Live. The first line appears in a moment." Setelah transkripsi berjalan, jeda ini sudah lewat, dan satu-satunya pertanyaan yang tersisa adalah berapa banyak dari sisa jeda yang Anda bawa.
Selama transkripsi langsung berjalan, tab Speed di host menampilkan semua hasil penjumlahan ini: selisih terkini antara pembicara dan teks, dengan chip mode di sebelahnya, serta grafik selisih itu sepanjang rekaman beserta rata-rata dan puncaknya. Di dalam transkrip, baris yang sampai ke pendengar terlambat diberi lencana yang menunjukkan jumlah detik antara saat diucapkan dan saat tiba.
Grafik yang tetap rendah dan datar berarti mode itu cocok dengan audionya. Grafik yang terus naik berarti pipeline mulai tertinggal. Dalam mode Accuracy, itu mungkin saatnya beralih ke Auto, yang mengorbankan sebagian akurasi demi kecepatan sampai selisihnya menyempit.
Pengembang mendapat satu angka saja. Ketika sesi realtime berakhir, session.done membawa stats.realtimeFactor, yaitu audio yang ditranskripsikan dibagi waktu yang dihabiskan untuk mentranskripsikannya. Satu catatan konvensi: dalam literatur pengenalan ucapan, real-time factor biasanya berarti kebalikannya, yaitu waktu proses dibagi durasi audio, dengan nilai yang lebih rendah lebih baik. VocalStack melaporkannya dengan cara sebaliknya, sehingga di sini nilai yang lebih tinggi lebih baik: sesi langsung berada di sekitar 1, dan di bawah 1 berarti audio tiba lebih cepat daripada yang bisa ditranskripsikan pipeline.
Tidak ada detik-detik ini yang misterius. Sebagian milik aliran, sebagian milik sebuah kata yang menunggu kata setelahnya, sebagian milik kalimat yang dibutuhkan terjemahan, dan sisanya milik mode latensi yang Anda pilih. Referensi API memuat detail frame demi frame, dan demo di halaman utama memperlihatkan rantai ini berjalan.
