Bir immersive master neden dalga biçimi editöründen geçip QC'de kalır

Immersive bir teslimat, bir dalga biçimi editöründe açılabilir, on iki ya da on altı sağlıklı görünen kanal gösterebilir, makul biçimde çalabilir ve yine de reddedilebilir. Nedeni yapısaldır: bir BW64 dosyasında ses ile üst veri, birebir örtüşmesi gereken iki ayrı şeydir ve formatta bunu zorlayan hiçbir şey yoktur. Bir render motoru referansları çözer. Bir editör örnekleri çizer. Farklı işler — ADM için QC'nin dinlemek değil, referans bütünlüğünü denetlemek olmasının nedeni de bu. İki standardın ne söylediği, referansların nerede koptuğu ve hangi denetimin hangi hatayı yakaladığı aşağıda.

Üç tür ses ve bu ayrımın neden her şeyi belirlediği

Immersive teslimatla ilgili her sorun, bir kanalın bu üç şeyden hangisi olduğu konusundaki karışıklıkla başlar.

Kanal tabanlı ses, her kanalı sabit bir hoparlör konumuna atar. Stereo kanal tabanlıdır, 5.1 de öyledir, 7.1.4 bir bed de öyledir. Konum, kanalın kimliğine gömülüdür: 3. kanal orta hoparlördür ve onu çalan her sistemde orta hoparlördür. ITU-R BS.2051 bunu gelişmiş ses sistemleri için resmileştirir ve düzenleri Üst + Orta + Alt katman sayıları biçiminde tarif eder — System A 0+2+0 (stereo), System B 0+5+0 (5.1), System D 4+5+0, System J 4+7+0, System H ise 9+10+3, yani 22.2 yapılandırmasıdır. ADM'de bu, DirectSpeakers typeDefinition'ı, typeLabel 0001'dir.

Nesne tabanlı ses, bir mono (ya da çok kanallı paket) sinyalin yanında zamanla değişen konum üst verisi taşır. Hangi gerçek hoparlörlerin onu çalacağına, odada bulunan düzene bakarak render motoru karar verir. Kanalın hiçbir yanı bir hoparlör varsaymaz. Bu, typeDefinition Objects, typeLabel 0003'tür.

Sahne tabanlı ses, pratikte Yüksek Dereceli Ambisonics, tüm ses alanını küresel harmonik bileşenler olarak kodlar. Hiçbir bileşen tek başına bir yöne karşılık gelmez; yön, doğrusal bileşimden doğar. Bu HOA, typeLabel 0004'tür. ADM ayrıca Mid-Side ya da Lt/Rt gibi matrislenmiş sinyaller için Matrix (0002) ve Binaural (0005) tanımlar.

Bu ayrım bir sınıflandırma merakı değildir. Kanal tabanlı bir teslimat, çıplak bir WAV olarak hayatta kalacak kadar kendini anlatır — kanal sırasını doğru yapın, çalar. Nesne tabanlı ya da sahne tabanlı bir teslimat ise üst verisi olmadan anlamsızdır: ses, birbirinden ayrışmamış bir mono akış yığınıdır ve aksini söyleyen tek şey ADM'dir. BW64 ile ADM'nin var olma nedeni işte bu asimetridir.

BW64, 32 bitlik bir sayı yüzünden var

Klasik WAV bir RIFF dosyasıdır. 1991'den gelen RIFF, her chunk'ın önüne 32 bitlik bir boyut alanı koyar. Otuz iki bit 4,294,967,296 baytı — 4 GB — adresler ve bu, hem dosyanın tamamı hem de içindeki data chunk'ı için katı bir tavandır.

48 kHz / 24-bit stereoda veri hızı saniyede 288,000 bayttır, yani 4 GB yaklaşık 4 saat 8 dakika eder. Önemsiz. 96 kHz / 24-bit, 128 kanallı nesne tabanlı bir master içinse hız saniyede 36,864,000 bayttır ve 4 GB iki dakikanın altına düşer — 116.5 saniye.

