Kenapa sebuah master immersive lolos di editor gelombang tetapi gagal QC

Sebuah berkas kiriman immersive bisa dibuka di editor gelombang, menampilkan dua belas atau enam belas trek yang kelihatan sehat, diputar dengan wajar, dan tetap ditolak. Alasannya bersifat struktural: di dalam berkas BW64, audio dan metadata adalah dua hal terpisah yang harus cocok persis, dan tidak ada apa pun di dalam formatnya yang memaksa keduanya cocok. Renderer menyelesaikan rujukan. Editor menggambar sampel. Pekerjaan yang berbeda — itulah sebabnya QC ADM adalah pemeriksaan integritas rujukan, bukan mendengarkan. Berikut isi kedua standarnya, di mana rujukannya putus, dan pemeriksaan mana yang menangkap kegagalan mana.

Tiga jenis audio, dan kenapa pembedaannya menentukan segalanya

Setiap masalah pengiriman immersive berawal dari kebingungan tentang mana di antara tiga hal itu yang sedang diwakili sebuah trek.

Audio berbasis kanal menetapkan tiap trek ke posisi pengeras suara yang tetap. Stereo itu berbasis kanal, begitu juga 5.1, begitu juga bed 7.1.4. Posisinya melekat pada identitas kanal: trek 3 adalah speaker tengah, dan ia adalah speaker tengah di setiap sistem yang memutarnya. ITU-R BS.2051 memformalkan ini untuk sistem suara lanjutan, dengan menggambarkan tata letak sebagai jumlah lapisan Upper + Middle + Bottom — System A adalah 0+2+0 (stereo), System B adalah 0+5+0 (5.1), System D adalah 4+5+0, System J adalah 4+7+0, System H adalah 9+10+3, konfigurasi 22.2. Di ADM ini adalah typeDefinition DirectSpeakers, typeLabel 0001.

Audio berbasis objek membawa sinyal mono (atau pack multikanal) plus metadata posisional yang berubah seiring waktu. Renderer-lah yang memutuskan pengeras suara nyata mana yang mereproduksinya, berdasarkan tata letak yang ada di ruangan. Tidak ada apa pun pada treknya yang mengandaikan sebuah speaker. Ini adalah typeDefinition Objects, typeLabel 0003.

Audio berbasis scene, dalam praktiknya Higher-Order Ambisonics, mengodekan seluruh medan suara sebagai komponen harmonik sferis. Tidak ada satu komponen pun yang dengan sendirinya berkaitan dengan sebuah arah; arah muncul dari kombinasi liniernya. Ini adalah HOA, typeLabel 0004. ADM juga mendefinisikan Matrix (0002) untuk sinyal termatriks seperti Mid-Side atau Lt/Rt, dan Binaural (0005).

Pembedaan ini bukan soal taksonomi. Kiriman berbasis kanal cukup mendeskripsikan dirinya sendiri untuk bertahan sebagai WAV telanjang — benarkan urutan kanalnya dan ia akan berbunyi. Kiriman berbasis objek atau berbasis scene tidak berarti apa-apa tanpa metadatanya: audionya adalah tumpukan aliran mono tanpa pembeda, dan ADM adalah satu-satunya yang menyatakan sebaliknya. Ketimpangan itulah alasan BW64 dan ADM ada.

BW64 ada gara-gara sebuah bilangan 32 bit

WAV klasik adalah berkas RIFF. RIFF, dari 1991, mengawali setiap chunk dengan field ukuran 32 bit. Tiga puluh dua bit mengalamati 4,294,967,296 byte — 4 GB — dan itulah plafon keras bagi seluruh berkas sekaligus bagi chunk data di dalamnya.

Untuk stereo pada 48 kHz / 24-bit, laju datanya 288,000 byte per detik, jadi 4 GB kira-kira 4 jam 8 menit. Tidak relevan. Untuk master berbasis objek 128 trek pada 96 kHz / 24-bit, lajunya 36,864,000 byte per detik, dan 4 GB adalah kurang dari dua menit — 116.5 detik.

