BW64 dan ADM: Referensi Teknis Audio Imersif untuk Rekaman Gamelan, Angklung, dan Ansambel Indonesia

Acuan kerja untuk perekam karawitan, insinyur mixing, dan musisi yang tiba-tiba diminta menyerahkan "master imersif" tanpa pernah punya ruang untuk mendengarkannya.

Jawaban singkat

ADM (Audio Definition Model, Rekomendasi ITU-R BS.2076) adalah model metadata terbuka yang menjelaskan apa sebenarnya setiap trek audio di dalam sebuah berkas: kanal pengeras suara tetap, objek yang bergerak, atau komponen medan suara Ambisonik — dan bagaimana semuanya digabung menjadi satu sajian. Metadata itu ditulis sebagai XML dan dititipkan di dalam kontainer BW64 (Rekomendasi ITU-R BS.2088), yaitu perluasan 64-bit dari RIFF/WAVE yang melewati plafon 4 GB berkas WAV klasik. Untuk musik Indonesia, taruhannya besar dan konkret: satu perangkat gamelan Jawa lengkap adalah dua puluh sampai tiga puluh instrumen yang berbeda secara fisik, ditata dalam susunan ruang yang punya makna budaya — gong ageng di belakang, jajaran saron di sisi, bonang di depannya, kendang di tengah sebagai pengendali — dan meringkas itu menjadi stereo membuang informasi yang bersifat struktural, bukan hiasan. Pengiriman imersif gagal QC bukan karena telinga, melainkan karena audio dan metadata adalah dua benda terpisah yang harus cocok persis, dan tidak ada apa pun di dalam format berkas yang memaksanya cocok. QC ADM adalah pemeriksaan integritas rujukan, bukan sesi mendengarkan. Itulah sebabnya dokumen ini masih berguna untuk Anda meskipun — seperti hampir semua studio di Indonesia — Anda tidak punya satu pun ruang monitor imersif.

1. Kenapa gamelan adalah argumen audio berbasis objek terkuat di musik dunia

Mulailah dari musiknya, bukan dari formatnya.

Sebuah perangkat gamelan Jawa lengkap — katakanlah gamelan ageng laras slendro dan pelog — bukan "satu instrumen". Ia adalah dua puluh sampai tiga puluh instrumen yang secara fisik terpisah, dimainkan oleh dua puluh sampai tiga puluh orang, yang ditempatkan di posisi tertentu dan posisi itu bukan kebetulan. Susunannya adalah bagian dari cara musik itu bekerja:

• Gong ageng dan gong suwukan berada di belakang, digantung tinggi. Fungsinya menandai akhir siklus gongan. Ia jarang berbunyi, dan ketika berbunyi, ia harus terasa datang dari belakang dan dari atas — bukan dari tengah campuran.
• Kendang berada di tengah, menghadap ansambel. Pengendang adalah pemimpin sajian: ia yang menaikkan dan menurunkan irama, memberi aba-aba peralihan, dan mengunci suwuk. Posisinya di tengah bukan estetika, melainkan tata kelola.
• Jajaran saron (demung, saron barung, saron panerus/peking) berjajar rapat, sering berhadapan dua baris. Yang penting bukan hanya bunyinya, melainkan jaraknya satu sama lain — imbal antara dua saron atau dua bonang panerus hanya masuk akal kalau pendengar bisa membedakan mana yang di kiri dan mana yang di kanan.
• Bonang barung dan bonang panerus ada di depan, membuka lagu dan mengisi.
• Gender barung, gender panerus, gambang, siter, suling, dan rebab — kelompok lirih — berada lebih dekat ke pesindhen dan penggerong.

Sekarang perhatikan apa yang terjadi kalau semua itu diringkas ke stereo. Imbal — pola berselang-seling antara dua instrumen sejenis — berubah menjadi satu deretan nada yang lebih cepat dan kehilangan identitas pelakunya. Sesenggakan dan aba-aba kendang yang seharusnya datang dari titik tetap di tengah menjadi bagian dari dinding suara. Gong ageng, yang di ruangan aslinya terasa seperti seluruh bangunan bergerak dari arah belakang, menjadi rendahan di tengah panggung stereo. Yang hilang bukan "kesan ruang" atau "ambience". Yang hilang adalah siapa memainkan apa dan dari mana — informasi yang, dalam karawitan, setara dengan informasi kontrapungtal.

Dalam gamelan, penempatan instrumen adalah bagian dari partitur. Format yang tidak bisa membawa penempatan itu bukan sekadar kurang mewah; ia kehilangan data.

Ini persis definisi masalah yang dijawab audio berbasis objek. Kalau kendang adalah objek dengan posisi tersendiri, ia tetap kendang di sistem 7.1.4, di sistem 5.1, dan di headphone — perendernya yang menyesuaikan. Kalau kendang hanyalah "sebagian dari kanal tengah", ia berhenti menjadi entitas begitu berkas dibuat.

Gamelan Bali: kasus yang lebih ekstrem lagi

Gamelan gong kebyar Bali menambah satu argumen yang tidak dimiliki musik lain. Instrumen logamnya dilaras berpasangan: satu set pengumbang dan satu set pengisep disetel dengan selisih frekuensi kecil yang disengaja. Selisih itulah yang menghasilkan ombak — denyut pelayangan yang menjadi ciri bunyi kebyar. Pasangan itu diletakkan berdampingan tetapi terpisah secara fisik.

Kalau pengumbang dan pengisep dijatuhkan ke titik panggung yang sama, pelayangannya tetap ada secara matematis tetapi berhenti menjadi peristiwa ruang; ia berubah menjadi tremolo. Kalau keduanya adalah objek dengan posisi masing-masing, perender bisa menjaga pemisahan itu di tata letak apa pun yang tersedia. Ini contoh langka di mana perbedaan berbasis kanal versus berbasis objek bisa diuji secara musikal, bukan sekadar diperdebatkan.

