BW64 ve ADM: Sürükleyici Ses Teslimi İçin Teknik Referans

Fasıl heyetinin sabit oturma düzeninden, ney ile kanunun kendi uzamsal kimliğine, kubbeli bir salonun yankı alanından chna chunk'ının 40 baytlık kaydına kadar — nesne tabanlı master hazırlayan ve "Atmos teslimatı" denen dosyayı QC'den geçirmesi istenen mühendisler için.

Kısa cevap

ADM (Audio Definition Model, ITU-R BS.2076), bir dosyadaki her ses parçasının ne olduğunu — sabit bir hoparlör kanalı mı, hareketli bir nesne mi, yoksa bir Ambisonik bileşen mi — ve bunların bir programı nasıl kurduğunu tarif eden açık bir meta veri (metadata) standardıdır. Bu XML, BW64 (ITU-R BS.2088) adlı kapsayıcının içinde taşınır; BW64, klasik RIFF/WAVE'in 4 GB tavanını aşmak için tasarlanmış 64-bit bir uzantıdır. Sürükleyici teslimatların QC'den dönmesinin sebebi neredeyse hiçbir zaman "kötü ses" değildir: ses ile meta veri iki ayrı şeydir, birbirleriyle harfi harfine uyuşmak zorundadır ve dosya biçiminde bu uyumu zorlayan hiçbir mekanizma yoktur. fmt içindeki kanal sayısının chna tablosuyla tutmaması, hiçbir nesnenin referans vermediği bir audioTrackUID, zamanı geriye akan bir blok, XML'de tarif edilip diske hiç basılmamış bir bed — bunların hepsi dalga formu editöründe sessizdir ve renderer için ölümcüldür. Sürükleyici QC dinleme işi değil, referans bütünlüğü denetimidir. Türkiye'deki pratik sonuç şudur: 12 hoparlörlük bir oda kurmadan da doğru dosya teslim edebilirsiniz, ama dosyayı doğrulamadan teslim edemezsiniz.

1. Üç tür ses, ve fasıl heyetinin neden ders kitabı örneği olduğu

Kapsayıcıdan önce model gelir. Sürükleyici teslimattaki her sorun, bir parçanın aslında bu üç şeyden hangisi olduğunun karıştırılmasıyla başlar.

Kanal tabanlı ses (channel-based), her parçayı 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ülmüştür: 3 numaralı parça merkez hoparlördür ve onu çalan her sistemde merkez hoparlördür. ITU-R BS.2051 bunu gelişmiş ses sistemleri için biçimlendirir ve düzenleri Üst + Orta + Alt katman sayısıyla adlandırır: 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 = 9+10+3 (yani 22.2). ADM'de kanal tabanlı içerik DirectSpeakers typeDefinition'ını, typeLabel 0001'i kullanır.

Nesne tabanlı ses (object-based), mono (ya da çok kanallı bir pack) sinyalin yanında, zaman içinde değişen konum meta verisi taşır. Hangi gerçek hoparlörlerin bu sesi üreteceğine, odada fiilen bulunan düzene bakarak renderer karar verir. Parçanın kendisi hiçbir hoparlörü varsaymaz. Bu, typeDefinition Objects, typeLabel 0003'tür.

Sahne tabanlı ses (scene-based), pratikte Yüksek Mertebeli Ambisonik (HOA), tüm ses alanını küresel harmonik bileşenler kümesi olarak kodlar. Hiçbir bileşen tek başına bir yöne karşılık gelmez; yön, doğrusal birleşimden doğar. typeDefinition HOA, typeLabel 0004. ADM ayrıca matrislenmiş sinyaller (Mid-Side, Lt/Rt) için Matrix (0002) ve kulaklığa hazır çiftler için Binaural (0005) tanımlar.

Kanal tabanlı ses dosyaya hoparlörlerin nerede olduğunu söyler; nesne tabanlı ses tahmin etmeyi reddeder; sahne tabanlı ses ise kaynakları değil, alanın kendisini tarif eder.

1.1. Fasıl heyeti: oturma düzeni zaten meta veridir

Bu ayrım akademik değildir ve Türkiye'de bunun en temiz örneği bir fasıl heyetidir. Bir fasıl heyetinde oturma düzeni tesadüfi değildir: sazendeler bir yay çizer, kanun genellikle bir uçta ve alçakta durur çünkü icracı önündeki mandalları görmek zorundadır; ney orta bölgede, mikrofona göre açısı nefes gürültüsünü belirleyecek biçimde durur; ud ve tanbur arka sırada, kudüm ve bendir merkezin gerisinde; hanendeler ise ayrı bir sıra oluşturur. Bu düzen prova edilmiş, tekrarlanabilir ve sabittir — bir icradan diğerine değişmez, çünkü heyetin iç dengesi buna göre kurulmuştur.

İşte bu, nesne tabanlı sesin ideal vakasıdır. Her sazın gerçek dünyada zaten bir azimutu ve bir yüksekliği vardır; siz bunu uydurmuyorsunuz, kayda geçiriyorsunuz. Kanunun sağ önde, neyin merkezin biraz solunda ve biraz yukarıda, kudümün merkezin gerisinde ve alçakta olması bir "efekt" değil, salonda oturan bir dinleyicinin duyduğu şeydir. audioBlockFormat içine yazdığınız azimuth / elevation değerleri, ölçtüğünüz oturma planının sayısal karşılığıdır.

Nesne tabanlı temsilin buradaki gerçek kazancı da sabitlemedir: heyet 5.1'de de, 7.1.4'te de, kulaklıkta binaural olarak da dinlenecek. Kanal tabanlı bir mikste kanunu "sol-arka hoparlöre" yazdığınızda, o hoparlörün olmadığı bir düzende ne olacağını downmix matrisi belirler. Nesne olarak yazdığınızda, BS.2127 renderer'ı o düzende mevcut hoparlörlerle aynı algısal yönü kurmaya çalışır. Yani heyetin düzeni, hoparlör sayısından bağımsız olarak korunur.