Master immersive melewati batas itu secara rutin, dan penulis WAV yang menabraknya menghasilkan entah berkas terpotong atau berkas yang ukuran deklarasinya diam-diam berputar balik. EBU menangani ini lebih dulu lewat RF64 (EBU Tech 3306); ITU melanjutkannya sebagai Recommendation ITU-R BS.2088 — BW64.

Trik sentinel: 0xFFFFFFFF dan sebuah chunk ds64

BS.2088 menyatakan mekanismenya secara eksplisit. "The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file", dan field ukuran 32 bit yang asli menjadi bendera escape: "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

Itulah keseluruhan triknya, dan layak dinyatakan terang-terangan: BW64 tidak melebarkan field ukuran RIFF. Ia mengisinya dengan 0xFFFFFFFF sebagai sentinel dan menaruh ukuran 64 bit yang sebenarnya di dalam chunk ds64 yang harus berada paling depan di berkas. Jadi berkas BW64 di bawah 4 GB kompatibel byte demi byte dengan pembaca WAV dalam segala hal kecuali tanda tangan empat karakternya. Banyak alat menerimanya; sebagian keras kepala tidak.

Chunk-chunk-nya, dan yang tepat 40 byte per entri

Menurut BS.2088, berkas BW64 diharapkan memuat setidaknya ds64, fmt , chna, axml (dengan bxml dan sxml sebagai pembawa metadata alternatif) dan data gelombangnya.

ds64 harus menjadi chunk pertama setelah tanda tangan, karena pembaca harus mengetahui ukuran sebenarnya sebelum bisa menyusuri apa pun yang lain. Ia membawa paruh rendah/tinggi 32 bit untuk ukuran seluruh berkas dan ukuran data, plus tabel entri ChunkSize64 untuk chunk lain mana pun yang kebesaran — chunk axml yang mendeskripsikan ribuan objek dengan otomasi akurat sampel bisa mendekati atau melampaui 4 GB dengan sendirinya.

fmt adalah chunk format WAVE standar — format sampel, laju sampel, jumlah kanal, bit per sampel, block align. Ia satu-satunya pernyataan otoritatif tentang berapa banyak kanal terjalin yang ada di data. Segala sesuatu di hilirnya adalah metadata tentang kanal-kanal itu, dan metadata bisa berbohong.

chna adalah jembatan antara trek fisik dan ADM. Setelah ckID, ckSize, numTracks 2 byte dan numUIDs 2 byte, ia memuat larik datar entri audioID berlebar tetap, masing-masing tepat 40 byte:

2 + 12 + 14 + 11 + 1 = 40. Lebarnya bukan anjuran: semuanya ASCII berlebar tetap, dan penulis yang memancarkan UID 13 karakter telah menghasilkan tabel yang korup, bukan tabel yang sedikit tidak biasa.

Konvensi ID-nya juga penting. Nilai 0x0FFF ke bawah merujuk pada common definitions ADM — format kanal dan pack standar yang sudah ditetapkan sebelumnya — sedangkan 0x1000 ke atas menandakan definisi kustom yang harus hadir di axml. AP_00010003 adalah 5.1 menurut common definition dan tidak butuh XML; AP_00031001 adalah pack objek kustom dan butuh XML, atau ia menggantung.

numUIDs juga sah kalau melebihi numTracks: panduan EBU mencatat bahwa di tempat "the audio elements of a track may be [defined] differently in the course of a file … there will be a different UID for each definition", jadi satu trackIndex bisa muncul di beberapa entri. Alat QC yang mengasumsikan satu UID per trek akan menandai berkas yang benar sebagai rusak.

axml adalah dokumen XML UTF-8 yang memuat pohon <audioFormatExtended>. Itulah ADM, dan di situlah pada dasarnya semua kegagalan menarik bersarang. data adalah PCM terjalin biasa; tidak ada apa pun di dalamnya yang tahu apa-apa tentang objek.