Kecak: kasus berbasis skena

Kecak adalah puluhan penyuara yang duduk melingkar, dan pendengar berada di dalam lingkaran. Tidak ada satu pun arah yang lebih utama dari yang lain, dan pola cak yang berselang-seling secara harfiah berputar mengelilingi ruang. Ini bukan kasus objek dan bukan kasus bed; ini kasus medan suara, dan representasi yang jujur untuknya adalah Ambisonik orde tinggi (HOA), yang di ADM berjenis HOA, typeLabel 0004.

2. Tiga jenis audio, dan kenapa pembedaannya menentukan format

Sebelum kontainer, modelnya. Hampir semua kekacauan pengiriman imersif berawal dari kebingungan tentang mana dari tiga hal berikut yang sebenarnya diisi oleh sebuah trek.

**Audio berbasis kanal (channel-based).** Setiap trek terikat ke satu posisi pengeras suara tetap. Stereo berbasis kanal. Begitu pula 5.1 dan "bed" 7.1.4. Posisinya menyatu dengan identitas kanal: trek 3 adalah kanal tengah, dan ia tetap kanal tengah di sistem mana pun. ITU-R BS.2051 memformalkan ini untuk sistem suara lanjutan, mendefinisikan tata letak sebagai jumlah lapisan Upper + Middle + Bottom: Sistem A adalah 0+2+0 (stereo), Sistem B 0+5+0 (5.1), Sistem D 4+5+0, Sistem J 4+7+0, dan Sistem H 9+10+3 — konfigurasi 22.2. Di ADM, isi berbasis kanal memakai typeDefinition DirectSpeakers, typeLabel 0001.

**Audio berbasis objek (object-based).** Satu sinyal mono (atau satu pak multikanal) ditambah metadata posisi yang boleh berubah sepanjang waktu. Perenderlah yang memutuskan pengeras suara nyata mana yang membunyikannya, berdasarkan tata letak yang benar-benar ada di ruangan. Tidak ada bagian dari trek itu yang mengandaikan pengeras suara. Ini typeDefinition Objects, typeLabel 0003.

**Audio berbasis skena (scene-based).** Dalam praktik, Ambisonik orde tinggi: seluruh medan suara dikodekan sebagai sekumpulan komponen harmonik sferis. Tidak ada satu komponen pun yang sendirian mewakili satu arah; arah muncul dari kombinasi liniernya. Ini typeDefinition HOA, typeLabel 0004. ADM juga mendefinisikan Matrix (0002) untuk sinyal termatriks seperti Mid-Side atau Lt/Rt, dan Binaural (0005) untuk pasangan yang sudah siap headphone.

Bedanya bukan soal selera. Deliverable berbasis kanal cukup menjelaskan dirinya sendiri untuk bertahan sebagai WAV telanjang: benarkan urutan kanalnya, dan ia berbunyi. Deliverable berbasis objek atau berbasis skena tidak berarti apa-apa tanpa metadatanya: audionya hanyalah tumpukan aliran mono yang tak terbedakan, dan ADM adalah satu-satunya yang menyatakan sebaliknya. Asimetri itulah alasan keberadaan BW64 dan ADM, sekaligus alasan QC imersif jauh lebih sulit daripada QC stereo.

3. Pendopo: ruang yang diwakili buruk oleh bed dan diwakili baik oleh objek-plus-bed

Gamelan Jawa secara tradisional dimainkan di pendopo — pendapa, pavilyun terbuka: atap joglo bertumpu pada saka guru, tanpa dinding, lantai keras, dan sisi-sisi yang terbuka ke halaman. Secara akustik, ini ruangan yang aneh dan penting.

Apa yang terjadi di pendopo:

1. Pantulan atas kuat dan berwarna. Atap joglo yang tinggi dan miring memantulkan kembali energi dari atas, dan pantulan itu sampai ke pendengar dengan tunda yang cukup panjang untuk terdengar sebagai peristiwa tersendiri. Bunyi gamelan di pendopo punya "atap" yang bisa didengar.
2. Hampir tidak ada dinding samping. Karena sisi-sisinya terbuka, energi yang menyamping pergi dan tidak kembali. Reverberasi lateralnya sedikit; yang tersisa adalah bunyi langsung yang tajam ditambah pantulan atas.
3. Ekor luruh yang panjang dan lembut dari luar ruangan. Halaman, pepohonan, bangunan sekitar — semuanya menyumbang ekor yang sangat pelan, difus, dan tidak berarah tegas.
4. Pendengar sering berada di dalam ansambel atau tepat di tepinya, bukan di seberang panggung.

Sekarang bandingkan dengan apa yang bisa diwakili oleh bed berbasis kanal. Bed 7.1.4 adalah dua belas posisi tetap yang mengelilingi satu titik dengar. Bed sangat baik untuk hal-hal yang memang difus dan tak berarah: ekor ruangan, atmosfer halaman, gemerisik penonton, ambience malam. Bed buruk untuk dua hal yang justru menentukan bunyi pendopo: pantulan atas yang berarah dan berwaktu tertentu, dan sumber-sumber yang berada di posisi tetap dan berbeda-beda di dalam medan.

Kalau seluruh sajian dipaksa masuk ke bed, ada dua kerugian sekaligus. Pertama, setiap instrumen harus di-pan ke posisi kanal terdekat pada saat mixing — artinya keputusan ruang dikunci di studio Anda, dan sistem pemutaran yang berbeda tidak bisa memperbaikinya. Kedua, tata letak pendengar di rumah hampir tidak pernah sama dengan 7.1.4; ketika sistem hanya punya 5.1 atau stereo, downmix kanal-ke-kanal menjatuhkan kanal atas ke dalam kanal tengah, dan gong ageng yang tadinya di belakang-atas berakhir di titik yang sama dengan vokal.

