Encoder AAC Baru di FFmpeg 9.1

 (hydrogenaudio.org)
1 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Encoder AAC native FFmpeg ditulis ulang secara menyeluruh, mencakup rate control, RDO, serta PNS·TNS·I/S·M/S, dengan target kualitas yang layak dibandingkan langsung dengan encoder AAC eksternal
  • Implementasi baru berperilaku mendekati CBR ketat, dan mode VBR nyata berbasis -q:a tidak direkomendasikan
  • Dalam perbandingan Zimtohrli·ViSQOL, encoder nmr baru umumnya menunjukkan hasil lebih baik daripada fdk-aac·Apple AAC pada rentang 64–256kbps, tetapi Opus tetap unggul dalam perbandingan terpisah
  • PNS·TNS·I/S·M/S dipilih di dalam loop RDO, dan jika downmix diperkirakan akan dilakukan, disarankan memakai -aac_is 0 -aac_pns 0 untuk menjaga fase
  • Pada 128kbps ke atas, banyak evaluasi menunjukkan peningkatan, tetapi stereo 64kbps, beberapa sampel TNS, dan konten suara masih menjadi area yang memerlukan verifikasi tambahan

Penulisan ulang menyeluruh encoder AAC FFmpeg

  • Encoder AAC FFmpeg ditulis ulang secara menyeluruh, termasuk rate control, RDO, PNS, TNS, I/S, dan M/S
  • PR penulisan ulang dibagikan sebagai kandidat merge, dan merge aktual kemudian dikonfirmasi di thread
  • Pengujian dapat dilakukan setelah build dari source atau setelah pembaruan BtbN nightly builds
  • Encoder baru dapat digunakan sebagai codec aac
    • ffmpeg -i input.flac -map 0:0 -c:a aac -b:a 128000 output.m4a
    • Menonaktifkan I/S: -aac_is 0
    • Menonaktifkan PNS: -aac_pns 0

Metrik kualitas dan pembanding

  • Perbandingan menggunakan Zimtohrli dari Google, ViSQOL, dan uji dengar
    • Zimtohrli makin rendah makin baik
    • ViSQOL makin tinggi makin baik
  • Dalam tabel, encoder baru ditandai sebagai nmr, dan dibandingkan dengan FFmpeg 8.1 lama fast·twoloop, fdk-aac, Apple AAC, dan libopus
  • Hasil representatif:
    • 64kbps: nmr 0.00309 / 3.83, fdk-aac 0.00322 / 3.69, Apple 0.00612 / 3.29, libopus 0.00100 / 4.59
    • 128kbps: nmr 0.00072 / 4.47, fdk-aac 0.00143 / 4.27, Apple 0.00081 / 4.44, libopus 0.00020 / 4.68
    • 256kbps: nmr 0.00031 / 4.61, fdk-aac 0.00103 / 4.45, Apple 0.00067 / 4.63, libopus 0.00002 / 4.73
  • Pada bitrate tinggi, Zimtohrli menjadi jenuh sehingga ViSQOL digunakan sebagai tie-breaker; dengan kriteria ini, encoder baru unggul dalam perbandingan selain melawan Opus

Desain berfokus CBR dan alat coding

  • Encoder baru dirancang hampir sebagai khusus CBR, dengan variasi bitrate yang sangat kecil
    • Target anggaran bit membantu kualitas coding
    • Mode VBR nyata berbasis -q:a tidak direkomendasikan
  • Dalam perbandingan, encoder lain dinilai hampir tidak memakai alat coding selain TNS; encoder baru terlebih dulu dibandingkan hanya dengan TNS, lalu PNS, I/S, dan M/S diimplementasikan ulang
  • Berdasarkan hasil reverse engineering, qaac tidak melakukan optimisasi perseptual, melainkan memakai kurva alokasi bit dan energi band yang menyukai frekuensi tinggi
    • Encoder baru memakai masked band energy pada RDO dengan kurva serupa
  • Semua alat coding PNS, TNS, I/S, dan M/S dipilih di dalam loop RDO
    • Tidak memakai heuristik tetap atau cutoff bitrate arbitrer
    • Alat yang dapat digunakan diterapkan sesuai keputusan RDO
  • Pada bitrate tinggi, jika encoder itu sendiri bekerja cukup baik, alat seperti I/S dan PNS akan mati sendiri untuk mempertahankan bitrate