Urutannya: ds64 selalu pertama; fmt sebelum data. Tetapi axml sah saja berada setelah data, dan sering memang begitu, karena — seperti diamati BS.2088 — selama perekaman "the XML metadata will likely be of an unknown length." Berkas dengan axml di ekor bukanlah berkas cacat, tetapi pembaca yang hanya memindai megabyte pertama akan melaporkan tidak ada ADM sama sekali. Itulah penjelasan bagi sebagian laporan "berkas saya tidak punya metadata" yang jumlahnya mengejutkan.

ADM adalah graf, dan kegagalannya adalah sisi yang putus

Hierarki ITU-R BS.2076 berjalan audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat, dengan audioTrackUID sebagai daun dan satu-satunya elemen yang berkaitan dengan trek fisik.

Itu adalah graf rujukan, bukan dokumen bersarang, dan setiap kegagalan pengiriman yang serius adalah sisi yang putus di dalamnya. Yang membuat rujukan menggantung berbahaya adalah tidak adanya satu perilaku baku ketika ia putus. Renderer yang menyelesaikan sebuah audioPackFormatIDRef yang menyebut pack yang tidak ada di XML bisa membatalkan penguraian dan menolak berkasnya; bisa melewati objek itu dan me-render sisanya, menghasilkan mix yang diam-diam kehilangan satu stem; atau bisa jatuh kembali ke common definitions, menemukan ID di rentang kustom 0x1000-ke-atas tanpa padanan, dan menggantinya dengan keheningan. Ketiga hasil itu sama-sama berarti "berkasnya terbuka". Hanya satu yang tertangkap dengan mendengarkan, dan itu pun hanya kalau Anda tahu apa yang seharusnya ada di sana.

Empat kegagalan yang menjelaskan sebagian besar penolakan

Jumlah trek fmt yang berselisih dengan chna. fmt .nChannels bilang 16; chna.numTracks bilang 14. Berkasnya sudah tidak konsisten secara internal sejak dua chunk pertama — biasanya hasil bounce yang mengubah jumlah trek setelah metadatanya disusun, atau alat yang membuang trek tanpa menulis ulang chna. Deteksinya berupa mengurai dua bilangan bulat dan membandingkannya: pemeriksaan termurah di seluruh alur, dan ia menangkap proporsi kegagalan yang mengejutkan banyaknya. Pastikan sekaligus bahwa setiap trackIndex berada dalam 1 … fmt .nChannels.

Sebuah audioTrackUID yang tidak dirujuk objek mana pun. UID di chna yang tidak dirujuk audioObject mana pun berarti ada audio yang tidak akan di-render apa pun; kasus cerminnya, sebuah audioTrackUIDRef di XML tanpa entri chna yang cocok, berarti metadata mengharapkan trek yang tidak ada. Bangun himpunan UID dari chna dan himpunan dari axml lalu ambil selisih simetrisnya; hasilnya harus kosong. EBU Tech 3392 menyatakan maksudnya secara langsung: "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

Pewaktuan blok yang berjalan mundur. BS.2076 tidak ambigu: "When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." EBU Tech 3392 mengetatkannya menjadi kesinambungan — "rtime + duration of an audioBlockFormat should match the rtime of the following block" — dengan blok pertama sebuah objek dimulai pada 00:00:00.00000, tidak ada blok yang lebih pendek dari satu sampel, dan durasi yang jumlahnya sama dengan audioObject induknya. Susuri blok-bloknya dalam urutan dokumen dan tegakkan rtime[n] + duration[n] == rtime[n+1]. Kegagalannya hadir dalam tiga bentuk: celah, yang perilaku renderer-nya tidak terdefinisi sehingga sebagian menahan posisi terakhir sementara sebagian lain membisu; tumpang tindih, yang membuat blok saling berebut; dan blok yang tidak urut secara kronologis, yaitu otomasi yang melompat mundur di tengah program.