Representasi objek plus bed membelah masalah itu tepat di sendinya:

• Bed membawa apa yang memang difus: ekor pendopo, ambience halaman, bunyi ruangan yang tak berarah. Ini berbasis kanal, dan itu benar untuk isinya.
• Objek membawa apa yang memang punya posisi: gong ageng di belakang dan tinggi, kendang di tengah, dua saron sebagai dua objek berbeda supaya imbal tetap terbaca, bonang di depan, rebab dan pesindhen sebagai objek tersendiri. Setiap objek membawa posisinya, bukan kanalnya.
• Perender — bukan Anda — memutuskan bagaimana posisi itu diwujudkan di tata letak yang benar-benar ada. Di 4+7+0 gong ageng dapat pengeras suara atas belakang; di 0+5+0 ia disebar ke kanal belakang; di headphone ia dirender binaural. Tidak ada satu pun dari itu yang mengharuskan Anda membuat berkas baru.

Bed menjawab pertanyaan "seperti apa ruangannya"; objek menjawab pertanyaan "siapa berada di mana". Pendopo membutuhkan kedua jawaban, dan hanya salah satunya yang bisa dibawa oleh kanal.

Pembagian praktis yang masuk akal untuk rekaman karawitan: satu bed 7.1.4 dari mikrofon ruang (dua belas kanal), ditambah objek untuk instrumen yang perlu identitas posisi — kendang, gong ageng, gong suwukan, kenong, dua sampai empat saron, dua bonang, gender, rebab, suling, pesindhen, penggerong. Dua puluh empat objek adalah jumlah yang lapang untuk sajian klenengan, dan totalnya 36 trek. Angka itu akan kita pakai untuk aritmetika byte di Bagian 5.

4. BW64: apa itu, dan persisnya kenapa ia ada

WAV klasik adalah berkas RIFF. RIFF, dari 1991, mengawali setiap chunk dengan medan ukuran 32-bit. Tiga puluh dua bit mengalamati 4 294 967 296 byte — 4 GB — dan itulah plafon keras, baik untuk berkas secara keseluruhan maupun untuk chunk data di dalamnya.

Mari hitung apa artinya untuk pekerjaan nyata. Ukuran satu sample frame adalah jumlah kanal dikalikan byte per sampel.

(Aritmetika ini dapat Anda verifikasi sendiri; tidak ada angka di tabel ini yang berasal dari klaim pihak ketiga.)

Perhatikan baris ketiga. Satu klenengan — sajian gending berdurasi panjang, yang bentuk ladrang atau gendhing ageng-nya rutin melewati dua puluh sampai empat puluh menit dan sesi rekamannya bisa berjam-jam — melewati batas 4 GB dalam waktu kurang dari empat belas menit. Untuk repertoar wayang kulit semalam suntuk, yang berlangsung tujuh sampai delapan jam tanpa jeda, WAV klasik bukan sekadar sempit; ia mustahil.

Penulis WAV yang menabrak batas itu menghasilkan salah satu dari dua hal: berkas terpotong, atau berkas yang medan ukurannya diam-diam sudah membungkus (wrap) dan karenanya berbohong.

EBU menjawab masalah ini lebih dulu lewat RF64 (EBU Tech 3306). ITU kemudian melanjutkannya sebagai Rekomendasi ITU-R BS.2088, Long-form file format for the international exchange of audio programme materials with metadata — yaitu BW64. BS.2088 menyebut mekanismenya secara gamblang: "The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file", dan medan 32-bit yang lama berubah fungsi menjadi penanda pelarian — "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

Itulah seluruh triknya, dan layak dinyatakan terang-terangan:

BW64 tidak melebarkan medan ukuran RIFF; ia mengisinya dengan 0xFFFFFFFF sebagai sentinel, lalu menaruh ukuran 64-bit yang sebenarnya di dalam chunk ds64 yang wajib berada paling depan.

BW64 paling mudah dipahami sebagai generasi ketiga dari satu garis keturunan. RIFF/WAVE memberi kontainer berpotongan. Broadcast Wave (BWF, EBU Tech 3285) menambahkan chunk bext — originator, rujukan timecode, riwayat pengodean — yang mengubah WAV menjadi format pertukaran siaran. BW64 mempertahankan semuanya, menambah pengalamatan 64-bit, dan menambah chunk-chunk pembawa ADM. Berkas BW64 di bawah 4 GB kompatibel byte-per-byte dengan pembaca WAV dalam segala hal kecuali tanda tangan empat karakter di awal; banyak perkakas menerimanya, dan sebagian keras kepala menolak.

5. Tata letak chunk, dengan hitungannya

Menurut BS.2088, sebuah berkas BW64 diharapkan memuat setidaknya <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (dengan <bxml-ck> dan <sxml-ck> sebagai pembawa metadata alternatif), dan <wave-data>.

ds64 — tabel ukuran 64-bit

Wajib menjadi chunk pertama setelah tanda tangan BW64, karena pembaca harus tahu ukuran yang sebenarnya sebelum bisa menyusuri apa pun. Medannya adalah paruh-paruh 32-bit dari besaran 64-bit:

Muatan minimalnya 8 + 8 + 8 + 4 = 28 byte, ditambah 8 byte header chunk = 36 byte.

Hitung satu kasus nyata. Rekaman wayang dua jam, 36 trek, 48 kHz, 24-bit. Ukuran data:

5 184 000 byte/detik × 7 200 detik = 37 324 800 000 byte