1.2. Ney ve kanun: gerçekten ayrı kaynaklar

Her saz nesne olmayı hak etmez; bazıları bed'in içinde yaşamalıdır. Ama ney ve kanun, Türk müziğinde nesne olmak için en güçlü iki adaydır ve sebepleri birbirinden farklıdır.

Ney, yönelimi (directivity) çok belirgin bir kaynaktır ve üflemeli olduğu için sinyalin bir kısmı ses değil, nefestir. Nefes gürültüsü, üfleme kenarına yakın mikrofonda baskın, uzakta neredeyse yoktur. Bunu bed'in içine yaydığınızda ney "içi boş" bir hale gelir; ayrı bir nesne olarak, kendi yakın mikrofonuyla ve kendi konumuyla taşıdığınızda, icracının nefesi ile enstrümanın rezonansı arasındaki ilişki korunur. Ayrıca ney taksimi çoğu fasılda tek başına başlar: programın ilk iki dakikasında sahnede tek bir kaynak vardır ve heyetin geri kalanı sessizdir. Nesne tabanlı model bunu doğal olarak ifade eder — audioObject'in start ve duration alanları taksimin süresini taşır.

Kanun başka bir sebeple ayrılır: transient yoğunluğu ve mandal. 70'ten fazla telli, mızrapla çalınan, çok hızlı geçkiler yapan bir enstrümandır; mandal değişimleri icra sırasında duyulur ve komanın mikro-tonal bilgisi tam da bu detayda yaşar. Yankı alanının içine gömülmüş bir kanun, koma farklarını duyulamaz hale getirir. Ayrı bir nesne olarak, kendi yakın mikrofonuyla ve kontrollü bir yankı gönderimiyle, hem yerinde durur hem net kalır.

Buna karşılık kudüm, bendir ve halile çoğu zaman bed'e aittir: heyetin nabzını verirler, salonu bütünüyle uyarırlar ve tek bir noktaya sıkıştırıldıklarında yapay durur. Bu ayrımı yapmak — neyin nesne, neyin bed olacağına karar vermek — sürükleyici bir Türk müziği kaydındaki en önemli sanatsal karardır ve teknik değil, müzikal bir karardır.

2. Tarihî mekânda kayıt: bed artı nesne neden doğru temsildir

Türkiye'de sürükleyici sesin en güçlü gerekçelerinden biri repertuvar değil, mekândır. Kubbeli büyük bir salon, taş avlulu kervansaray tipi bir yapı, bedesten benzeri tonozlu bir hacim — bunlar kaydın arka planı değil, kaydın konusudur. Böyle bir mekânda kubbe altındaki geç yankı alanı, kaynaklardan bağımsız bir davranış gösterir: enerji yatay düzlemde dolaşır, kubbeden geriye döner, ve dinleyicinin üstünde stereo bir çiftin asla taşıyamayacağı bir örtü oluşturur.

Bu, kanal tabanlı bir bed'in tam olarak doğru araç olduğu durumdur. Yankı alanı yönsüz değil ama noktasal da değildir; onu nesnelere bölmenin bir anlamı yoktur, çünkü "kubbenin yankısı" diye tek bir kaynak yoktur. Bunun yerine mekâna bir ambiyans dizisi (yatay bir ana dizi artı bir yükseklik katmanı) kurar, çıktısını doğrudan 7.1.4 gibi bir bed'e basar ve yankı alanını olduğu gibi kaydedersiniz. Yakın mikrofonlanan sazlar ise nesne olarak üstüne gelir.

Ortaya çıkan temsil şudur:

• Bed (kanal tabanlı, DirectSpeakers, 0001) — mekânın kendisi. Bu, System J (4+7+0) düzenine karşılık gelen 12 parçalık bir yatak olarak basılır.
• Nesneler (Objects, 0003) — ney, kanun, ud, tanbur, kemençe, kemanlar, hanendeler. Her biri kendi konumuyla.

Bu ikisinin birlikteliği tesadüf değil, ADM'in tasarlandığı şeydir. audioProgramme altında bir audioContent "mekân", bir başkası "heyet" olabilir; her biri kendi audioObject'lerini referanslar.

Burada dürüst olmak gereken bir nokta var: böyle bir mekânda çekim yapmak, RT60'ı ölçmeden yapılacak bir iş değildir ve bu belge size o mekânın yankı süresine dair bir sayı veremez, çünkü her yapı farklıdır ve yayımlanmış genel bir değer yoktur. Ölçün, kaydedin, teslim notlarına yazın. Uzun yankılı bir hacimde nesnelerin duration değerlerini yankı kuyruğunu kesecek biçimde kısa tutmak, sürükleyici kayıtlarda en sık yapılan ve en zor fark edilen hatalardan biridir: nesne bittiğinde renderer o kaynağı bırakır, ama kuyruğun bed'de devam etmesi gerekir. Kuyruğu nesneye bindirdiyseniz, kesilir.

3. BW64 neden var: 4 GB duvarının aritmetiği

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

48 kHz / 24-bit stereo için 4 GB kabaca altı buçuk saattir: konu bile değildir. Sürükleyici bir teslimatta ise duvar çok yakındır. Somut bir Türk örneğiyle hesaplayalım.

Bir fasıl heyeti kaydı: 12 parçalık 7.1.4 bed + 14 nesne parçası (ney, kanun, ud, tanbur, kemençe, keman 1, keman 2, kudüm, bendir, darbuka, hanende 1–3, ve bir spot ambiyans) = 26 parça, 24-bit, 96 kHz.

Saniyedeki bayt = 96 000 × 3 bayt × 26 kanal = 7 488 000 bayt/s
4 GB sınırı      = 4 294 967 296 bayt
Sınıra kalan süre = 4 294 967 296 ÷ 7 488 000 ≈ 573,6 saniye ≈ 9 dakika 34 saniye

Dokuz buçuk dakika. Bir fasıl takımı peşrevden son saz semaisine kadar rahatlıkla 50 dakikadır. 52 dakikalık bir çekimde:

3 120 s × 7 488 000 bayt/s = 23 362 560 000 bayt ≈ 23,36 GB

Yani sınırın beş katından fazlası. 48 kHz'de bile (3 744 000 bayt/s) duvara 19 dakika 7 saniyede çarparsınız. Sınıra çarpan bir WAV yazıcısı ya dosyayı budar ya da beyan ettiği boyutlar sessizce taşmış bir dosya üretir; ikincisi daha kötüdür, çünkü dosya açılır.

EBU bu sorunu önce RF64 (EBU Tech 3306) ile çözdü. ITU bu çalışmayı devraldı ve ITU-R BS.2088, Long-form file format for the international exchange of audio programme materials with metadata — yani BW64 — olarak yayımladı. BS.2088 mekanizmayı açıkça yazar:

"The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file." — ITU-R BS.2088

ve

"If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead." — ITU-R BS.2088

Numaranın tamamı budur ve açıkça söylemekte fayda var:

BW64, RIFF'in boyut alanlarını genişletmez; onları 0xFFFFFFFF ile bir işaret (sentinel) olarak doldurur ve gerçek 64-bit boyutları, dosyanın başında yer almak zorunda olan bir ds64 chunk'ına koyar.

BW64'ü tek bir soyağacının üçüncü kuşağı olarak okumak en doğrusudur. RIFF/WAVE chunk'lı kapsayıcıyı verdi. Broadcast Wave (BWF, EBU Tech 3285) bext chunk'ını ekledi — originator, zaman kodu referansı, coding history — ve WAV'ı yayıncılık değişim formatına çevirdi. BW64 bunların hepsini korur, 64-bit adreslemeyi ve ADM'i taşıyan chunk'ları ekler. 4 GB'ın altındaki bir BW64 dosyası, dört karakterlik dosya imzası dışında her bakımdan bir WAV okuyucusuyla bayt uyumludur; birçok araç kabul eder, bazıları inatla etmez.

4. Chunk yerleşimi, bayt bayt

BS.2088'e göre bir BW64 dosyasında en azından <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (alternatif meta veri taşıyıcıları olarak <bxml-ck> ve <sxml-ck>) ve <wave-data> bulunması beklenir.

4.1. ds64 — 64-bit boyut tablosu

BW64 imzasından hemen sonra, ilk chunk olmak zorundadır, çünkü okuyucunun dosyada yürümeye başlamadan önce gerçek boyutları bilmesi gerekir. Alanları, 64-bit büyüklüklerin 32-bit yarımlarıdır:

Tablosuz bir ds64'ün toplam boyutu doğrudan çıkar: 8 bayt başlık (ckID + ckSize) + 24 bayt üç adet 64-bit alan + 4 bayt tableLength = 36 bayt. Tablodaki her kayıt bir chunk kimliği (4) artı düşük (4) ve yüksek (4) sözcük, yani 12 bayttır; iki kayıtlı bir ds64 36 + 24 = 60 bayttır.

Yukarıdaki 52 dakikalık fasıl dosyasında sayılar şöyle oturur. data chunk'ının gerçek boyutu 23 362 560 000 bayt. Bunu 32-bit sözcüklere ayırırız:

23 362 560 000 ÷ 4 294 967 296 = 5 tam, kalan
23 362 560 000 − (5 × 4 294 967 296)
                = 23 362 560 000 − 21 474 836 480
                = 1 887 723 520

dataSizeHigh = 5            → 0x00000005
dataSizeLow  = 1 887 723 520 → 0x70846000

Aynı anda, data chunk'ının kendi 32-bit ckSize alanına 0xFFFFFFFF yazılır. Yani dosyada iki yerde boyut vardır: biri kasten geçersizdir ve okuyucuyu ds64'e yönlendirir, diğeri gerçektir. bw64SizeHigh de bu dosyada 5'tir, çünkü toplam boyut data artı meta veri chunk'larıdır ve 4 GB sınırının çok üstündedir.

table[] göründüğünden önemlidir. Binlerce nesneyi örnek doğruluğunda otomasyonla tarif eden bir axml chunk'ı tek başına 4 GB'a yaklaşabilir; data dışındaki herhangi bir chunk'ın 64-bit boyut beyan edebilmesinin tek yolu bu tablodur.

4.2. fmt — özün (essence) tarifi

Standart WAVE format chunk'ı: örnek biçimi, örnekleme hızı, kanal sayısı, örnek başına bit, block align. data içinde fiilen kaç kanalın araya geçmiş (interleaved) olduğuna dair tek yetkili beyan budur. Aşağıdaki her şey o kanallar hakkında meta veridir ve meta veri yalan söyleyebilir.

4.3. chna — kanal ayırma tablosu ve 40 baytlık kayıt

chna, fiziksel parçalar ile ADM arasındaki köprüdür. Başlangıcı:

• ckID — 4 bayt, 'chna'
• ckSize — 4 bayt
• numTracks — 2 bayt, dosyadaki parça sayısı
• numUIDs — 2 bayt, ardından gelen audioTrackUID kaydı sayısı

Ardından sabit genişlikli audioID kayıtlarından oluşan düz bir dizi gelir. Her kayıt tam olarak 40 bayttır:

Aritmetiği açıkça yapalım:

 2  (trackIndex)
12  (UID          — "ATU_0000000D", 12 ASCII karakter)
14  (trackRef     — "AT_00031001_01", 14 ASCII karakter)
11  (packRef      — "AP_00031001", 11 ASCII karakter)
 1  (pad)
---
40 bayt / kayıt

Alan genişlikleri tavsiye değildir; sabit genişlikli ASCIItir. 13 karakterlik bir UID yazan bir yazıcı, "biraz alışılmadık" değil, bozuk bir tablo üretmiştir; çünkü 40 baytlık ızgara kayar ve o noktadan sonraki bütün kayıtlar okunamaz hale gelir.

26 parçalı fasıl dosyamızda chna chunk'ının tamamı:

kayıtlar   : 26 × 40 = 1040 bayt
numTracks  :  2 bayt
numUIDs    :  2 bayt
ckSize alanına yazılan değer = 1040 + 2 + 2 = 1044 bayt
chunk'ın diskteki toplam boyutu = 1044 + 8 (ckID + ckSize) = 1052 bayt

1044 çift sayı olduğu için chunk sonunda ek dolgu gerekmez.

Kimlik konvansiyonuna da dikkat: 0x0FFF ve altındaki değerler ADM'in ortak tanımlarına (common definitions) — standart, önceden tanımlı kanal ve pack biçimlerine — atıf yapar; 0x1000 ve üstü ise axml chunk'ında bulunması zorunlu özel tanımları gösterir. AP_00010003 ortak tanım gereği 5.1'dir ve XML gerektirmez; AP_00031001 özel bir nesne pack'idir ve XML'de karşılığı yoksa boşta kalır (dangling).

Track UID, tek bir fiziksel parçanın kimliği için dosyanın verdiği seri numarasıdır ve bir parçanın program boyunca taşıdığı şeyin meşru olarak değişebilmesi için vardır.

Bu son cümle, numUIDs'in numTracks'ten büyük olabilmesinin sebebidir. EBU'nun rehberi açıkça yazar: bir dosyanın seyri içinde "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." Fasıl örneğinde bu tam olarak gerçekleşir: ney parçası ilk iki dakika boyunca tek başına, serbest ritimli bir taksim nesnesidir; heyet girdikten sonra aynı fiziksel parça, heyet pack'inin bir üyesi olarak tanımlanır. Bu durumda numTracks = 26, numUIDs = 27 olur ve trackIndex = 13 iki ayrı kayıtta görünür:

kayıtlar   : 27 × 40 = 1080 bayt
ckSize     : 1080 + 4 = 1084 bayt
toplam     : 1092 bayt

Her parçaya bir UID varsayan QC araçları, doğru dosyaları bozuk diye işaretler. Bu, Türkiye'de taksimle açılan hemen her sürükleyici kayıtta karşınıza çıkacak bir durumdur.

4.4. axml — ADM'in kendisi

UTF-8 kodlu bir XML belgesi; içinde <audioFormatExtended> ağacı bulunur. ADM budur. Metindir, incelenebilir, ve ilginç arızaların neredeyse tamamı burada yaşar.

4.5. data — araya geçmiş PCM

WAV'daki gibi düz, araya geçmiş örnekler. data içindeki hiçbir şey nesnelerden haberdar değildir.

4.6. Sıralama

ds64 her zaman ilk. fmt , data'dan önce. axml ise meşru olarak data'dan sonra yerleştirilebilir ve çoğu zaman öyle yapılır; çünkü BS.2088'in kendi gerekçesiyle, kayıt sırasında "the XML metadata will likely be of an unknown length." Sonunda axml taşıyan bir dosya bozuk değildir; ama dosyanın yalnızca ilk birkaç yüz kilobaytını tarayan bir okuyucu "ADM yok" diye rapor eder. "Dosyamda meta veri görünmüyor" şikâyetlerinin şaşırtıcı bir kısmı tek başına bu maddedir.

5. ADM nesne modeli

ITU-R BS.2076 modeli iki yarıya böler. Format kısmı — BS.2076-3'ün ifadesiyle — "describes the technical nature of the audio so it can be decoded or rendered correctly" ve henüz hiç ses yokken yazılabilir. İçerik kısmı ise "the language of dialogue, the loudness, etc." gibi şeyleri tarif eder ve ancak sinyaller varken tamamlanabilir. Bir hatanın hangi yarıya ait olduğunu bilmek, onu üretimin hangi aşamasının soktuğunu söyler.

Hiyerarşi, yukarıdan aşağı:

• audioProgramme — tek bir tam sunum. Bir veya daha fazla audioContent'e referans verir.
• audioContent — programın editoryal anlamı olan bir bileşeni: "heyet", "mekân ambiyansı", "hanende grubu". Bir veya daha fazla audioObject'e referans verir.
• audioObject — editoryal niyet ile teknik biçimin birleştiği yer. Başlangıç zamanı ve süre taşır; sıfır veya daha fazla audioPackFormat, iç içe audioObject ve audioTrackUID referanslar. İçerik ile öz burada buluşur.
• audioPackFormat — birlikte anlam taşıyan kanal grubu: 7.1.4 bed, bir stereo çift, belirli mertebeden bir HOA kümesi. audioChannelFormat öğelerine referans verir, başka pack'leri içerebilir.
• audioChannelFormat — tek bir kanalın zaman içindeki davranışı. Bir veya daha fazla audioBlockFormat içerir.
• audioBlockFormat — atom. Objects için konum (azimuth/elevation/distance ya da Kartezyen X/Y/Z), kazanç, boyut, yayınıklık (diffuseness), artı rtime ve duration. Sabit bir nesne tek bloktur; hareketli bir nesne blok dizisidir.
• audioTrackUID — yaprak, ve fiziksel bir parçaya karşılık gelen tek öğe. İsteğe bağlı sampleRate ve bitDepth nitelikleri taşır; bir audioTrackFormat ve bir audioPackFormat referanslar.

audioStreamFormat ve audioTrackFormat, kanal biçimi ile track UID arasında durur ve akış kodlamasını tarif eder. BS.2076-3, PCM için bunların fiilen gereksiz olduğunu belirtir — "the audioStreamFormat and the audioTrackFormat should be omitted" — ama okuyucuların, BS.2076-2 ve öncesine dayanan mevcut ADM dosyalarının bunları "may contain" edeceğinin farkında olması gerektiğini de yazar. Her iki biçim de yasaldır. Yalnızca birini kabul eden bir doğrulayıcı, diğeri konusunda hatalıdır.

ADM iç içe geçmiş bir belge değil, bir referans grafiğidir; ve ciddi her teslimat arızası, o grafikte kopmuş bir kenardır.