Kompatibilitas decoder dan hal yang perlu diperhatikan saat downmix

  • Decoder AAC FFmpeg memiliki masalah dalam pemrosesan stereo PNS, dan bug yang sama mungkin ada di decoder AAC lain, sehingga encoder melakukan workaround
    • Karena encoder lama tidak memakai PNS, masalah ini belum terlihat sampai sekarang
  • Jika downmix direncanakan atau output mungkin di-downmix, penggunaan -aac_is 0 -aac_pns 0 direkomendasikan
    • Tujuannya adalah menjaga fase sinyal asli
  • Banyak lubang yang terlihat di spektrogram adalah perilaku yang disengaja
    • Band yang termasking dibuat menjadi 0 atau diproses dengan PNS
    • Jika band tetangga cukup besar sehingga band yang hilang sulit dipersepsikan, encoder memilih mengodekan band yang terdengar dengan lebih baik daripada mengodekan semua band dengan buruk

Kebijakan sample rate dan cutoff

  • Encoder terutama dioptimalkan untuk audio 48kHz
    • 44,1kHz dan 96kHz juga berfungsi
    • Jika menginginkan kualitas tertinggi, penggunaan 48kHz direkomendasikan
  • Benchmark yang dipublikasikan terutama dilakukan pada 44,1kHz, sedangkan data yang disetel dengan telinga adalah 48kHz
    • Sebagian logika windowing/transient terikat pada 48kHz
    • Karena perbedaan timing pada 44,1kHz tidak besar, logika tersebut tetap dipertahankan
  • Setelah itu, kebijakan bandwidth disesuaikan
    • 128kbps dibatasi ke 16kHz
    • 160kbps ke atas dibatasi ke 18kHz
    • Pada 192kbps per channel, diubah agar seluruh spektrum 20kHz ke atas ikut dikodekan
  • Pada stereo 64kbps, tidak banyak yang bisa dilakukan, dan meningkatkan PNS lebih jauh dapat merusak stereo image
    • Pada 64kbps, 15kHz pun bisa terlalu tinggi, sehingga diminta pengujian ulang cutoff 12kHz
    • Pada mono, workaround bug decoder tidak diperlukan sehingga PNS dapat digunakan jauh lebih banyak

Cakupan pengujian dan statistik debug

  • Pengujian dari pihak pengembang dilakukan pada koleksi musik 3000 track
    • Konten suara diuji sangat sedikit, sehingga mungkin memerlukan optimisasi tambahan
  • Encoder mencetak statistik tambahan saat selesai
    • Contoh: Qavg: 207.975 Tr: 5.3% TNS(L): 4.8% TNS(S): 36.9% M/S: 3.9% I/S: 10.0% PNS: 5.1%
  • Arti statistik:
    • Qavg: nilai lambda rata-rata; makin tinggi berarti makin sulit mempertahankan rate
    • Tr: short blocks
    • TNS(L): tingkat penggunaan TNS pada long frame
    • TNS(S): tingkat penggunaan TNS pada short frame
    • M/S: tingkat penggunaan Mid/Side coding
    • I/S: tingkat penggunaan intensity stereo coding
    • PNS: tingkat penggunaan perceptual noise substitution
  • Jika menemukan artefak yang mengganggu, sampel input asli dan baris statistik ini dapat disertakan untuk analisis