Angka itu jauh melewati 4 294 967 296. Maka:

• Medan ckSize 32-bit di chunk data diisi 0xFFFFFFFF — bukan ukuran, melainkan sentinel.
• Nilai sebenarnya dipecah dua di ds64:

dataSizeHigh = 37 324 800 000 ÷ 4 294 967 296 = 8 (yaitu 0x00000008) dataSizeLow = 37 324 800 000 − (8 × 4 294 967 296) = 2 965 061 632 (yaitu 0xB0BB4000)

• Pembaca merekonstruksinya: (8 × 2³²) + 2 965 061 632 = 37 324 800 000. Cocok.

table[] lebih penting daripada kelihatannya. Chunk axml yang menjelaskan ribuan objek dengan otomasi berakurasi sampel bisa mendekati atau melewati 4 GB sendirian; tabel itulah cara chunk selain data menyatakan ukuran 64-bit-nya.

fmt — deskripsi esensi

Chunk format WAVE standar: format sampel, laju sampel, jumlah kanal, bit per sampel, block align. Ini satu-satunya pernyataan berwenang tentang berapa kanal terjalin yang benar-benar ada di data. Segala sesuatu di hilirnya adalah metadata tentang kanal-kanal itu, dan metadata bisa berbohong.

chna — tabel alokasi kanal, dan aritmetika 40 byte-nya

chna adalah jembatan antara trek fisik dan ADM. Ia dibuka dengan:

• ckID — 4 byte, 'chna'
• ckSize — 4 byte
• numTracks — 2 byte, jumlah trek di berkas
• numUIDs — 2 byte, jumlah entri audioTrackUID yang menyusul

Lalu larik datar entri audioID berlebar tetap. Setiap entri persis 40 byte:

2 + 12 + 14 + 11 + 1 = 40. Lebar medan ini bukan anjuran; semuanya ASCII berlebar tetap, dan penulis yang mengeluarkan UID 13 karakter tidak menghasilkan tabel yang "sedikit tidak lazim" — ia menghasilkan tabel yang rusak.

Hitung untuk berkas gamelan kita. 36 trek, satu definisi per trek, jadi 36 UID:

muatan chna = 4 (numTracks + numUIDs) + (36 × 40) = 4 + 1 440 = 1 444 byte
seluruh chunk = 8 (ckID + ckSize) + 1 444 = 1 452 byte

Seribu empat ratus lima puluh dua byte untuk menjelaskan tiga puluh tujuh gigabyte audio. Perbandingan itu sendiri layak direnungkan: bagian terkecil dari berkas adalah bagian yang paling sering merusaknya.

Sekarang kasus yang lebih halus. Misalkan trek 19 membawa kendang sebagai objek selama gending pembuka, lalu dialihfungsikan menjadi kanal bed selama bagian rampak di paruh kedua. Trek itu berhak punya dua UID. Maka numTracks tetap 36 tetapi numUIDs menjadi 37:

muatan chna = 4 + (37 × 40) = 4 + 1 480 = 1 484 byte

numUIDs boleh lebih besar daripada numTracks. Panduan EBU menyatakan alasannya: bila "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." Karena itu satu trackIndex boleh muncul di beberapa entri. Perkakas QC yang mengasumsikan satu UID per trek akan menandai berkas yang benar sebagai rusak.

Perhatikan juga konvensi ID: nilai 0x0FFF ke bawah merujuk ke common definitions ADM — format kanal dan pak baku yang sudah didefinisikan — sementara 0x1000 ke atas menandakan definisi kustom yang wajib ada di chunk axml. packRef bernilai AP_00010003 adalah 5.1 menurut common definition dan tidak butuh XML; AP_00031001 adalah pak objek kustom dan tanpa XML ia menggantung.

audioTrackUID adalah nomor seri berkas untuk identitas satu trek fisik, dan ia ada justru supaya sebuah trek boleh berganti isi di tengah sajian secara sah.

axml — ADM-nya sendiri

Dokumen XML, UTF-8, berisi pohon <audioFormatExtended>. Inilah ADM. Ia teks, bisa dibaca manusia, dan di sinilah hampir semua kegagalan menarik bersarang.

Satu catatan khas Indonesia: nama instrumen dan nama gending di dalam label objek adalah teks Unicode. Gong Ageng, Kendhang Ciblon, Saron Panerus aman; tetapi ejaan dengan diakritik Jawa (é, è, ě) dan tanda kutip melengkung yang tersisip dari papan ketik ponsel bisa membuat XML tidak sah kalau penulisnya tidak meng-escape dengan benar. Simpan axml sebagai UTF-8 tanpa BOM, dan buka hasilnya sekali dengan pengurai XML mana pun sebelum kirim.

data — PCM terjalin

Sampel terjalin biasa, persis seperti di WAV. Tidak ada apa pun di data yang tahu apa pun tentang objek.

Urutan. ds64 selalu pertama. fmt sebelum data. axml boleh diletakkan setelah data, dan sering memang begitu, karena — sebagaimana dicatat BS.2088 — selama perekaman "the XML metadata will likely be of an unknown length." Berkas dengan axml di ekor bukan berkas cacat; tetapi pembaca yang hanya memindai satu megabyte pertama akan melaporkan tidak ada ADM sama sekali. Fakta tunggal ini menjelaskan sebagian besar laporan "berkas saya tidak ada metadatanya".

6. Model objek ADM

ITU-R BS.2076 membelah model menjadi dua paruh. Bagian format "describes the technical nature of the audio so it can be decoded or rendered correctly" dan bisa ditulis sebelum ada audio sama sekali. Bagian content menjelaskan "the language of dialogue, the loudness, etc." dan hanya bisa dirampungkan setelah sinyalnya ada. Mengetahui sebuah elemen milik paruh yang mana langsung memberi tahu Anda tahap produksi mana yang memasukkan kesalahan tertentu.