Referans boşta kaldığında ne olur? Tek bir davranış yoktur — sorun da budur. XML'de bulunmayan bir pack'i adlandıran audioPackFormatIDRef'i çözmeye çalışan bir renderer: ayrıştırmayı iptal edip dosyayı reddedebilir; o nesneyi atlayıp geri kalanını render ederek sessizce bir saz eksik bir miks üretebilir; ya da ortak tanımlara düşüp 0x1000+ aralığında karşılığı olmayan bir kimlik bulunca sessizlik koyabilir. Üçünde de "dosya açıldı" denir. Yalnızca biri dinlemekle yakalanır — o da orada ne olması gerektiğini biliyorsanız. Kanunun ikinci hanesinin sessiz olduğunu, o hanenin var olduğunu bilmeyen bir kulak duyamaz. Sürükleyici QC'nin otomatikleştirilmek zorunda olmasının sebebi budur.

6. BS.2051 düzenleri ve BS.2127 renderer'ı

Nesne tabanlı bir dosya bir mikse eşit değildir; miksin tarifidir. Sesi duymak için onu bir hoparlör düzenine render etmeniz gerekir ve ITU bunun için referans bir renderer tanımlamıştır: ITU-R BS.2127, Audio Definition Model renderer for advanced sound systems. Açık kaynaklı kardeşi EBU ADM Renderer (EAR, EBU Tech 3388), aynı davranışı tekrarlanabilir biçimde elde etmenin pratik yoludur.

Bu, sürükleyici sesin stereo ile arasındaki en temel farkı doğurur:

Sürükleyici bir teslimatın tek bir "sesi" yoktur. Ne kadar render hedefi varsa o kadar sesi vardır ve hedef düzeni değiştirmek, çıkan sonucu değiştirir.

Fasıl kaydımız System J (4+7+0) hedefinde render edildiğinde, kanunun sağ öndeki konumu iki hoparlör arasında paylaştırılır. System B (0+5+0) hedefinde aynı konum farklı bir çift arasında paylaştırılır ve yükseklik bilgisi yatay düzleme indirilir. System A (0+2+0) hedefinde ise heyetin tamamı iki hoparlöre iner. Üçü de doğrudur, üçü de farklıdır ve hiçbiri diğerinin yerine geçmez.

Pratik sonuç şudur: teslim notlarınızda bir düzen adı geçmiyorsa, o notta yazan hiçbir ölçüm doğrulanabilir değildir. "System J'ye BS.2127 uyumlu render" cümlesi bir spesifikasyondur; "Atmos'ta ölçüldü" cümlesi değildir.

7. BS.1770-5 ile sürükleyici içerikte ses yüksekliği

Burada yayımlanmış olan ile dolaşımda olanı ayırmak şart.

BS.1770 ne tanımlar. BS.1770 K-ağırlıklandırmayı tanımlar: katı bir küreyi modelleyen bir high-shelf "kafa" filtresi, ardından bir RLB yüksek geçiren filtre. Eğrinin 1 kHz'deki kazancı +0,698 dB'dir (doğrusal 1,0836). Ölçüm %75 örtüşmeli 400 ms bloklarla yapılır; mutlak kapı −70 LKFS altındaki blokları atar; göreli kapı ise mutlak kapıdan sağ kalan blokların ortalamasından hesaplanır ve −10 LU kaydırılır. Göreli kapının kapılanmamış ortalamadan değil, sağ kalan bloklardan hesaplandığı ayrıntısı, uygulamaların yeterince sık yanlış yaptığı bir noktadır. Yükseklik Aralığı (LRA, EBU Tech 3342) ise −20 LU göreli kapı kullanır; LRA için −10 LU kullanmak yaygın bir uygulama hatasıdır.

Hangi baskı yürürlükte. BS.1770'in altı baskısı vardır: -0 (2006), -1 (2007), -2 (2011), -3 (2012), -4 (2015) ve -5 (Kasım 2023). Yürürlükteki baskı BS.1770-5'tir ve BS.1770-4'ün (Ekim 2015) yerini almıştır — BS.1770-4, sahadaki ölçerlerin çoğunun hâlâ panelinde yazdığı baskı olsa da artık geçerli baskı değildir. Güncel baskıyı adıyla anın: -5.

Kanal ağırlıkları ve kapsam. Çekirdek algoritmada kanal ağırlığı L, R ve C için 1,0 (0 dB); Ls ve Rs için 1,41'dir (≈ +1,5 dB); LFE ölçüme girmez. Temel algoritmanın kapsamı "from one to five channels" olarak tanımlanmıştır. BS.1770-5 bunun ötesine eklerinde geçer: BS.2051'in gelişmiş ses sistemlerini — serbest konumlandırılmış hoparlörler ve yükseklik kanalları — ve ölçülebilmesi için önce render edilmesi gereken nesne tabanlı sesi kapsar.

Sürükleyici ses yüksekliği dosyanın değil, bir render'ın özelliğidir. Hedef düzeni değiştirirseniz sayı değişir.

Fasıl kaydımızda bu somut olarak şu demektir: aynı BW64 dosyasından System J'ye ve System B'ye yapılan iki render'ın bütünleşik LUFS değerleri aynı çıkmaz — kubbeli salonun yükseklik katmanı 5.1'e indiğinde enerji yeniden dağılır. Dolayısıyla bir sayı yazacaksanız üç şeyi birlikte yazın: hangi düzen, hangi renderer, hangi BS.1770 baskısı.

Müzik için yayımlanmış olan. Kanal tabanlı stereo müzik için Spotify bütünleşik hedefini −14 LUFS, gerçek tepe tavanını −1 dBTP olarak yayımlar; master −14 LUFS'ten yüksekse tavan −2 dBTP'ye iner. Spotify sessiz master'lar için de pozitif kazanç uyguladığını söyler, ama aynı sayfada koşulu da verir: "We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality." AES TD1008 müzik için −16 LUFS önerir; belgedeki −18 LUFS değeri konuşma ağırlıklı içeriğe (haber, söyleşi, drama) aittir ve −18'i müzik hedefi diye aktarmak yaygın ve ciddi bir hatadır. EBU R 128'in −23 LUFS'i ise yayıncılık pratiğidir, müzik akışı spesifikasyonu değildir. Ölçer davranışları EBU Tech 3341'de tanımlıdır: anlık (momentary) 400 ms, kısa dönem (short-term) 3 s.