Immersive master'lar bu sınırı rutin olarak aşar; sınıra çarpan bir WAV yazıcısı ya kesilmiş bir dosya üretir ya da bildirdiği boyutları sessizce taşmış bir dosya. EBU buna önce RF64 ile yanıt verdi (EBU Tech 3306); ITU ise bunu Recommendation ITU-R BS.2088 — BW64 — olarak ileri taşıdı.

Sentinel numarası: 0xFFFFFFFF ve bir ds64 chunk'ı

BS.2088 mekanizma konusunda nettir. "The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file" ve özgün 32 bitlik boyut alanları birer kaçış bayrağına dönüşür: "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

Numaranın tamamı bu ve açıkça söylemekte fayda var: BW64, RIFF'in boyut alanlarını genişletmez. Onları sentinel olarak 0xFFFFFFFF ile doldurur ve gerçek 64 bitlik boyutları, dosyada ilk sırada durması gereken bir ds64 chunk'ına koyar. Dolayısıyla 4 GB altındaki bir BW64 dosyası, dört karakterlik imza dışında her bakımdan bir WAV okuyucusuyla bayt düzeyinde uyumludur. Birçok araç onu kabul eder; bazıları inatla etmez.

Chunk'lar ve girdi başına tam 40 bayt olan

BS.2088'e göre bir BW64 dosyasının en azından ds64, fmt , chna, axml (alternatif üst veri taşıyıcıları olarak bxml ve sxml ile birlikte) ve dalga verisini içermesi beklenir.

ds64, imzadan sonraki ilk chunk olmak zorundadır, çünkü bir okuyucunun başka bir şeyi gezebilmesi için önce gerçek boyutları bilmesi gerekir. Dosyanın tamamının boyutu ile data boyutu için 32 bitlik alt/üst yarılar taşır; ayrıca aşırı büyümüş diğer chunk'lar için bir ChunkSize64 girdileri tablosu tutar — binlerce nesneyi örnek hassasiyetinde otomasyonla tarif eden bir axml chunk'ı da 4 GB'a yaklaşabilir veya onu aşabilir.

fmt , standart WAVE format chunk'ıdır — örnek formatı, örnekleme hızı, kanal sayısı, örnek başına bit, blok hizalama. data içinde kaç adet iç içe geçmiş kanal olduğuna dair tek yetkili ifade odur. Sonrasındaki her şey, o kanallar hakkında üst veridir ve üst veri yalan söyleyebilir.

chna, fiziksel kanallar ile ADM arasındaki köprüdür. ckID, ckSize, 2 baytlık bir numTracks ve 2 baytlık bir numUIDs alanından sonra, her biri tam 40 bayt olan sabit genişlikte audioID girdilerinden oluşan düz bir dizi tutar:

2 + 12 + 14 + 11 + 1 = 40. Genişlikler tavsiye niteliğinde değildir: sabit genişlikte ASCII'dir ve 13 karakterlik bir UID yazan bir araç, biraz sıra dışı değil, bozuk bir tablo üretmiştir.

Kimlik yazım kuralı da önemlidir. 0x0FFF ve altındaki değerler ADM ortak tanımlarına — standart, önceden tanımlı kanal ve paket formatlarına — işaret ederken, 0x1000 ve üstü, axml içinde bulunması zorunlu özel tanımları gösterir. AP_00010003 ortak tanım gereği 5.1'dir ve XML gerektirmez; AP_00031001 ise özel bir nesne paketidir ve XML ister, yoksa boşta kalır.

numUIDs, numTracks'ten fazla olabilir ve bu meşrudur: EBU'nun rehberi, "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" der; yani tek bir trackIndex birden fazla girdide görünebilir. Kanal başına tek UID varsayan QC araçları, doğru dosyaları bozuk diye işaretler.

