Apa Itu LUFS? Panduan Loudness untuk Suara AI dan Podcast

Apa itu LUFS? LUFS adalah satuan loudness yang mengukur seberapa keras audio terdengar bagi pendengar dalam rentang waktu tertentu, bukan seberapa tinggi puncak sinyalnya. Satu LU sama dengan satu dB gain, dan nilainya negatif karena skalanya bertumpu pada digital full scale (0 dBFS). Untuk suara manusia, Anda biasanya mencocokkan target tertentu, misalnya -16 LUFS untuk kebanyakan podcast, lalu menjaga true peak tetap di bawah sekitar -1 dBTP.

Bagaimana LUFS sebenarnya mengukur loudness?

LUFS adalah singkatan dari Loudness Units relative to Full Scale. Pengukurannya didefinisikan dalam ITU-R BS.1770 dan diadopsi oleh EBU R 128, sedangkan LKFS adalah satuan yang sama dengan nama lama. Sebuah meter melakukan tiga hal sebelum ia menampilkan angka.

Pertama, meter menerapkan K-weighting. Ini adalah filter yang memotong frekuensi rendah dan memberi sedikit penguatan pada upper mids, kurang lebih meniru cara telinga menimbang energi. Suara dengan rumble 80 Hz yang berat akan terbaca lebih pelan daripada level mentahnya, karena filter itu mengurangi rumble tersebut.

Kedua, meter merata-ratakan energi dalam sebuah jendela waktu. Ada tiga jendela yang penting dalam praktik:

• Momentary melihat 400 ms dan bergerak dengan cepat.

• Short-term melihat 3 detik dan paling berguna saat Anda mengedit satu frasa.

• Integrated mencakup seluruh file dari sampel pertama sampai sampel terakhir, dan inilah angka yang dipakai platform untuk normalisasi.

Ketiga, meter melakukan gating. Segala sesuatu di bawah -70 LUFS diabaikan begitu saja, lalu apa pun yang lebih dari 10 LU di bawah rata-rata berjalan juga diabaikan. Gating inilah alasan jeda panjang di antara dua baris tidak menarik turun angka Anda. Itu juga alasan file yang sebagian besar berisi room tone memberi angka integrated yang terasa aneh.

Catatan sesi: jika sebuah render lebih pendek dari satu detik, angka integrated hanya bertumpu pada sedikit jendela. Ukur di dalam adegan atau bab yang utuh.

Mengapa nilainya negatif, dan apa bedanya dengan dBFS dan RMS?

Skalanya berhenti di 0 dBFS, yaitu nilai tertinggi yang bisa disimpan oleh file digital dengan format tetap. Semua yang Anda dengar berada di bawah batas itu, jadi semuanya terbaca negatif. Angka -16 LUFS berarti 16 satuan di bawah full scale.

Kebingungan dimulai karena beberapa meter memakai tampilan dB yang mirip. Berikut perbedaannya dalam praktik.

• Peak (dBFS) adalah sampel tertinggi tunggal. Ini memberi tahu Anda tentang clipping, dan sama sekali tidak tentang loudness.

• True peak (dBTP) memperkirakan level tertinggi yang dicapai gelombang di antara sampel setelah konversi. Codec lossy bisa mendorongnya melewati 0 walaupun sample peak masih berada di bawah itu, dan inilah sebabnya platform meminta headroom -1 dBTP.

• RMS merata-ratakan daya sinyal tanpa K-weighting maupun gating. Ini lebih kasar, dan sebagian spesifikasi, seperti standar audiobook di bawah, masih memakainya.

• LUFS adalah loudness yang ditimbang dan di-gate. Ini paling sesuai dengan apa yang pendengar anggap lebih keras.

Dua file bisa menampilkan peak yang sama namun berjarak 8 LU dalam loudness. Sebuah take dengan banyak plosive dan satu lonjakan tunggal, dibandingkan dengan take terkompresi yang dinamikanya rata, membuktikannya. Celah inilah alasan satuan ini ada.

Target LUFS mana yang harus Anda capai untuk pekerjaan voice?