Yayımlanmamış olan. Hiçbir müzik akış servisi sürükleyici teslimat için bütünleşik bir ses yüksekliği hedefi yayımlamamaktadır. Forumlarda ve üretici eğitim materyallerinde sayılar bolca dolaşır; bazıları makul, bazıları muhtemelen doğrudur. Ama hiçbiri yayımlanmış bir spesifikasyon değildir ve bu belge onları spesifikasyonmuş gibi tekrarlamayacaktır. Apple Music, YouTube Music, Amazon Music, TIDAL ve Deezer stereo için de bir normalizasyon hedefi yayımlamaz; bu servisler için sık alıntılanan rakamlar "yaygın olarak bildirilen, ancak servis tarafından yayımlanmamış" değerlerdir ve üzerinden bir kazanç farkı hesaplanamaz.

Tescilli sistemler üzerine. Dolby Atmos, Dolby Laboratories'in tescilli ve lisanslı teknolojisidir; Sony 360 Reality Audio ise MPEG-H üzerine kurulu tescilli bir sistemdir. Teslimat gereklilikleri sahipleri tarafından belirlenir ve ITU ya da EBU takvimine bakmadan değişir. Bu belgedeki hiçbir ifade bu şirketlerin gereksinimlerinin beyanı değildir; hiçbir bağlantı, sertifikasyon veya onay iddia edilmemektedir. Bir lisans veren bir gereklilik yayımlıyorsa, onun kendi güncel dokümantasyonunu okuyun ve ona atıf yapın.

8. Türkçe karakterler, kimlik alanları ve UTF-8

Bu, Türkçe konuşan bir stüdyo için ADM'in az bilinen ama en somut tuzağıdır ve iki ayrı katmanda yaşar.

axml UTF-8'dir; orada Türkçe serbesttir. audioObject ve audioContent öğelerinin audioObjectName, audioContentName gibi name nitelikleri metin alanlarıdır ve Kanun (sağ), Ney — nısfiye, Hanende sırası, Kudüm gibi değerler tamamen geçerlidir. Buradaki tek şart, XML'in gerçekten UTF-8 yazılması ve bildiriminin buna uymasıdır. Latin-5 (ISO-8859-9) artığı bir yazıcı, ş ve ğ karakterlerini bozar ve XML ayrıştırıcı ya hata verir ya da yerine değiştirme karakteri koyar.

chna'daki kimlik alanları ASCII'dir; orada Türkçe felakettir. UID, trackRef ve packRef alanları sabit bayt genişliğine sahiptir: 12, 14 ve 11 bayt. UTF-8'de ş iki bayt, İ iki bayttır. Bir aracın kimlik üretirken enstrüman adını kimliğe karıştırması durumunda — ki bazı üretici içi araçlarda görülür — 12 karakterlik bir dize 13 veya 14 bayt tutar, kayıt 40 baytlık ızgaradan taşar ve o noktadan sonraki bütün chna kayıtları okunamaz hale gelir. Kimlikler daima ATU_, AT_, AP_ önekli, saf ASCII onaltılık değerlerdir. Türkçe adlar yalnızca XML'in name alanlarında yaşar.

Buna bağlı üçüncü bir tuzak, dosya ve klasör adlarındaki noktasız ı / noktalı i meselesidir. Bir teslimat setinde Fasil_Ney.wav ile Fasıl_Ney.wav iki farklı dosyadır; yerel ayara duyarsız bir toLowerCase() çağrısından geçmiş bir manifest, FASIL kelimesini fasil yerine fası̇l (U+0069 + U+0307) yapabilir ve sağlama toplamı (checksum) manifesti dosyayı bulamaz. Teslimat manifestlerinde dosya adlarını ASCII tutmak, meta verinin kendisinde Türkçeyi tam kullanmak en güvenli ayrımdır.

9. Türkiye'deki stüdyo gerçeği: bu belge size hoparlör satmıyor

Dürüst olalım. Türkiye'de sürükleyici monitörlemesi olan stüdyo sayısı azdır. Kalibre edilmiş 7.1.4 veya daha büyük bir oda, çoğu müzik stüdyosu için ne bütçe ne de mekân olarak gerçekçi değildir; sektörde bulunan çok kanallı odaların ağırlığı da müzikte değil, dizi ve film post-prodüksiyonundadır ve orada da yaygın olan 5.1'dir. Bu belgenin amacı bunu bir eksiklik olarak sunmak değildir.

Amaç şudur: doğru dosyayı teslim etmek ve teslim ettiğiniz dosyayı doğrulamak, sürükleyici bir oda kurmaktan bağımsız işlerdir. Türkiye'deki çoğu ekip için değerin tamamı burada yatar.

Bunun pratik anlamı:

1. Kayıt kararı ile monitör kararı ayrıdır. Kubbeli bir salonda 12 kanallı bir ambiyans dizisi kurup, yakın mikrofonları ayrı tutup, nesne tabanlı bir master için gereken ham malzemeyi doğru toplayabilirsiniz. Bu malzeme, sürükleyici odası olan bir tesise gittiğinizde hâlâ değerlidir; toplanmadıysa geri dönüşü yoktur.
2. Binaural render, monitör değil ama kontrol noktasıdır. BS.2127 uyumlu bir renderer'la (örneğin açık kaynaklı EAR) yapılmış bir binaural render, kulaklıkta nesnelerin doğru yönde olup olmadığını, bir sazın yanlış tarafta oturup oturmadığını, yükseklik katmanının boş kalıp kalmadığını duymanızı sağlar. Bu, mikse karar vermek için yeterli değildir; korkunç bir hatanın teslim edilmesini önlemek için fazlasıyla yeterlidir.
3. Arızaların çoğu zaten duyulamaz. Bu belgenin baştan beri anlattığı hataların — boşta referans, uyuşmayan kanal sayısı, geriye akan blok zamanı, basılmamış bed kanalı — hiçbiri hoparlör sayısıyla yakalanmaz. Bunlar bir ayrıştırıcının saniyenin altında yakaladığı şeylerdir. Yirmi bin liralık bir hoparlör bunları bulmaz; kırk satırlık bir betik bulur.
4. Ölçümü render'a bağlayın. Odanız yoksa bile, bir BS.2127 render'ını BS.1770-5 uyumlu bir ölçerden geçirip sonucu düzen adıyla birlikte teslim notuna yazabilirsiniz. Bu, sayının doğrulanabilir olması için gereken tek şeydir.