axml, <audioFormatExtended> ağacını içeren bir UTF-8 XML belgesidir. ADM odur ve ilginç hataların neredeyse tamamı orada yaşar. data ise sade, iç içe geçmiş PCM'dir; içindeki hiçbir şey nesnelerden haberdar değildir.

Sıralama: her zaman önce ds64; data'dan önce fmt . Ama axml meşru biçimde data'dan sonra durabilir ve çoğu zaman durur, çünkü — BS.2088'in belirttiği gibi — kayıt sırasında "the XML metadata will likely be of an unknown length." Sonunda axml bulunan bir dosya hatalı değildir, ama yalnızca ilk megabaytı tarayan bir okuyucu hiç ADM bulunmadığını bildirir. "Dosyamda üst veri yok" bildirimlerinin şaşırtıcı bir kısmı buradan gelir.

ADM bir graftır ve hatalar kopmuş kenarlardır

ITU-R BS.2076'nın hiyerarşisi audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat biçiminde ilerler; yaprak ise audioTrackUID'dir ve fiziksel bir kanala karşılık gelen tek öğe odur.

Bu, iç içe geçmiş bir belge değil, bir referans grafıdır ve ciddi her teslimat hatası, o graftaki kopmuş bir kenardır. Boşta kalan bir referansı tehlikeli kılan şey, biri koptuğunda tek bir davranışın olmamasıdır. XML'de bulunmayan bir paketi adlandıran audioPackFormatIDRef'i çözmeye çalışan bir render motoru, ayrıştırmayı yarıda kesip dosyayı reddedebilir; o nesneyi atlayıp geri kalan her şeyi render ederek sessizce bir stem'i eksik bir miks üretebilir; ya da ortak tanımlara düşüp 0x1000 ve üstü özel aralıkta karşılığı olmayan bir kimlik bulup yerine sessizlik koyabilir. Üç sonucun da adı "dosya açıldı"dır. Yalnızca biri dinleyerek yakalanır, o da orada ne olması gerektiğini biliyorsanız.

Redlerin çoğunu açıklayan dört hata

fmt kanal sayısının chna ile uyuşmaması. fmt .nChannels 16 diyor; chna.numTracks 14 diyor. Dosya daha ilk iki chunk'tan itibaren kendi içinde tutarsızdır — genellikle üst veri hazırlandıktan sonra kanal sayısı değişen bir bounce'tan ya da chna'yı yeniden yazmadan kanal düşüren bir araçtan kaynaklanır. Tespit, iki tam sayıyı ayrıştırıp karşılaştırmaktır: hattaki en ucuz denetim ve hataların şaşırtıcı bir bölümünü yakalıyor. Aynı anda her trackIndex'in 1 … fmt .nChannels aralığında olduğunu da doğrulayın.

Hiçbir nesnenin referans vermediği bir audioTrackUID. chna'da olup hiçbir audioObject'in referans vermediği bir UID, hiçbir şeyin render etmeyeceği bir sesin var olduğu anlamına gelir; aynanın diğer yüzü, yani XML'de olup chna'da karşılığı bulunmayan bir audioTrackUIDRef, üst verinin orada olmayan bir kanalı beklediği anlamına gelir. UID kümesini chna'dan, diğerini axml'den kurun ve simetrik farkı alın; boş olmalıdır. EBU Tech 3392 niyeti doğrudan söyler: "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

Geriye doğru işleyen blok zamanlaması. BS.2076 açıktır: "When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." EBU Tech 3392 bunu bitişikliğe kadar sıkılaştırır — "rtime + duration of an audioBlockFormat should match the rtime of the following block" — bir nesnenin ilk bloğu 00:00:00.00000'da başlar, hiçbir blok bir örnekten kısa olmaz ve süreler üst audioObject'e toplanır. Blokları belge sırasında yürüyün ve rtime[n] + duration[n] == rtime[n+1] iddiasını sınayın. Hatalar üç biçimde gelir: boşluklar — render motorunun davranışı tanımsızdır, bazıları son konumu tutar, bazıları susar; örtüşmeler — bloklar birbiriyle çekişir; ve kronolojik sırası bozuk bloklar — bu, otomasyonun program ortasında geriye sıçramasıdır.