Hierarkinya, dari atas:

• audioProgramme — satu sajian utuh yang dikirim. Merujuk satu atau lebih audioContent.
• audioContent — komponen bermakna editorial: stem gamelan, stem vokal (pesindhen dan penggerong), narasi dalang, versi bahasa. Merujuk satu atau lebih audioObject.
• audioObject — sendi antara maksud editorial dan format teknis. Membawa waktu mulai dan durasi, dan merujuk nol atau lebih audioPackFormat, nol atau lebih audioObject bersarang, serta nol atau lebih audioTrackUID. Di sinilah isi bertemu esensi.
• audioPackFormat — sekelompok kanal yang memang satu paket: bed 7.1.4, pasangan stereo, satu set HOA berorde tertentu. Merujuk elemen audioChannelFormat, dan boleh menyarangkan pak lain.
• audioChannelFormat — perilaku satu kanal sepanjang waktu. Berisi satu atau lebih audioBlockFormat.
• audioBlockFormat — atomnya. Untuk Objects: posisi (azimuth/elevation/distance atau Kartesian X/Y/Z), gain, ukuran, difusitas, plus rtime dan duration. Objek diam adalah satu blok; objek bergerak adalah deretan blok.
• audioTrackUID — daunnya, dan satu-satunya elemen yang berkorespondensi dengan trek fisik. Membawa atribut opsional sampleRate dan bitDepth, serta merujuk audioTrackFormat dan audioPackFormat.

audioStreamFormat dan audioTrackFormat duduk di antara channel format dan track UID untuk menjelaskan pengodean aliran. BS.2076-3 mencatat bahwa untuk PCM keduanya praktis mubazir — "the audioStreamFormat and the audioTrackFormat should be omitted" — tetapi pembaca "should be aware that existing ADM files (based on Recommendation ITU-R BS.2076-2 and earlier) for PCM audio may contain" keduanya. Dua bentuk itu sama-sama sah. Validator yang bersikeras pada salah satunya salah terhadap yang lain.

ADM adalah graf rujukan, bukan dokumen bersarang, dan setiap kegagalan pengiriman yang serius adalah sisi graf yang putus.

Apa yang terjadi ketika rujukan menggantung. Tidak ada satu perilaku baku, dan justru itu masalahnya. Perender yang menelusuri audioPackFormatIDRef ke pak yang tidak ada di XML bisa membatalkan penguraian dan menolak berkas; bisa melewati objek itu dan merender sisanya, menghasilkan campuran yang diam-diam kehilangan satu stem; atau bisa jatuh ke common definitions, menemukan ID di rentang kustom 0x1000+ tanpa padanan, lalu menggantinya dengan kesenyapan. Ketiganya sama-sama "berkasnya kebuka". Hanya satu yang bisa ketahuan dengan mendengarkan, dan itu pun hanya kalau Anda kebetulan tahu apa yang seharusnya ada di sana.

Bayangkan bentuk konkretnya: audioObject untuk gong ageng merujuk pak kustom yang tidak pernah ditulis ke XML. Berkas terbuka. Sajian berbunyi. Gong ageng hanya berbunyi di akhir gongan — mungkin sekali setiap satu sampai dua menit. Seorang QC yang tidak mengenal karawitan bisa mendengarkan berkas itu penuh-penuh dan tidak curiga sedikit pun. Inilah alasan QC ADM harus otomatis: telinga tidak bisa mendengar ketiadaan yang tidak pernah diberitahukan kepadanya.

7. Angklung: ansambel di mana satu objek benar-benar sama dengan satu orang

Angklung memberi contoh yang lebih tajam lagi, karena pemetaan satu-objek-satu-sumber di sana harfiah.

Dalam ansambel angklung padaeng, setiap pemain memegang satu atau dua angklung, dan setiap angklung hanya bisa membunyikan satu nada. Melodi dihasilkan oleh puluhan orang yang menggoyangkan alatnya secara bergantian pada saat yang tepat. Artinya: satu garis melodi tunggal secara fisik berpindah tempat dari satu pemain ke pemain lain, nada demi nada, melintasi barisan.

Dalam stereo, itu terdengar sebagai melodi yang sedikit bergerak di panggung. Dalam representasi berbasis objek, itu adalah persis apa adanya: sumber-sumber diskret di posisi tetap yang menyala bergiliran. Dan kalau Anda merekam angklung interaktif — bentuk pertunjukan di mana penonton dibagikan angklung dan diarahkan memainkan melodi bersama — objek dan bed membagi tugas dengan sangat rapi: objek untuk pemain inti dan pemandu di panggung, bed untuk ratusan angklung penonton yang memang difus dan mengelilingi ruangan.

Satu peringatan teknis. Angklung menghasilkan energi tinggi dengan transien cepat, dan barisannya bisa berjumlah puluhan. Godaannya adalah menjadikan setiap pemain satu objek. Jangan. Jumlah objek yang besar memperbesar axml secara nonlinier bila setiap objek beranimasi, dan memperbesar biaya render. Kelompokkan: satu objek per seksi (melodi 1, melodi 2, iringan, bass angklung/gambang), plus objek tersendiri hanya untuk yang benar-benar perlu identitas posisi.

8. Render: BS.2127 ke tata letak BS.2051

Berkas ADM bukan bunyi. Ia menjadi bunyi hanya lewat perender yang memetakan objek ke pengeras suara yang benar-benar ada.