mazufa.com üzerinde, kapsayıcıyı ve meta veriyi tamamen kendi cihazınızda ayrıştıran, hiçbir şey yüklemeyen ücretsiz bir tarayıcı tabanlı BW64/ADM inceleyicisi var; sözleşme gereği binadan çıkamayan malzemede de kullanılabilir olması bundandır.

10. Sık görülen QC arızaları ve her birinin tespiti

10.1. fmt ile chna arasında kanal sayısı uyuşmazlığı

fmt.nChannels 26 diyor; chna.numTracks 24 diyor. Dosya daha ilk iki chunk'ta kendi içinde tutarsızdır. Genellikle meta veri yazıldıktan sonra parça sayısını değiştiren bir bounce'tan ya da chna'yı yeniden yazmadan parça düşüren bir araçtan kaynaklanır.

Tespit: iki chunk'ı ayrıştırıp tam sayıları karşılaştırın. Bütün hattaki en ucuz denetim budur ve arızaların şaşırtıcı bir oranını yakalar. Ayrıca chna'daki her trackIndex'in 1 … fmt.nChannels aralığında olduğunu doğrulayın.

10.2. Öksüz track UID'leri

chna'da var olup hiçbir audioObject'in referans vermediği bir UID; ya da XML'de chna karşılığı olmayan bir audioTrackUIDRef. Birincisi hiçbir şeyin render etmeyeceği ses demektir; ikincisi meta verinin var olmayan bir parçayı beklemesi demektir.

Tespit: chna'dan gelen UID kümesi ile axml'den gelen kümenin simetrik farkını alın; boş olmalıdır. EBU Tech 3392 niyeti açıkça yazar: "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

10.3. Eksik veya monoton olmayan blok zamanlaması

BS.2076 nettir: "When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." EBU Tech 3392 bunu bir bitişiklik kuralına sıkıştırır — "rtime + duration of an audioBlockFormat should match the rtime of the following block" — nesnenin ilk bloğu 00:00:00.00000'da başlar, hiçbir blok bir örnekten kısa olamaz ve süreler toplamı üst audioObject'in süresine eşit olmalıdır.

Tespit: her audioChannelFormat için blokları belge sırasında yürüyün ve rtime[n] + duration[n] == rtime[n+1] olduğunu doğrulayın. Arızalar üç şekle toplanır: boşluklar (renderer davranışı tanımsızdır — kimi son konumu tutar, kimi susturur), örtüşmeler (bloklar birbiriyle çekişir) ve kronolojik sıradan çıkmış bloklar (program ortasında geriye zıplayan otomasyon). Uzun yankılı bir kubbeli salon kaydında en sık görüleni birincisidir.

10.4. Yanlış örnekleme hızı veya bit derinliği

audioTrackUID, sampleRate ve bitDepth nitelikleri taşıyabilir. Bunlar fmt ile çeliştiğinde aynı öz hakkında iki iddianız olur. EBU Tech 3392'nin tutumu bunların "Should be ignored if available from the audio essence" olduğudur — ama her renderer bu rehbere uymaz ve bir yerde 48 000, başka bir yerde 96 000 yazan bir dosya farklı araçlarda farklı yorumlanır. Ayrıca hızın teslim şartnamesindeki hız olduğunu doğrulayın: ADM yazıldıktan sonra uygulanan bir örnekleme hızı dönüşümü, örnek cinsinden ifade edilmiş her rtime ve duration değerini geçersiz kılar.

Tespit: fmt 'i XML'deki her sampleRate/bitDepth niteliğiyle karşılaştırın; nominal olarak hoş görülebilir olsa bile her uyuşmazlığı işaretleyin.

10.5. Stereo veya binaural conform'un eksikliği ya da kayması

Sürükleyici teslimatların çoğu, master'ın yanında bir stereo (çoğu zaman da binaural) conform ister. Tekrarlayan arıza yokluk değil — yokluk zaten görülür — kaymadır: conform daha eski bir versiyondan render edilmiştir, birkaç kare öndedir, ya da başlangıç zaman kodu farklıdır. Sürükleyici ebeveynine göre 40 ms erken olan bir stereo dosya, "dosya var mı" denetimini geçer ve senkron dinlemede düşer.

Tespit: süreleri örnek örnek karşılaştırın, bext'ten başlangıç zaman kodunu karşılaştırın, conform'u master'ın null render'ıyla çapraz ilişkilendirin. Güncel master'dan bayt olarak türetilemeyen her conform'u şüpheli sayın ve yeniden denetlemek yerine yeniden render edin.

10.6. XML'de var olan, dosyada olmayan bir bed

XML 7.1.4 bir DirectSpeakers pack'i — on iki kanal — beyan ediyor, ama diske yalnızca 5.1 alt kümesi basılmış; ya da yükseklik kanalları bounce sırasında susturulmuş ve dijital siyah olarak yazılmış. Referans grafiği sağlamdır; ses değildir. Kubbeli salon kayıtlarında bu tam olarak felakettir, çünkü belgenin bütün gerekçesi olan yankı örtüsü yükseklik katmanındadır.

Tespit: yapısal denetimler bunu yakalayamaz. Öz analizi gerekir: bir DirectSpeakers pack'inin talep ettiği her kanal için, parçada sinyal olup olmadığını ölçün. Beyan edilmiş bir bed kanalındaki dijital siyah otomatik olarak hata değildir — meşru bir miks üst-arka bir kanalı boş bırakabilir — ama her zaman insan kararını hak eder.