Uji pengguna awal dan masalah yang tersisa

  • Seorang pengguna menguji satu lagu, Burn the Boats, pada 64kbps, 134kbps, dan 200kbps
    • 64kbps bagus tetapi ada sedikit artefak
    • 134kbps dan 200kbps terdengar sangat baik
  • Dalam pengujian lain, muncul umpan balik bahwa pada sampel The Tower 64kbps, encoder nmr baru terasa lebih smeary dan metallic dibandingkan twoloop lama
    • twoloop lama juga memiliki masalah collapse di bagian awal, noise umum, dan roughness
  • Pada sampel fatboy_30sec, di 192kbps terdengar ticking sound pada 6,836 detik dan 10,480 detik; setelah resampling ke 48kHz, tick tambahan muncul pada 14,125 detik
    • Jika TNS dimatikan dengan -aac_tns 0, ticking hilang
    • Dilanjutkan dengan permintaan untuk mencoba menaikkan nilai TNS_PG_C1_SHORT di libavcodec/aacenc_tns.c menjadi 3.2, 4.2, dan 5.0
  • Seorang pengguna menilai bahwa pada kondisi 64kbps dan cutoff 16kHz, Fraunhofer AAC terdengar lebih baik, sementara encoder baru terdengar metallic
    • Pengguna yang sama menilai encoder baru bekerja baik pada bitrate tinggi di atas 128kbps
    • Juga muncul penilaian bahwa encoder AAC yang mudah diakses secara luas di dalam FFmpeg native kini sudah cukup layak digunakan

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Pendapat di Hacker News

  • Ini contoh yang menunjukkan betapa kuatnya Opus
    Pekerjaan seperti ini sendiri memang bernilai, dan membaiknya encoder untuk codec lama jelas menguntungkan, tetapi jika melihat angka Opus dalam benchmark ini, bahkan pada 64kbps pun ia mengungguli semua encoder AAC

    • Keunggulan terbesar encoder AAC yang bagus bukan efisiensi, melainkan kompatibilitas
      Selama hampir 20 tahun, standar de facto untuk video live streaming adalah RTMP yang memakai video H.264 dan audio AAC, dengan dukungan untuk codec lain nyaris tidak ada
      Jika ingin mengirim stream ke YouTube atau Twitch, pada akhirnya Anda akan mengirim H.264 dan AAC; OBS pun dalam mode streaming sama sekali tidak mengizinkan pilihan codec video·audio lain dan berasumsi streamer akan memakai H.264 dan AAC
    • Sebelum membaca artikelnya, saya sempat bingung apakah Opus yang dimaksud itu model atau encoder
    • Memilih codec audio lossy sekarang hampir tidak perlu dipikirkan lagi
      Pakai saja Opus, selesai; kalau karena suatu alasan tidak bisa memakai Opus, gunakan AAC dengan bitrate sangat tinggi demi kompatibilitas
      Anda bisa mendapatkan kualitas bagus tanpa harus meneliti encoder dan mode mana yang harus dipilih
      Tetap saja, hadirnya encoder AAC bawaan yang berkualitas itu bagus, tetapi saya tidak terlalu paham kenapa fokusnya terutama pada bitrate konstan
    • [https://en.wikipedia.org/wiki/Opus_(audio_format)#/media/Fil...](https://en.wikipedia.org/wiki/Opus_(audio_format)#/media/File:Opus_bitrate+latency_comparison.svg)
    • Menurut saya masalah terbesar Opus ada pada spesifikasinya yang kurang memadai: https://nothings.org/stb/stb_opus.html
      Karena itu, Opus jadi hampir tidak digunakan pada game atau distribusi lewat store yang bisa memunculkan masalah lisensi tertentu

  • Saya penasaran seperti apa performa sebenarnya
    Encoder AAC lama di FFmpeg punya kualitas output yang buruk dan sering menghasilkan artefak seperti kicauan yang mengganggu, jadi untuk mendapatkan suara yang layak saya harus memasang encoder Apple Core Audio di setiap komputer yang dipakai untuk merekam video
    Saat melakukan perbandingan A/B/X, MP3 320kbps terdengar lebih baik daripada AAC 320kbps yang di-encode dengan FFmpeg, dan kira-kira setara dengan AAC 256kbps yang di-encode dengan Core Audio
    Jika sekarang instalasi Core Audio tidak lagi diperlukan, itu peningkatan besar, dan orang-orang yang merekam layar atau streaming dengan alat seperti OBS bisa mendapat peningkatan kualitas audio yang besar pada update berikutnya

    • Terkait Apple Core Audio, qaac itu berguna
      Ia membungkus DLL iTunes Windows menjadi alat encoding mandiri dengan CLI, dan setahu saya juga berjalan di Wine di Linux: https://web.archive.org/web/20250814194428/https://www.andre...
      Untuk encoding AAC berkualitas tinggi, Mac atau instalasi penuh iTunes tidak selalu diperlukan
    • Saya memakai encoder FDK AAC, dan tidak tahu bahwa encoder Apple bisa dipakai juga di sistem selain Apple
      Dulu saat membandingkan FDK AAC dan Apple AAC pada 192kbps, saya tidak merasakan perbedaan, tetapi encoder AAC lama FFmpeg runtuh pada bitrate ini
    • Dalam tabel metrik di thread diskusi Hydrogenaudio, encoder baru ini mendapat skor lebih baik daripada Core Audio
      Namun itu berdasarkan bitrate konstan
      Core Audio juga punya TVBR, yaitu mode bitrate variabel yang tidak ada pada encoder baru ini
      Jadi ketika TVBR bisa digunakan, Core Audio mungkin tetap yang terbaik, tetapi saya berharap encoder FFmpeg baru ini juga akan menjadi cukup bagus jika lebih banyak orang menemukan sampel bermasalah dan berkontribusi untuk tuning
    • Kalau peduli pada kualitas, saya penasaran kenapa tidak memakai codec lossless
      Atau pakai saja Opus; untuk suara juga bagus dan sekarang hampir berjalan di mana-mana
    • Saya tidak paham kenapa Apple terus bergantung pada codec proprietari
      Kalau Apple tidak mengadopsi H.265, mungkin kita sudah hidup di utopia AV1

  • Bagian yang mengatakan “decoder AAC FFmpeg punya bug dalam pemrosesan PNS stereo, dan mungkin juga ada di decoder AAC lain, jadi diakali di sisi encoder. Encoder lain tidak memakai PNS, sehingga belum ditemukan sampai sekarang” itu menarik
    Saya tidak tahu apa itu PNS, tetapi sepertinya selama 20 tahun ini ia telah menyiksa kasus penggunaan yang sangat khusus milik seseorang

    • Masalahnya ada dua
      Pertama, jika TNS dipakai di atas PNS, noise yang disisipkan akan dibentuk oleh TNS, padahal pihak yang membuat noise bukan encoder melainkan decoder, jadi itu tidak masuk akal
      Ini membuat PNS rusak, dan masalah yang lebih besar adalah ketika PNS dipakai bersama alat stereo tertentu, noise bocor secara identik ke kedua kanal dan merusak stereo imaging
      Jadi yang terbaik adalah mengaktifkan PNS hanya ketika pita terkait di kedua kanal semuanya berupa noise, atau cukup tidak tonal dan tertutupi masking
    • https://www.audiolabs-erlangen.de/content/resources/aesCodin...

  • Pembaruan yang hebat dengan detail yang tertata rapi
    Opus memang hebat dan punya tempatnya sendiri, tetapi AAC tidak akan menghilang

  • Ada bagian yang mengatakan, “Encoder ini terutama dioptimalkan untuk audio 48kHz. Terimalah. Ini tahun 2026, resampling itu gratis, dan 48kHz adalah standar. 44,1kHz berfungsi, 96kHz juga berfungsi, tetapi kalau ingin kualitas terbaik, gunakan 48kHz.” Apakah sekarang 48kHz benar-benar sudah menjadi standar?

    • Yang paling mendekati “standar” sebenarnya menurut saya adalah AES5-2018, “praktik yang direkomendasikan untuk audio digital profesional”
      Dalam abstraknya disebutkan bahwa untuk produksi, pemrosesan, dan pertukaran program audio yang menggunakan PCM, disarankan frekuensi sampling 48kHz; juga mengakui 44,1kHz untuk beberapa aplikasi digital konsumen, 32kHz untuk aplikasi terkait transmisi, dan 96kHz untuk aplikasi yang membutuhkan bandwidth lebih tinggi atau filter anti-aliasing yang lebih longgar
      Secara pribadi, 44,1kHz terasa seperti kerepotan kecil yang tersisa sebagai warisan
    • AAC punya sifat aneh: ukuran jendelanya berubah tergantung sampling rate
      Karena jendela 20ms dan 60ms terdengar sangat berbeda bagi telinga manusia, semua parameter psikoakustik encoder harus dioptimalkan ulang sepenuhnya untuk setiap sampling rate
      Di Opus, tentu saja masalah ini sudah diselesaikan
    • 48kHz membuat penyelarasan video dan audio jauh lebih mudah
      Misalnya, sinkronisasi gerak bibir setelah penyuntingan jadi lebih mudah
    • Sejauh yang saya tahu, codec Opus menganggap semua input sebagai 48kHz, lalu melakukan resampling input ke sana
    • Hampir semua DAC pada dasarnya berjalan di 48kHz, karena sistem operasi memilihnya sebagai nilai default yang masuk akal

  • Encoder AAC FFmpeg baru yang lebih baik tentu disambut baik, tetapi ada dua catatan yang cukup besar dalam detailnya
    Hanya mendukung bitrate tetap, dan hanya dioptimalkan untuk sampling 48kHz
    Tidak bisa melakukan encoding variable bitrate berbasis kualitas adalah celah besar, dan mengingat audio CD di seluruh dunia adalah 44,1kHz, ini juga tampak seperti kekurangan besar

    • Saya tidak paham mengapa variable bitrate diperlukan untuk encoding audio
      Audio variable bitrate terdengar buruk sekali dan juga tidak menghemat bitrate sebanyak itu
    • Dengan -q:a, Anda bisa menggunakan variable bitrate “sungguhan”, tetapi metriknya beberapa persen lebih rendah
      Meski begitu, menurut saya sulit dipersepsikan dan tetap menang
      Benchmark sebagian besar dilakukan pada 44,1kHz, sedangkan data yang dituning dengan telinga adalah 48kHz, jadi sebagian logika windowing dan transient terikat ke 48kHz
      Namun, itu sudah terbawa dengan cukup baik ke 44,1kHz dan perbedaan timing-nya tidak besar, jadi dibiarkan seperti itu

  • Menarik bahwa begitu banyak hal ini bergantung pada telinga pengembangnya sendiri
    Di saat yang sama agak mengkhawatirkan sekaligus cukup keren, karena penilaian kualitas audio memang sesubjektif ini

    • Untuk tabel dan perbandingan digunakan “Zimtohrli baru dari Google, ViSQOL, dan pendengaran saya”
    • Dalam audio, biasanya memang seperti ini
      Musepack juga sempat populer di ceruk tertentu; itu codec yang sederhana tetapi dituning dengan sangat baik
      Speaker dan headphone juga sama: orang mengira ini soal kualitas komponen, padahal sebenarnya pemahaman umum tentang fisika audio dan kemampuan tuning yang baik adalah faktor penentu utamanya

  • Ini tambahan yang sangat menggembirakan
    Semoga sekarang bisa menggantikan fdk-aac

  • Ada orang yang membuat encoder AAC terbaik sepanjang masa, dan reaksi pertama justru admin memperdebatkan 48kHz atau 44kHz. Benar-benar terasa seperti internet zaman dulu

    • Tidak perlu melihatnya sesinis itu
      Penulisnya tidak benar-benar menguji pada sampling rate yang paling umum digunakan, jadi untuk proyek serius mana pun, mengganti seluruh pipeline yang sudah berjalan selama puluhan tahun itu tidak masuk akal
      Menunggu sampai validasi yang memadai selesai adalah hal yang sepenuhnya wajar

  • Dulu ketika saya meng-encode lagu untuk iPod nano dengan ffmpeg, filenya rusak
    Saat diputar, setiap beberapa detik terdengar suara pop dan klik yang terputus-putus; saya penasaran apakah sekarang sudah diperbaiki