ITU-R BS.2127 mendefinisikan perender ADM acuan untuk sistem suara lanjutan — yaitu tata letak yang dinamai BS.2051. Saudara sumber-terbukanya, EBU ADM Renderer (EAR, EBU Tech 3388), adalah cara paling praktis mendapatkan hasil yang bisa direproduksi orang lain.

Konsekuensi paling penting dari kalimat itu, untuk pekerjaan sehari-hari:

Berkas ADM yang sama menghasilkan bunyi yang berbeda pada tata letak yang berbeda, dan itu memang tujuannya. Karena itu setiap pernyataan tentang berkas imersif harus menyebut tata letak dan perendernya, atau pernyataan itu tidak bermakna.

Untuk rekaman gamelan, ini bukan detail administratif. Gong ageng yang Anda tempatkan di belakang-atas akan diwujudkan berbeda di 4+7+0 (ada pengeras suara atas belakang), di 0+5+0 (tidak ada lapisan atas sama sekali — energinya disebar), dan di binaural headphone (lewat HRTF). Semua itu bisa benar. Yang tidak boleh adalah mengasumsikan bahwa yang Anda dengar di satu tata letak adalah "berkasnya".

Praktik kerja yang masuk akal: pilih satu tata letak acuan yang Anda sebutkan di catatan pengiriman (misalnya 4+7+0, Sistem J), render dengan perender bernama dan berversi, lalu simpan render itu sebagai bukti — bukan sebagai deliverable, melainkan sebagai catatan tentang apa yang Anda dengar ketika mengambil keputusan.

9. Loudness imersif di bawah BS.1770-5

Di sini penting memisahkan apa yang dipublikasikan dari apa yang beredar.

Yang ditetapkan ITU-R BS.1770

Edisi yang berlaku adalah BS.1770-5 (November 2023). BS.1770-4 (Oktober 2015) sudah digantikan, meskipun itulah edisi yang masih dicantumkan oleh sebagian besar meter yang terpasang di studio. Sebut selalu -5 sebagai yang mutakhir. Seluruhnya ada enam edisi: -0 (2006), -1 (2007), -2 (2011), -3 (2012), -4 (2015), -5 (2023-11).

Mekanikanya:

• K-weighting adalah filter dua tahap: sebuah high-shelf ("head filter") yang memodelkan bola kaku, lalu high-pass RLB.
• Gain kurva K-weighting pada 1 kHz = +0,698 dB (linier 1,0836).
• Pengukuran memakai blok 400 ms dengan tumpang tindih 75 %.
• Gerbang absolut: buang blok di bawah −70 LUFS.
• Gerbang relatif: dihitung dari rata-rata blok yang lolos gerbang absolut, lalu digeser −10 LU. Ini bukan rata-rata tak tergerbang. Perbedaan ini sering dinyatakan keliru oleh implementasi.
• Loudness Range (LRA), EBU Tech 3342, memakai gerbang relatif −20 LU — bukan −10 LU. Memakai −10 untuk LRA adalah bug implementasi yang umum.
• Short-term: jendela 3 detik (EBU Tech 3341). Momentary: 400 ms.
• True peak diukur pada sinyal ter-oversample (minimal 4× menurut BS.1770; 8× lebih baik). Sample peak ≠ true peak; puncak antar-sampel bisa melebihi nilai sampel tertinggi.

Pembobotan kanal pada algoritme inti adalah 1,0 (0 dB) untuk L, R, dan C, serta 1,41 (≈ +1,5 dB) untuk Ls dan Rs, dengan LFE dikecualikan. Algoritme dasarnya bercakupan "from one to five channels". BS.1770-5 memperluasnya di lampiran-lampirannya, mencakup sistem suara lanjutan BS.2051 — pengeras suara di posisi sembarang dan kanal ketinggian — serta audio berbasis objek, yang harus dirender lebih dulu sebelum bisa diukur.

Loudness imersif bukan sifat berkas; ia sifat sebuah render. Ganti tata letak sasaran, angkanya berubah.

Ini perbedaan substantif dari stereo. Master stereo punya satu nilai loudness. Master berbasis objek punya sebanyak jumlah sasaran rendernya, dan cara jujur menyebut angka adalah dengan menyebut tata letak tempat ia diukur dan perender yang dipakai.

Yang dipublikasikan untuk musik

Untuk musik stereo berbasis kanal, Spotify mempublikasikan target integrated −14 LUFS dan plafon true peak −1 dBTP, mengetat menjadi −2 dBTP untuk master yang lebih keras daripada −14 LUFS. AES TD1008 menganjurkan −16 LUFS untuk musik; angka −18 LUFS di dokumen yang sama berlaku untuk konten yang dipimpin wicara (berita, bincang, drama) — menyebut −18 sebagai target musik adalah kekeliruan yang umum dan serius. EBU R 128 menetapkan target program siaran −23 LUFS; itu praktik normalisasi siaran, bukan spesifikasi musik streaming.

Yang TIDAK dipublikasikan

Tidak ada satu pun layanan streaming musik yang mempublikasikan target loudness terintegrasi untuk pengiriman imersif. Angka-angka beredar luas di forum dan di materi pelatihan vendor; sebagian masuk akal dan sebagian mungkin benar. Tak satu pun dari angka itu adalah spesifikasi yang dipublikasikan, dan dokumen ini tidak akan mengulanginya seolah-olah demikian.

Untuk stereo pun, Apple Music, YouTube Music, Amazon Music, TIDAL, dan Deezer tidak mempublikasikan target normalisasi apa pun. Angka yang biasa dikutip untuk layanan-layanan itu berstatus "dilaporkan luas, tetapi tidak dipublikasikan oleh layanannya", dan tidak boleh dijadikan dasar menghitung perubahan gain.