Kapsayıcı kusursuz geçerli, XML kusursuz biçimli olabilir ve teslimat yine de yanlış olabilir; boş bir bed kanalının tek denetimi örneklere bakmaktır.

11. Teslim kontrol listesi

Sırayla ilerleyin. Önce yapısal denetimler — hızlıdırlar ve altlarındaki her şeyi geçersiz kılarlar.

Kapsayıcı

1. İlk dört bayt BW64 mi? RIFF ise dosya düz bir WAV'dır ve 4 GB'ı aşamaz.
2. ds64 imzadan sonraki ilk chunk mu, ve 64-bit boyutları diskteki gerçek dosya ve data boyutlarıyla eşleşiyor mu?
3. 4 GB'ı aşan data dışı her chunk'ın ds64 tablosunda bir ChunkSize64 kaydı var mı?
4. axml'i açıkça arayın — data'dan sonra dahil. Kısmi taramadan "ADM yok" sonucunu çıkarmayın.

Öz (essence)

1. fmt örnekleme hızı ve bit derinliği şartnameye birebir uyuyor mu? ADM yazıldıktan sonra SRC yok.
2. fmt.nChannels = chna.numTracks.
3. chna'daki her trackIndex aralıkta ve 1 tabanlı.

chna bütünlüğü

1. Her kayıt tam 40 bayt, sabit genişlikli alanlar doğru doldurulmuş, hiçbir kimlikte ASCII dışı bayt yok.
2. 0x1000 ve üstündeki her packRef, axml içinde bulunan bir özel tanıma çözülüyor.
3. Tekrarlanan trackIndex değerleri kasıtlı mı (taksimden heyete geçen bir parça gibi), yoksa çoğaltma hatası mı?

ADM grafiği

1. audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef ve audioTrackUIDRef'lerin hepsi çözülüyor. Sıfır boşta kenar.
2. Her iki yönde de öksüz audioTrackUID yok.
3. Döngüsel veya kendine referans veren öğe yok.
4. Her audioChannelFormat'ın typeLabel'ı üst audioPackFormat'ıyla uyumlu.

Zamanlama

1. Çok bloklu kanal biçimlerinde her blokta hem rtime hem duration var.
2. Bloklar bitişik ve monoton; süreler toplamı üst audioObject süresine eşit.
3. Nesneler 00:00:00.00000'da başlıyor.
4. Uzun yankılı mekân kayıtlarında kuyruk bed'de sürüyor; nesne süreleri kuyruğu kesmiyor.

İçerik

1. Beyan edilmiş bed'in her kanalında olması gereken şey var; dijital siyahı soruşturun.
2. Nesne sayısı ve bed yapılandırması şartnameye uyuyor.
3. bext başlangıç zaman kodu doğru ve setteki bütün teslimatlarda tutarlı.

Render ve conform'lar

1. Stereo ve binaural conform'lar güncel master'dan yeniden render edildi, devralınmadı.
2. Süreler ve başlangıç zaman kodları master'la örnek örnek eşleşiyor.
3. Ses yüksekliği, adı konmuş bir düzene adı konmuş bir renderer'la yapılmış adı konmuş bir render üzerinde ölçüldü ve üçü de teslim notuna yazıldı; kullanılan BS.1770 baskısı -5 olarak belirtildi.

Tekrarlanabilirlik

1. Her teslimatın sağlama toplamını alın ve manifesti saklayın; dosya adlarını ASCII tutun.
2. Oturumu ve ADM XML'ini BW64'ten ayrı arşivleyin. Diff alabildiğiniz bir XML, sonradan yalnızca yeniden ayrıştırabildiğiniz bir binary'den daha değerlidir.

Sürükleyici bir teslimat kulağa doğru geldiğinde bitmez; onu hiç duymamış bir makine referanslarının çözüldüğünü kanıtladığında biter.

12. Kapanış

BW64 ve ADM açık, yayımlanmış, serbestçe okunabilen standartlardır. Sektörün bu köşesinde bu alışılmadık bir durumdur ve kullanmaya değer: BS.2088'i ve BS.2076'yı kendiniz okuyabilir, kırk satır kodla bir chna chunk'ını ayrıştırabilir ve bir üreticinin dışa aktarıcısının iddia ettiğini değil, gerçekte yazdığını doğrulayabilirsiniz. Sürükleyici ses, gereksiz reddedilmelerin en yoğun olduğu alandır ve bunların neredeyse tamamı, bir doğrulayıcının saniyenin altında yakaladığı referans bütünlüğü hatalarıdır.

Bir fasıl heyetinin oturma düzeni yüzyıllardır sabittir. Onu doğru kaydeden dosya biçimi de artık var; iş, dosyanın söylediği ile diskte olanın aynı şey olduğundan emin olmaya kaldı.

Mazufa'da dağıtım ücretsizdir — yükleme ücreti, abonelik ya da yayın başına ücret yoktur; tek kesinti tahsil edilen telif gelirlerinin %5'idir ve her eksiksiz başvuru insan tarafından incelenir.

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.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
• ITU-R BS.2127 sayfası — https://www.itu.int/rec/R-REC-BS.2127

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/docs/tech/tech3388.pdf ve 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 (ölçerler), EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch
• EBU ADM Guidelines — CHNA chunk — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 ve 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
• EBU ADM Renderer (EAR) dokümantasyonu, BW64 G/Ç — https://ear.readthedocs.io/en/latest/BW64.html
• libbw64 referans uygulaması — https://github.com/ebu/libbw64
• libadm referans uygulaması — 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/

Servis dokümantasyonu

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

Karakter kodlaması

• Unicode Character Database, SpecialCasing.txt — Türkçe harf dönüşümü kuralları — https://www.unicode.org/Public/UNIDATA/SpecialCasing.txt

Son gözden geçirme: Eylül 2026. Standartlar revize edilir; bir madde numarasını alıntılamadan önce yukarıdaki ITU ve EBU sayfalarından güncel baskıyı daima kontrol edin.