XML'de tarif edilip diske hiç yazılmamış bir bed. XML 7.1.4'lük bir DirectSpeakers paketi — on iki kanal — beyan ediyor, ama yalnızca 5.1 alt kümesi yazılmış, ya da yükseklik kanalları bounce sırasında susturulup dijital siyah olarak yazılmış. Referans grafı sağlamdır; ses değildir. Yapısal denetimler bunu yakalayamaz: esas ses analizine ihtiyacınız var, yani bir DirectSpeakers paketinin iddia ettiği her kanalda hiç sinyal olup olmadığını ölçmeye. Beyan edilmiş bir bed kanalındaki dijital siyah kendiliğinden bir hata değildir — meşru bir miks, üst-arka bir kanalı boş bırakabilir — ama her zaman bir insanın karar vermesine değer.

Immersive ses yüksekliği hakkında ne yayımlanmış, ne yayımlanmamış

Bir sayı, stereodan geçişten sağ çıkamıyor ve nedenini söylemekte fayda var.

BS.1770-5 (November 2023) güncel baskıdır; BS.1770-4 yürürlükten kalkmıştır, gerçi sahadaki ölçerlerin çoğu hâlâ onu anar. Çekirdek algoritması L, R ve C'yi 1.0, Ls ve Rs'yi 1.41 (yaklaşık +1.5 dB) katsayısıyla ağırlıklandırır, LFE'yi dışarıda bırakır ve kapsamı "from one to five channels" ile sınırlıdır. BS.1770-5, eklerinde bunun ötesine geçer ve BS.2051 gelişmiş ses sistemleri ile nesne tabanlı sesi kapsar — ki nesne tabanlı ses, ölçülebilmesi için önce render edilmek zorundadır. Dolayısıyla immersive ses yüksekliği dosyanın değil, bir render'ın özelliğidir ve hedef düzeni değiştirmek sayıyı değiştirir. BS.2127 uyumlu bir render'ı, adı konmuş bir BS.2051 düzenine, BS.1770-5 ölçeriyle ölçün ve üçünü birden teslimat notlarınıza yazın; BS.2127 referans ADM render motorunu tanımlar ve açık kaynaklı kardeşi EBU ADM Renderer (EBU Tech 3388), yeniden üretilebilir bir rakam elde etmenin pratik yoludur.