Tidak ada satu angka tunggal. Target bergantung pada tempat file akhirnya diputar, dan beberapa tujuan sama sekali tidak memakai LUFS. Ini angka-angka yang sebaiknya Anda tulis di catatan kerja.

• Streaming musik, sekitar -14 LUFS integrated. Dokumentasi loudness Spotify menyebut -14 dB LUFS sebagai level pemutaran normal, dengan Loud di -11 dan Quiet di -19 untuk pendengar Premium. Panduannya adalah true peak di -1 dBTP atau lebih rendah, atau -2 dBTP jika master Anda lebih keras dari -14.

• Podcast, umumnya -16 LUFS stereo dan -19 LUFS mono. Angka mono 3 LU lebih rendah karena sinyal mono yang digandakan ke kedua kanal terukur 3 LU lebih keras dibanding sinyal yang sama di satu kanal. Batas -1 dBTP adalah saran yang umum.

• Broadcast menurut EBU R 128, -23 LUFS integrated, dengan batas true peak -1 dBTP dan toleransi 0.5 LU untuk pengiriman berbasis file.

• Audiobook di ACX, tanpa LUFS sama sekali. Persyaratan pengiriman audio ACX meminta RMS antara -23 dB dan -18 dB, peak di bawah -3 dB, dan noise floor di bawah -60 dB RMS. Jika Anda mengirim audiobook, ukur dengan analyzer mereka, bukan hanya dengan meter LUFS.

Perhatikan urutan pada poin terakhir. Sebuah bab bisa berada di -20 LUFS yang wajar dan tetap gagal di ACX karena satu peak yang panas atau ekor yang berisik. LUFS memberi tahu Anda tentang loudness rata-rata, sementara spesifikasi memperhatikan tiga hal yang terpisah.

Yang sering terlewat: jangan memastikan podcast ke -14 hanya karena halaman Spotify menyebut -14. Angka itu untuk musik. Ucapan dengan integrated -14 biasanya berarti limiter bekerja keras pada konsonan, dan pendengar merasakannya sebagai kelelahan dalam sepuluh menit.

Mengapa output voice AI butuh pemeriksaan loudness sendiri?

Anda mungkin mengira voice sintetis datang dengan level yang konsisten, karena tidak ada jarak mikrofon atau drift preamp. Kadang memang begitu. Namun sering kali tidak, dan penyebabnya berbeda dari sesi rekaman.

Setiap render bisa membawa gain keseluruhannya sendiri dari mesin. Ubah voice, kecepatan bicara, atau pengaturan emosi, dan integrated loudness ikut bergeser. Penyampaian yang tegang dan terpotong serta penyampaian yang tenang dan berbisik dari voice clone yang sama bisa berbeda beberapa LU. Jika Anda membangun satu adegan dari 40 baris yang dirender terpisah, Anda akan mendengar lompatan yang tidak pernah direkam oleh siapa pun.

Tiga kebiasaan membantu.

1. Ukur setiap render sebelum Anda mengeditnya. Tulis integrated reading di samping nama file di log Anda.

2. Samakan dulu baris-baris dalam satu adegan satu sama lain, baru ke target pengiriman. Konsistensi relatif lebih penting daripada angka absolut di dalam mix.

3. Simpan satu garis referensi per voice. Normalisasi semua yang lain terhadap garis itu, sehingga narator clone tidak melenceng dari satu bab ke bab berikutnya.

Saat Anda mengontrol emosi dengan slider, seperti sistem 8 slider AnyVoice, bersiaplah bahwa loudness ikut berubah seiring intensitas. Perlakukan integrated reading sebagai bagian dari catatan parameter, bukan renungan belakangan. Untuk game, artinya normalisasi per state voice sebelum baris masuk ke middleware, karena engine tidak akan melakukannya untuk Anda.

Seperti apa alur loudness yang masuk akal untuk voice sintetis?

Urutan ini paling sedikit membuang waktu. Alurnya sama, baik file berasal dari voice clone, voice stok, maupun narator manusia.

1. Render pada kualitas tertinggi yang ditawarkan tool, lalu simpan file yang belum diproses. Jangan normalisasi di dalam generator jika bisa dihindari, karena Anda kehilangan file asli.