Siaran dan film terdokumentasi lebih baik daripada musik, karena lembaga penyiaran memang mempublikasikan. Kalau Anda butuh angka loudness imersif yang bisa dipertahankan hari ini: ukur sebuah render yang konform BS.2127 ke tata letak BS.2051 yang disebutkan namanya, dengan meter BS.1770-5, lalu tulis ketiganya di catatan pengiriman.

Tentang sistem berpemilik

Dolby Atmos adalah teknologi berpemilik dan berlisensi milik Dolby Laboratories, dan Sony 360 Reality Audio adalah sistem berpemilik yang dibangun di atas MPEG-H. Persyaratan pengirimannya ditetapkan oleh pemiliknya dan berubah tanpa mengikuti jadwal ITU atau EBU. Tidak ada bagian dari dokumen ini yang merupakan pernyataan tentang persyaratan perusahaan-perusahaan tersebut, dan tidak ada afiliasi, sertifikasi, atau dukungan yang diklaim maupun tersirat. Bila pemberi lisensi mempublikasikan persyaratan, bacalah dokumentasi mutakhir milik mereka sendiri dan rujuklah itu.

10. Posisi jujur: hampir tidak ada studio Indonesia yang punya monitoring imersif

Ini bagian yang biasanya tidak ditulis, dan justru bagian yang paling menentukan nilai praktis dokumen ini.

Kenyataannya sederhana: ruang monitor imersif — dua belas atau lebih pengeras suara yang dikalibrasi, termasuk lapisan atas, di ruangan yang perlakuan akustiknya memadai — hampir tidak ada di Indonesia. Yang ada, dan ada dalam jumlah besar, adalah studio kamar, project studio, dan ruang rekam kampus dengan monitor stereo yang bagus. Sebagian pekerjaan imersif Indonesia yang benar-benar terjadi dikerjakan di headphone, lewat render binaural.

Dua kesimpulan yang salah sering ditarik dari kenyataan ini, dan keduanya perlu ditolak.

Kesimpulan salah pertama: "kalau begitu jangan kerjakan imersif." Ini keliru untuk musik yang informasi ruangnya struktural. Rekaman gamelan yang dikirim hanya sebagai stereo membuang data yang tidak bisa dikembalikan nanti. Merekam dengan susunan mikrofon yang memungkinkan representasi objek-plus-bed, lalu mengarsipkan trek dan ADM-nya, adalah keputusan yang masuk akal bahkan kalau mixing imersif finalnya baru dikerjakan bertahun-tahun kemudian oleh orang lain di ruangan yang layak.

Kesimpulan salah kedua: "kalau saya tidak bisa mendengarnya, saya tidak bisa memverifikasinya." Ini justru terbalik. Sebagian besar kegagalan pengiriman imersif tidak terdengar sama sekali, bahkan di ruangan sempurna. Hitungan trek yang tidak cocok, UID yatim, blok waktu yang mundur, bed yang dijanjikan XML tetapi tidak pernah dicetak — semuanya adalah kegagalan struktural, dan semuanya bisa diperiksa oleh mesin, dari laptop, di kamar, tanpa satu pun pengeras suara ketinggian.

Yang bisa Anda lakukan tanpa ruang imersif: membuktikan bahwa berkasnya benar. Yang tidak bisa: memutuskan bahwa mixingnya bagus. Jangan tukar-tukar keduanya.

Karena itu, aturan kerja untuk studio Indonesia tanpa monitoring imersif:

1. Verifikasi struktur secara otomatis, selalu, sebelum apa pun. Ini gratis dan menangkap mayoritas penolakan.
2. Render binaural sebagai alat kerja, bukan sebagai kebenaran. Binaural berguna untuk memeriksa bahwa objek ada di sisi yang benar dan bergerak ke arah yang benar. Ia tidak bisa dipakai memutuskan keseimbangan level lapisan atas.
3. Render turunan ke tata letak yang bisa Anda dengar — 0+5+0 kalau ada, minimal 0+2+0 — dan periksa bahwa tidak ada stem yang hilang. Stem yang hilang karena rujukan menggantung akan hilang juga di downmix.
4. Simpan XML terpisah dari BW64. XML bisa Anda diff; biner hanya bisa Anda urai ulang.
5. Nyatakan keterbatasan Anda di catatan pengiriman. "Diverifikasi secara struktural; dinilai secara pendengaran hanya lewat render binaural" adalah kalimat profesional, bukan pengakuan kelemahan. Yang tidak profesional adalah membiarkan pihak berikutnya menduga.

Sebuah pemeriksa BW64/ADM berbasis peramban yang gratis tersedia di mazufa.com; ia mengurai kontainer dan metadatanya sepenuhnya di perangkat Anda sendiri dan tidak mengunggah apa pun, sehingga bisa dipakai pada materi yang secara kontrak tidak boleh keluar dari studio.

11. Daftar periksa pengiriman

Kerjakan berurutan. Pemeriksaan struktural lebih dulu — cepat, dan hasilnya membatalkan semua yang di bawahnya.

Kontainer

1. Empat byte pertama adalah BW64. Kalau RIFF, berkas itu WAV biasa dan tidak bisa melewati 4 GB.
2. ds64 adalah chunk pertama setelah tanda tangan, dan ukuran 64-bit-nya cocok dengan ukuran berkas dan ukuran data yang sebenarnya di disk.
3. Setiap chunk non-data yang kebesaran punya entri ChunkSize64 di tabel ds64.
4. Cari axml secara eksplisit, termasuk setelah data. Jangan menyimpulkan "tidak ada ADM" dari pemindaian sebagian.

Esensi