Hiçbir müzik yayın servisi, immersive teslimat için entegre bir ses yüksekliği hedefi yayımlamıyor. Forumlarda ve satıcı eğitim materyallerinde rakamlar dolaşıyor; hiçbiri yayımlanmış bir şartname değil ve bu yazı hiçbirini öyleymiş gibi tekrarlamayacak. Yayımlanmış olan, kanal tabanlı stereo içindir — Spotify'ın entegre −14 LUFS hedefi ile −1 dBTP gerçek tepe tavanı, −14 LUFS üzerinde −2 dBTP'ye sıkışması ve AES TD1008'in müzik için −16 LUFS'i (onun −18 LUFS rakamı söz ağırlıklı içerik içindir ve −18'i müzik hedefi diye sunmak sık yapılan, ciddi bir hatadır).

Dolby Atmos, Dolby Laboratories'in tescilli ve lisanslı bir teknolojisidir; Sony 360 Reality Audio ise MPEG-H üzerine kurulu tescilli bir sistemdir. Gereklilikleri sahipleri tarafından belirlenir, ITU ya da EBU takvimlerine bakılmaksızın değişir ve burada belirtilmez; hiçbir bağlantı ya da onay iddia edilmemektedir. Lisans verenin kendi güncel belgelerini okuyun.

Göndermeden önce neyi denetlemeli

Önce yapısal denetimler; hem hızlıdırlar hem de sonrasındaki her şeyi geçersiz kılarlar.

• İlk dört bayt BW64 olmalı. RIFF okuyorsa bu düz bir WAV'dır ve 4 GB'ı aşamaz.
• ds64 imzadan sonraki ilk chunk olmalı, 64 bitlik boyutları diskteki dosya ve data boyutlarıyla uyuşmalı ve aşırı büyümüş her data dışı chunk'ın tabloda bir ChunkSize64 girdisi bulunmalı.
• axml'i açıkça bulun, data'dan sonrasını da tarayarak — kısmi bir taramadan asla "ADM yok" sonucunu çıkarmayın.
• fmt örnekleme hızı ve bit derinliği teslimat şartnamesiyle birebir uyuşmalı. ADM yazıldıktan sonra örnekleme hızı dönüşümü yok — bu, örnek cinsinden ifade edilmiş her rtime ve duration'ı geçersiz kılar.
• fmt .nChannels, chna.numTracks'e eşit olmalı; her trackIndex aralıkta ve 1'den başlıyor olmalı.
• Her chna girdisi tam 40 bayt, sabit genişlikte alanları doğru doldurulmuş olmalı ve 0x1000 ve üstündeki her packRef, axml içinde bulunan bir özel tanıma çözülmeli.
• Her audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef ve audioTrackUIDRef çözülmeli. Her iki yönde de sıfır boşta kenar, döngüsel referans yok.
• Çok bloklu kanal formatları her blokta hem rtime hem duration taşımalı; bloklar bitişik ve tek yönlü artan olmalı; nesneler 00:00:00.00000'da başlamalı.
• Beyan edilmiş bir bed'in her kanalı içermesi gerekeni içermeli. Dijital siyahı araştırın.
• bext başlangıç zaman kodu set genelinde tutarlı olmalı; stereo ve binaural uyarlamalar ise güncel master'dan yeniden render edilmiş olmalı. Immersive ebeveynine göre 40 ms erken bir uyarlama, dosya varlığı denetiminden geçer ve senkronlu bir dinlemede kalır.
• Her teslimatın sağlama toplamını alın, manifesti saklayın ve ADM XML'ini BW64'ten ayrı arşivleyin — fark alabildiğiniz bir XML, ileride yalnızca yeniden ayrıştırabildiğiniz bir ikili dosyadan daha değerlidir.

BW64 ve ADM açık, yayımlanmış, serbestçe okunabilir standartlardır ve bunu kullanmakta fayda var: BS.2088 ile BS.2076'yı kendiniz okuyabilir, kırk satır kodla bir chna chunk'ını ayrıştırabilir ve bir satıcının dışa aktarıcısının iletişim kutusunda iddia ettiğini değil, gerçekte ne yazdığını doğrulayabilirsiniz. Gereksiz immersive redlerinin neredeyse tamamı, bir doğrulayıcının bir saniyenin altında yakaladığı referans bütünlüğü hatalarıdır.

Mazufa'nın ücretsiz BW64/ADM inceleyicisi mazufa.com/immersive-master-check adresinde; kapsayıcıyı ve üst veriyi tamamen kendi cihazınızda ayrıştırır ve hiçbir şey yüklemez, bu da onu sözleşme gereği binadan çıkamayacak malzemede kullanılabilir kılar. Mazufa'nın kendisinde yayınlamak ücretsizdir, komisyonu 0%'dır ve yalnızca davetle çalışır; eksiksiz her başvuruyu bir insan inceler.

Kaynaklar

ITU-R Tavsiye Kararları

• 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

EBU teknik belgeleri

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (ve ekleri), 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
• libbw64 referans uygulaması — 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/

Servis belgeleri

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