2. Ukur integrated LUFS dan true peak pada seluruh file, dengan meter yang mengikuti BS.1770. Sebagian besar DAW menyertakannya, dan beberapa plugin gratis juga.

3. Hitung gain. Target dikurangi hasil ukur memberi offset dalam dB. Jika render terbaca -21.4 LUFS dan Anda ingin -16, tambahkan 5.4 dB. Satuannya linear, jadi gain 5.4 dB menggeser angka tepat sebesar 5.4 LU.

4. Periksa peak setelah gain. Jika true peak sebelumnya -8.0 dBTP, nilainya menjadi -2.6 dBTP, dan itu memenuhi batas -1 dBTP. Jika hasilnya melewati batas, Anda membutuhkan true-peak limiter, bukan gain tambahan.

5. Pakai limiter hanya untuk masalah yang tersisa. Ceiling -1 dBTP dengan 1 sampai 2 dB gain reduction transparan pada ucapan. Pengurangan 10 dB sudah terdengar sebagai pumping.

6. Ukur ulang file yang diekspor, bukan sesinya. Konversi codec dan dither bisa menggeser angka sedikit.

Normalisasi loudness pada tahap ini berbeda dari kompresi. Normalisasi hanya mengubah gain, jadi dinamikanya tetap seperti hasil render. Jika sebuah baris berisi bisikan tegang lalu teriakan dan Anda ingin keduanya lebih berdekatan, itu adalah kerja kompresi atau clip gain, dan dilakukan sebelum pass loudness akhir.

Catatan sesi: jalankan pengecekan akhir pada format yang benar-benar dikirim. File 128 kbps bisa terbaca beberapa persepuluh dB berbeda dari WAV asalnya.

Kesalahan apa yang paling banyak membuang waktu saat bekerja dengan LUFS?

Sebagian besar masalah berasal dari empat tempat yang sama.

Mengukur hal yang salah. Loudness short-term selama satu frasa keras bukan nilai integrated. Mengejar meter momentary membuat Anda terlalu banyak mengoreksi, dan file yang dimaster agar kalimat terkerasnya mencapai -16 akhirnya berada di -20 secara keseluruhan.

Menganggap -16 sebagai hukum alam. Itu sebuah konvensi. Sebagian platform menormalisasi pemutaran untuk Anda, sebagian lagi tidak. Web player atau smart speaker bisa tidak menerapkan kontrol loudness sama sekali, sehingga file yang terlalu pelan akan tetap pelan di sana.

Melewatkan noise floor. Menaikkan 5 LU juga menaikkan desis dan room tone sebesar 5 dB. Jika sumbernya berisik, langkah cleanup harus dilakukan sebelum langkah gain. Kalau tidak, masalahnya ikut membesar seiring angka yang Anda kejar.

Melupakan soal stereo. Voice mono yang dikirim sebagai file mono dan yang dikirim sebagai dual mono bisa berjarak 3 LU pada posisi fader yang sama. Periksa format mana yang diharapkan tujuan Anda sebelum mengekspor.

Lewati plugin apa pun yang menjanjikan perbaikan loudness satu klik tanpa meter dan tanpa log tentang apa yang dilakukannya. Pekerjaan loudness adalah aritmetika. Jika Anda tidak bisa melihat angka sebelum dan sesudah, Anda tidak bisa mempertanggungjawabkan hasilnya.

Sebelum sesi berikutnya

Tentukan tujuan pengirimannya dulu, karena itu yang menentukan semuanya. Untuk podcast: -16 LUFS stereo atau -19 mono, dengan peak di -1 dBTP. Untuk streaming yang berdekatan dengan musik: sekitar -14, dan ikuti panduan true peak. Untuk broadcast: -23 menurut R 128. Untuk audiobook: analyzer ACX beserta batas RMS, peak, dan noise floor-nya.

Lalu tulis angkanya ke template sesi Anda. Tambahkan kolom untuk integrated LUFS dan true peak di samping setiap render. Jika Anda membuat voice dalam batch, tetapkan garis referensi per voice dan samakan ke situ. Setelah log itu ada, bab baru atau adegan yang dibangun ulang enam bulan kemudian hanya membutuhkan beberapa menit, bukan setengah hari menebak dengan telinga.