Bed yang dideskripsikan di XML tetapi tidak pernah dicetak ke disk. XML mendeklarasikan pack DirectSpeakers 7.1.4 — dua belas kanal — tetapi hanya subset 5.1 yang dicetak, atau kanal ketinggian dibisukan saat bounce dan tercetak sebagai digital black. Graf rujukannya utuh; audionya tidak. Pemeriksaan struktural tidak bisa menangkap ini: Anda butuh analisis esensi, yang mengukur apakah setiap kanal yang diklaim oleh sebuah pack DirectSpeakers sungguh mengandung sinyal. Digital black pada kanal bed yang dideklarasikan bukan otomatis sebuah kesalahan — mix yang sah boleh saja meninggalkan kanal top-rear kosong — tetapi ia selalu layak diputuskan oleh manusia.

Apa yang diterbitkan tentang loudness immersive, dan apa yang tidak

Ada satu angka yang tidak selamat ketika berpindah dari stereo, dan alasannya layak disebut.

BS.1770-5 (November 2023) adalah edisi yang berlaku; BS.1770-4 sudah digantikan, meski sebagian besar meter yang terpasang masih mengutipnya. Algoritma intinya membobot L, R dan C pada 1.0 serta Ls dan Rs pada 1.41 (sekitar +1.5 dB), mengecualikan LFE, dan cakupannya "from one to five channels". BS.1770-5 memperluasnya melampaui itu di lampiran-lampirannya, mencakup sistem suara lanjutan BS.2051 dan audio berbasis objek — yang harus di-render sebelum bisa diukur. Karena itu loudness immersive bukan properti berkas melainkan properti sebuah render, dan mengubah tata letak sasaran akan mengubah angkanya. Ukurlah render yang konform BS.2127 ke tata letak BS.2051 bernama menggunakan meter BS.1770-5 dan catat ketiganya di catatan pengiriman Anda; BS.2127 mendefinisikan renderer ADM rujukan, dan saudara sumber terbukanya, EBU ADM Renderer (EBU Tech 3388), adalah cara praktis mendapatkan angka yang bisa direproduksi.

Tidak ada layanan streaming musik yang menerbitkan target loudness terintegrasi untuk pengiriman immersive. Angka-angka beredar di forum dan materi pelatihan vendor; tidak satu pun merupakan spesifikasi terbit dan artikel ini tidak akan mengulanginya seolah-olah demikian. Yang diterbitkan adalah untuk stereo berbasis kanal — target terintegrasi Spotify sebesar −14 LUFS dengan batas atas true peak −1 dBTP, diperketat menjadi −2 dBTP di atas −14 LUFS, dan −16 LUFS dari AES TD1008 untuk musik (angka −18 LUFS-nya berlaku untuk konten yang didominasi ujaran, dan menyebut −18 sebagai target musik adalah kekeliruan yang umum sekaligus serius).

Dolby Atmos adalah teknologi berpemilik dan berlisensi milik Dolby Laboratories, dan Sony 360 Reality Audio adalah sistem berpemilik yang dibangun di atas MPEG-H. Persyaratannya ditetapkan oleh pemiliknya, berubah tanpa mengacu pada jadwal ITU atau EBU, dan tidak dinyatakan di sini; tidak ada afiliasi atau dukungan yang diklaim. Bacalah dokumentasi terkini milik pemberi lisensinya sendiri.

Apa yang perlu diperiksa sebelum Anda mengirimnya

Pemeriksaan struktural lebih dulu; ia cepat dan ia membatalkan semua yang ada di hilirnya.