1. Laju sampel dan kedalaman bit di fmt persis sesuai spesifikasi pengiriman. Tidak ada konversi laju sampel setelah ADM ditulis — SRC membatalkan setiap rtime dan duration yang dinyatakan dalam sampel.
2. fmt.nChannels sama dengan chna.numTracks.
3. Setiap trackIndex di chna berada dalam rentang dan berbasis 1.

Integritas chna

1. Setiap entri persis 40 byte dengan medan berlebar tetap yang terganjal benar.
2. Setiap packRef bernilai 0x1000 ke atas menemukan definisi kustomnya di axml.
3. trackIndex yang berulang memang disengaja (trek yang sah berganti definisi), bukan duplikasi.

Graf ADM

1. Setiap audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef, dan audioTrackUIDRef terselesaikan. Nol sisi menggantung.
2. Tidak ada audioTrackUID yatim di kedua arah. Bangun himpunan UID dari chna dan dari axml, lalu ambil selisih simetrisnya — harus kosong. EBU Tech 3392 menyatakan maksudnya: "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."
3. Tidak ada elemen melingkar atau merujuk diri sendiri.
4. typeLabel di setiap audioChannelFormat cocok dengan audioPackFormat induknya.

Waktu

1. Channel format bermultiblok membawa rtime dan duration di setiap blok. BS.2076 tegas: "When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present."
2. Blok bersinambung dan monoton: rtime[n] + duration[n] == rtime[n+1]. EBU Tech 3392 mengetatkannya menjadi aturan kesinambungan — "rtime + duration of an audioBlockFormat should match the rtime of the following block" — dengan blok pertama sebuah objek dimulai di 00:00:00.00000, tidak ada blok yang lebih pendek dari satu sampel, dan jumlah durasi cocok dengan audioObject induknya.
3. Kegagalan waktu berkumpul dalam tiga bentuk: celah (perilaku perender tak terdefinisi — sebagian menahan posisi terakhir, sebagian membisu), tumpang tindih (blok berebut), dan blok yang urutan kronologisnya terbalik (otomasi melompat mundur).

Isi

1. Setiap kanal dari bed yang dideklarasikan berisi apa yang seharusnya. Digital black di kanal bed bukan otomatis kesalahan — mixing yang sah boleh meninggalkan kanal atas-belakang kosong — tetapi selalu layak diputuskan manusia. Pemeriksaan struktural tidak bisa menangkap ini; hanya analisis esensi yang bisa.
2. Jumlah objek dan konfigurasi bed cocok dengan spesifikasi pengiriman.
3. Timecode awal bext benar dan konsisten di seluruh berkas dalam satu set kiriman.

Render dan konform

1. Konform stereo dan binaural dirender ulang dari master saat ini, bukan dibawa dari versi sebelumnya. Kegagalan yang berulang bukan ketiadaan — ketiadaan gampang terlihat — melainkan pergeseran: konform yang dibuat dari versi lama, meleset beberapa frame, atau berbeda timecode awal. Berkas stereo yang 40 ms lebih awal dari induk imersifnya lolos pemeriksaan keberadaan berkas dan gagal saat didengarkan bersisian.
2. Durasi dan timecode awal cocok dengan master sampel-per-sampel.
3. Loudness diukur pada render bernama, ke tata letak bernama, dengan perender bernama — dan ketiganya dicatat.

Reproduktibilitas

1. Checksum setiap deliverable dan simpan manifesnya.
2. Arsipkan sesi dan XML ADM terpisah dari BW64.

Deliverable imersif tidak selesai ketika ia terdengar benar; ia selesai ketika mesin yang belum pernah mendengarnya bisa membuktikan bahwa rujukannya semua terselesaikan.

12. Penutup

BW64 dan ADM adalah standar terbuka, dipublikasikan, dan bisa dibaca siapa saja secara gratis. Itu tidak biasa di sudut industri ini, dan sebaiknya dimanfaatkan: Anda bisa membaca BS.2088 dan BS.2076 sendiri, mengurai chunk chna dengan empat puluh baris kode, dan memverifikasi apa yang benar-benar ditulis oleh eksportir sebuah perangkat lunak — bukan apa yang diklaim kotak dialognya. Untuk musik Indonesia, keterbukaan itu bernilai ganda: repertoar yang ruangnya struktural — karawitan, gong kebyar, angklung, kecak, gondang, talempong pacik — layak diarsipkan dalam format yang mampu menyimpan tata letaknya, dan tidak ada satu pun bagian dari format itu yang memerlukan izin siapa pun untuk dipelajari.

Distribusi lewat Mazufa gratis — tanpa biaya unggah, tanpa langganan, tanpa biaya per rilis — dengan satu-satunya potongan berupa 5% dari royalti yang diterima, dan setiap lamaran yang lengkap ditinjau oleh manusia.

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.2076-2 (10/2019), Audio definition model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-2-201910-S!!TOC-HTM-E.htm
• 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
• Halaman rekomendasi ITU-R BS.2127 — https://www.itu.int/rec/R-REC-BS.2127

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/docs/tech/tech3388.pdf dan https://tech.ebu.ch/publications/tech3388
• EBU Tech 3343, Practical guidelines for production and implementation in accordance with EBU R 128 — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3343v2_0.pdf
• EBU R 128, EBU Tech 3341 (meter), EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch
• EBU ADM Guidelines — chunk CHNA — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 dan 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
• Dokumentasi EBU ADM Renderer (EAR), I/O BW64 — https://ear.readthedocs.io/en/latest/BW64.html
• Implementasi acuan libbw64 — https://github.com/ebu/libbw64
• Implementasi acuan libadm — https://github.com/ebu/libadm

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/

Ditinjau terakhir September 2026. Standar direvisi dari waktu ke waktu; selalu periksa halaman ITU dan EBU di atas untuk edisi mutakhir sebelum mengutip nomor klausul.