• Empat byte pertama adalah BW64. Kalau terbaca RIFF, itu WAV biasa dan tidak bisa melampaui 4 GB.
• ds64 adalah chunk pertama setelah tanda tangan, ukuran 64 bit-nya cocok dengan ukuran berkas dan ukuran data di disk, dan setiap chunk non-data yang kebesaran punya entri ChunkSize64 di tabelnya.
• Temukan axml secara eksplisit, termasuk setelah data — jangan pernah menyimpulkan "tidak ada ADM" dari pemindaian sebagian.
• Laju sampel dan kedalaman bit fmt cocok persis dengan spesifikasi pengiriman. Tidak ada konversi laju sampel setelah ADM disusun — itu membatalkan setiap rtime dan duration yang dinyatakan dalam sampel.
• fmt .nChannels sama dengan chna.numTracks; setiap trackIndex berada dalam rentang dan berbasis 1.
• Setiap entri chna tepat 40 byte dengan field berlebar tetap yang padding-nya benar, dan setiap packRef di 0x1000 atau di atasnya terselesaikan ke definisi kustom yang hadir di axml.
• Setiap audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef dan audioTrackUIDRef terselesaikan. Nol sisi menggantung, di kedua arah, tanpa rujukan melingkar.
• Format kanal multiblok membawa baik rtime maupun duration di setiap blok; bloknya bersinambung dan monoton; objeknya mulai pada 00:00:00.00000.
• Setiap kanal dari bed yang dideklarasikan memuat apa yang seharusnya. Selidiki digital black.
• Timecode awal bext konsisten di seluruh set, dan conform stereo dan binaural di-render ulang dari master yang sekarang. Conform yang 40 ms lebih cepat dari induk immersive-nya akan lolos pemeriksaan keberadaan berkas dan gagal pada pendengaran tersinkron.
• Buat checksum tiap berkas kiriman, simpan manifesnya, dan arsipkan XML ADM terpisah dari BW64-nya — XML yang bisa Anda diff kelak lebih berharga daripada biner yang hanya bisa Anda urai ulang.

BW64 dan ADM adalah standar terbuka, terbit dan bebas dibaca, dan itu layak dimanfaatkan: Anda bisa membaca sendiri BS.2088 dan BS.2076, mengurai chunk chna dengan empat puluh baris kode, dan memverifikasi apa yang sebenarnya ditulis eksportir sebuah vendor alih-alih apa yang diklaim kotak dialognya. Hampir semua penolakan immersive yang tidak perlu adalah galat integritas rujukan yang bisa ditangkap validator dalam waktu kurang dari sedetik.

Inspektur BW64/ADM gratis dari Mazufa di mazufa.com/immersive-master-check mengurai kontainer dan metadatanya sepenuhnya di perangkat Anda sendiri dan tidak mengunggah apa pun, sehingga bisa dipakai pada materi yang secara kontraktual tidak boleh keluar gedung. Mazufa sendiri gratis untuk merilis, mengambil komisi 0%, dan hanya lewat undangan dengan tinjauan manusia atas setiap lamaran yang lengkap.

Sumber

Rekomendasi ITU-R

• ITU-R BS.2088-2 (11/2025), Long-form file format for the international exchange of audio programme materials with metadata (BW64) — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2088-2-202511-I!!PDF-E.pdf
• ITU-R BS.2076-3 (02/2025), Audio Definition Model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-3-202502-I!!PDF-E.pdf
• ITU-R BS.1770-5 (11/2023), Algorithms to measure audio programme loudness and true-peak audio level — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-5-202311-I!!PDF-E.pdf
• ITU-R BS.2051-2 (07/2018), Advanced sound system for programme production — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2051-2-201807-S!!PDF-E.pdf
• ITU-R BS.2127-1 (11/2023), Audio Definition Model renderer for advanced sound systems — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2127-1-202311-I!!PDF-E.pdf

Dokumen teknis EBU

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (beserta suplemennya), Specification of the Broadcast Wave Format — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3285s7.pdf
• EBU Tech 3392, ADM Broadcast Production Profile — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3392.pdf
• EBU Tech 3388, ADM Renderer for use in Next Generation Audio broadcasting — https://tech.ebu.ch/publications/tech3388
• EBU ADM Guidelines — CHNA chunk — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 and ADM — https://adm.ebu.io/reference/excursions/bw64_and_adm.html
• EBU ADM Guidelines — audioTrackUID — https://adm.ebu.io/reference/adm_elements/audio_track_uid.html
• Implementasi rujukan libbw64 — https://github.com/ebu/libbw64

AES

• AES TD1008, Recommendations for loudness of internet audio streaming and on-demand distribution — https://www.aes.org/community/technical-council/technical-document-aestd1008/

Dokumentasi layanan

• Spotify, Loudness normalization — https://support.spotify.com/us/artists/article/loudness-normalization/