چرا یک مستر ایمرسیو از ویرایشگر موج سربلند بیرون می‌آید و در QC رد می‌شود

یک تحویلی ایمرسیو می‌تواند در ویرایشگر موج باز شود، دوازده یا شانزده ترک سالم نشان دهد، معقول پخش شود، و باز هم رد شود. دلیلش ساختاری است: در یک فایل BW64، صدا و متادیتا دو چیز جدا هستند که باید دقیقاً با هم بخوانند، و هیچ چیز در این فرمت آن‌ها را به این کار وادار نمی‌کند. رندرر ارجاع‌ها را حل می‌کند. ویرایشگر نمونه‌ها را رسم می‌کند. دو کار متفاوت — و به همین دلیل است که QC روی ADM وارسی یکپارچگی ارجاع‌هاست، نه گوش دادن. اینجا می‌بینید دو استاندارد چه می‌گویند، ارجاع‌ها کجا می‌شکنند، و کدام وارسی کدام خطا را می‌گیرد.

سه گونه صدا، و چرا این تمایز همه چیز را تعیین می‌کند

هر مشکل تحویل ایمرسیو با سردرگمی دربارهٔ اینکه یک ترک کدام‌یک از این سه چیز است آغاز می‌شود.

صدای کانال‌محور هر ترک را به موقعیت بلندگویی ثابت نسبت می‌دهد. استریو کانال‌محور است، 5.1 هم همین‌طور، بستر 7.1.4 هم. موقعیت در هویت کانال پخته شده است: ترک 3 بلندگوی مرکزی است، و روی هر سامانه‌ای که پخشش کند بلندگوی مرکزی است. ‏ITU-R BS.2051 این را برای سامانه‌های صوتی پیشرفته صورت‌بندی می‌کند و چیدمان‌ها را به صورت شمار لایه‌های Upper + Middle + Bottom توصیف می‌کند — System A ‏0+2+0 است (استریو)، System B ‏0+5+0 (5.1)، System D ‏4+5+0، System J ‏4+7+0، System H ‏9+10+3، همان پیکربندی 22.2. در ADM این typeDefinition با نام DirectSpeakers است، با typeLabel ‏0001.

صدای شیءمحور یک سیگنال مونو (یا پک چندکاناله) را به‌همراه متادیتای موقعیتی حمل می‌کند که در طول زمان تغییر می‌کند. رندرر بر پایهٔ چیدمان موجود در اتاق تصمیم می‌گیرد کدام بلندگوهای واقعی آن را بازتولید کنند. هیچ چیز در ترک بلندگویی را پیش‌فرض نمی‌گیرد. این typeDefinition با نام Objects است، typeLabel ‏0003.

صدای صحنه‌محور، که در عمل همان آمبیسونیک مرتبهٔ بالاست، کل میدان صوتی را به صورت مؤلفه‌های هارمونیک کروی رمزگذاری می‌کند. هیچ مؤلفه‌ای به‌تنهایی متناظر یک جهت نیست؛ جهت از ترکیب خطی پدید می‌آید. این HOA است، typeLabel ‏0004. ‏ADM همچنین Matrix (0002) را برای سیگنال‌های ماتریسی مانند Mid-Side یا Lt/Rt و Binaural (0005) را تعریف می‌کند.

این تمایز رده‌بندی نیست. یک تحویلی کانال‌محور آن‌قدر خودتوصیف هست که به صورت یک WAV لخت هم دوام بیاورد — ترتیب کانال‌ها را درست بگذارید و پخش می‌شود. یک تحویلی شیءمحور یا صحنه‌محور بدون متادیتایش بی‌معناست: صدا انباشته‌ای از جریان‌های مونوی تفکیک‌نشده است، و ADM تنها چیزی است که خلافش را می‌گوید. همین عدم تقارن است که BW64 و ADM را به وجود آورده است.

‏BW64 به خاطر یک عدد 32 بیتی وجود دارد

‏WAV کلاسیک یک فایل RIFF است. ‏RIFF، از 1991، پیش از هر چانک یک فیلد اندازهٔ 32 بیتی می‌گذارد. سی‌ودو بیت 4,294,967,296 بایت — 4 GB — را آدرس‌دهی می‌کند، و این سقف سخت هم برای کل فایل است و هم برای چانک data درون آن.

برای استریو در 48 kHz / 24-bit نرخ داده 288,000 بایت بر ثانیه است، پس 4 GB حدود 4 ساعت و 8 دقیقه می‌شود. بی‌ربط. برای یک مستر شیءمحور 128 ترکی در 96 kHz / 24-bit نرخ 36,864,000 بایت بر ثانیه است، و 4 GB کمتر از دو دقیقه — 116.5 ثانیه.

مسترهای ایمرسیو به‌طور معمول از این حد می‌گذرند، و نویسندهٔ WAV که به آن برخورد کند یا فایلی بریده تولید می‌کند یا فایلی که اندازه‌های اعلامی‌اش بی‌صدا سرریز کرده‌اند. ‏EBU نخست با RF64 (‏EBU Tech 3306) به این پرداخت؛ ITU آن را به صورت توصیه‌نامهٔ ITU-R BS.2088 — یعنی BW64 — پیش برد.

ترفند سنتینل: ‏0xFFFFFFFF و یک چانک ds64

‏BS.2088 دربارهٔ این سازوکار صریح است. "The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file"، و فیلدهای اندازهٔ 32 بیتی اصلی به پرچم‌های گریز تبدیل می‌شوند: "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

تمام ترفند همین است، و ارزش دارد صریح گفته شود: ‏BW64 فیلدهای اندازهٔ RIFF را پهن‌تر نمی‌کند. آن‌ها را با 0xFFFFFFFF به عنوان سنتینل پر می‌کند و اندازه‌های واقعی 64 بیتی را در چانکی به نام ds64 می‌گذارد که باید نخستین چانک فایل باشد. پس یک فایل BW64 کوچک‌تر از 4 GB از هر جهت جز امضای چهارنویسه‌ای با یک خوانندهٔ WAV سازگاری بایتی دارد. بسیاری از ابزارها می‌پذیرندش؛ برخی لجوجانه نه.

چانک‌ها، و آن یکی که دقیقاً 40 بایت به‌ازای هر مدخل است

بر پایهٔ BS.2088 انتظار می‌رود یک فایل BW64 دست‌کم شامل ds64، fmt ، chna، axml (با bxml و sxml به عنوان حامل‌های جایگزین متادیتا) و دادهٔ موج باشد.

ds64 باید نخستین چانک پس از امضا باشد، چون خواننده پیش از آنکه بتواند چیز دیگری را بپیماید باید اندازه‌های واقعی را بداند. نیمه‌های 32 بیتی پایین/بالا را برای اندازهٔ کل فایل و اندازهٔ data حمل می‌کند، به‌علاوهٔ جدولی از مدخل‌های ChunkSize64 برای هر چانک بزرگ دیگر — یک چانک axml که هزاران شیء را با اتوماسیون نمونه‌دقیق توصیف می‌کند خودش می‌تواند به 4 GB نزدیک شود یا از آن بگذرد.

fmt همان چانک استاندارد فرمت WAVE است — قالب نمونه، نرخ نمونه، شمار کانال، بیت بر نمونه، بلوک‌ترازی. تنها بیان معتبر دربارهٔ اینکه چند کانال درهم‌بافته در data هست همین است. هر چیز پایین‌دستی متادیتا دربارهٔ آن کانال‌هاست، و متادیتا می‌تواند دروغ بگوید.

chna پل میان ترک‌های فیزیکی و ADM است. پس از ckID، ckSize، یک numTracks ‏2 بایتی و یک numUIDs ‏2 بایتی، آرایه‌ای مسطح از مدخل‌های audioID با پهنای ثابت را نگه می‌دارد، هر کدام دقیقاً 40 بایت:

2 + 12 + 14 + 11 + 1 = 40. این پهناها توصیه نیستند: ‏ASCII با پهنای ثابت‌اند، و نویسنده‌ای که UIDی 13 نویسه‌ای بیرون بدهد جدولی خراب ساخته است، نه جدولی کمی غیرمعمول.

قرارداد شناسه‌ها هم مهم است. مقادیر 0x0FFF و پایین‌تر به تعریف‌های مشترک ADM اشاره می‌کنند — یعنی قالب‌های کانال و پک استاندارد و از پیش تعریف‌شده — در حالی که 0x1000 و بالاتر نشان‌دهندهٔ تعریف‌های سفارشی‌اند که باید در axml حاضر باشند. ‏AP_00010003 بر پایهٔ تعریف مشترک همان 5.1 است و به XML نیازی ندارد؛ AP_00031001 یک پک شیء سفارشی است و XML می‌خواهد، وگرنه معلق می‌ماند.

‏numUIDs می‌تواند به‌درستی از numTracks بیشتر باشد: راهنمای EBU یادآور می‌شود که آنجا که "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"، پس یک trackIndex می‌تواند در چند مدخل ظاهر شود. ابزارهای QC که یک UID به‌ازای هر ترک را فرض می‌گیرند فایل‌های درست را خراب علامت می‌زنند.

axml یک سند XML با کدگذاری UTF-8 است که درخت <audioFormatExtended> را در بر دارد. آن همان ADM است، و عملاً همهٔ خطاهای جالب همان‌جا زندگی می‌کنند. data همان PCM درهم‌بافتهٔ ساده است؛ هیچ چیز در آن دربارهٔ شیءها نمی‌داند.

ترتیب: ds64 همیشه نخست؛ fmt پیش از data. اما axml به‌درستی می‌تواند پس از data بنشیند، و اغلب چنین است، چون — چنان‌که BS.2088 اشاره می‌کند — هنگام ضبط "the XML metadata will likely be of an unknown length." فایلی که axml در دُمش باشد بدساخت نیست، اما خواننده‌ای که فقط مگابایت نخست را اسکن کند گزارش می‌دهد که اصلاً ADM ندارد. سهم شگفت‌آوری از گزارش‌های «فایل من متادیتا ندارد» از همین‌جا می‌آید.

‏ADM یک گراف است، و خطاها یال‌های شکسته‌اند

سلسله‌مراتب ITU-R BS.2076 چنین پیش می‌رود: audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat، با audioTrackUID به عنوان برگ و تنها عنصری که متناظر یک ترک فیزیکی است.

این یک گراف از ارجاع‌هاست، نه یک سند تودرتو، و هر خطای جدی تحویل یالی شکسته در آن است. آنچه ارجاع معلق را خطرناک می‌کند این است که هنگام شکستن یکی، رفتار واحدی وجود ندارد. رندرری که audioPackFormatIDRef را حل می‌کند و پکی را می‌بیند که در XML غایب است، ممکن است تجزیه را رها کند و فایل را رد کند؛ ممکن است آن شیء را رد کند و باقی را رندر کند و میکسی بسازد که بی‌سر و صدا یک استم کم دارد؛ یا ممکن است به تعریف‌های مشترک پس‌روی کند، شناسه‌ای در گسترهٔ سفارشی 0x1000 به بالا بیابد که تطبیقی ندارد، و به جایش سکوت بگذارد. هر سه نتیجه یعنی «فایل باز شد». فقط یکی با گوش دادن گرفته می‌شود، و آن هم تنها اگر بدانید چه چیزی باید آنجا می‌بود.

چهار خطایی که بیشتر مردودی‌ها را می‌سازند

شمار ترک fmt که با chna نمی‌خواند. ‏fmt .nChannels می‌گوید 16؛ chna.numTracks می‌گوید 14. فایل از همان دو چانک نخست درونی ناسازگار است — معمولاً باونسی که پس از تألیف متادیتا شمار ترک را عوض کرده، یا ابزاری که ترک‌ها را انداخته بی‌آنکه chna را بازنویسی کند. تشخیصش یعنی تجزیهٔ دو عدد صحیح و مقایسه‌شان: ارزان‌ترین وارسی خط، و نسبت حیرت‌آوری از خطاها را می‌گیرد. هم‌زمان وارسی کنید که هر trackIndex در بازهٔ 1 … fmt .nChannels باشد.

یک audioTrackUID که هیچ شیئی به آن ارجاع نمی‌دهد. ‏UIDی در chna که هیچ audioObject به آن ارجاع ندهد یعنی صدایی هست که چیزی رندرش نخواهد کرد؛ حالت آینه‌ای‌اش، یعنی audioTrackUIDRef در XML بدون مدخل متناظر در chna، یعنی متادیتا انتظار ترکی را دارد که نیست. مجموعهٔ UIDها را از chna و مجموعه را از axml بسازید و تفاضل متقارن بگیرید؛ باید تهی باشد. ‏EBU Tech 3392 قصد را مستقیم بیان می‌کند: "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

زمان‌بندی بلوک که رو به عقب می‌رود. ‏BS.2076 صریح است: "When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." ‏EBU Tech 3392 آن را تا حد پیوستگی سخت‌تر می‌کند — "rtime + duration of an audioBlockFormat should match the rtime of the following block" — با این شرط که نخستین بلوک هر شیء از 00:00:00.00000 آغاز شود، هیچ بلوکی کوتاه‌تر از یک نمونه نباشد، و مجموع مدت‌ها با audioObject والد بخواند. بلوک‌ها را به ترتیب سند بپیمایید و ادعا کنید rtime[n] + duration[n] == rtime[n+1]. خطاها سه شکل دارند: شکاف، که رفتار رندرر در آن تعریف‌نشده است و برخی آخرین موقعیت را نگه می‌دارند و برخی بی‌صدا می‌کنند؛ هم‌پوشانی، که بلوک‌ها در آن با هم می‌جنگند؛ و بلوک‌های خارج از ترتیب زمانی، که یعنی اتوماسیون وسط برنامه به عقب پریده است.

بستری که در XML توصیف شده اما هرگز روی دیسک چاپ نشده است. ‏XML یک پک DirectSpeakers با چیدمان 7.1.4 — دوازده کانال — اعلام می‌کند، اما فقط زیرمجموعهٔ 5.1 چاپ شده، یا کانال‌های ارتفاع هنگام باونس بی‌صدا بوده‌اند و به صورت سیاهی دیجیتال چاپ شده‌اند. گراف ارجاع‌ها سالم است؛ صدا نیست. وارسی‌های ساختاری نمی‌توانند این را بگیرند: به تحلیل ماده نیاز دارید، یعنی سنجش اینکه آیا هر کانالی که یک پک DirectSpeakers ادعا می‌کند اصلاً سیگنالی دارد یا نه. سیاهی دیجیتال روی کانالی از بستر اعلام‌شده خودبه‌خود خطا نیست — میکسی مشروع می‌تواند یک کانال بالا-عقب را خالی بگذارد — اما همیشه ارزش یک تصمیم انسانی را دارد.

دربارهٔ بلندی ایمرسیو چه چیزی منتشر شده و چه چیزی نشده

یک عدد از انتقال از استریو جان سالم به در نمی‌برد، و ارزش دارد گفته شود چرا.

‏BS.1770-5 (نوامبر 2023) ویرایش جاری است؛ BS.1770-4 منسوخ شده، هرچند بیشتر متر‌های مستقر هنوز به آن استناد می‌کنند. الگوریتم هسته‌اش به L، R و C وزن 1.0 و به Ls و Rs وزن 1.41 (حدود +1.5 dB) می‌دهد، LFE را کنار می‌گذارد، و دامنه‌اش "from one to five channels" است. ‏BS.1770-5 در پیوست‌هایش از این فراتر می‌رود و سامانه‌های صوتی پیشرفتهٔ BS.2051 و صدای شیءمحور را پوشش می‌دهد — که پیش از اندازه‌گیری باید رندر شوند. پس بلندی ایمرسیو ویژگی فایل نیست بلکه ویژگی یک رندر است، و عوض کردن چیدمان هدف عدد را عوض می‌کند. یک رندر منطبق با BS.2127 روی یک چیدمان نام‌بردهٔ BS.2051 را با متر BS.1770-5 اندازه بگیرید و هر سه را در یادداشت‌های تحویلتان ثبت کنید؛ BS.2127 رندرر مرجع ADM را تعریف می‌کند، و همزاد متن‌باز آن، یعنی EBU ADM Renderer (‏EBU Tech 3388)، راه عملی رسیدن به رقمی بازتولیدپذیر است.

هیچ سرویس پخش موسیقی هدف بلندی یکپارچه‌ای برای تحویل ایمرسیو منتشر نمی‌کند. ارقامی در انجمن‌ها و مواد آموزشی فروشندگان دست‌به‌دست می‌شود؛ هیچ‌کدام مشخصه‌ای منتشرشده نیست و این مقاله هیچ‌کدام را چنان که گویی هست تکرار نمی‌کند. آنچه منتشر شده مربوط به استریوی کانال‌محور است — هدف یکپارچهٔ −14 LUFS از Spotify با سقف پیک واقعی −1 dBTP که برای بالاتر از −14 LUFS به −2 dBTP سخت‌تر می‌شود، و −16 LUFS از AES TD1008 برای موسیقی (رقم −18 LUFS آن به محتوای گفتارمحور مربوط است، و اعلام −18 به عنوان هدف موسیقی خطایی رایج و جدی است).

‏Dolby Atmos فناوری اختصاصی و لیسانس‌دار Dolby Laboratories است، و Sony 360 Reality Audio سامانه‌ای اختصاصی بر پایهٔ MPEG-H. الزاماتشان را مالکانشان تعیین می‌کنند، بدون توجه به جدول زمانی ITU یا EBU تغییر می‌کند، و اینجا بیان نشده است؛ هیچ وابستگی یا تأییدی ادعا نمی‌شود. مستندات جاری خود صاحب لیسانس را بخوانید.

پیش از فرستادن چه چیزهایی را وارسی کنید

نخست وارسی‌های ساختاری؛ سریع‌اند و هر چیز پایین‌دستی را باطل می‌کنند.

• چهار بایت نخست BW64 باشند. اگر RIFF بخوانند، فایل یک WAV ساده است و نمی‌تواند از 4 GB بگذرد.
• ‏ds64 نخستین چانک پس از امضا باشد، اندازه‌های 64 بیتی‌اش با اندازهٔ فایل و اندازهٔ data روی دیسک بخوانند، و هر چانک بزرگِ غیر-data مدخل ChunkSize64 خودش را در جدول داشته باشد.
• ‏axml را صریحاً بیابید، از جمله پس از data — هرگز از یک اسکن ناقص نتیجه نگیرید که «ADM ندارد».
• نرخ نمونه و عمق بیت fmt دقیقاً با مشخصهٔ تحویل بخوانند. پس از تألیف ADM هیچ تبدیل نرخ نمونه‌ای انجام نشود — هر rtime و duration بیان‌شده بر حسب نمونه را باطل می‌کند.
• ‏fmt .nChannels برابر chna.numTracks باشد؛ هر trackIndex در بازه و آغازشده از 1 باشد.
• هر مدخل chna دقیقاً 40 بایت با فیلدهای پهنا-ثابتِ درست لایی‌خورده باشد، و هر packRef در 0x1000 یا بالاتر به تعریفی سفارشی حاضر در axml حل شود.
• هر audioContentIDRef، audioObjectIDRef، audioPackFormatIDRef، audioChannelFormatIDRef و audioTrackUIDRef حل شود. صفر یال معلق، در هر دو جهت، بدون ارجاع دوری.
• قالب‌های کانال چندبلوکی هم rtime و هم duration را روی هر بلوک داشته باشند؛ بلوک‌ها پیوسته و یکنوا باشند؛ شیءها از 00:00:00.00000 آغاز شوند.
• هر کانال از بستر اعلام‌شده آنچه را باید داشته باشد داشته باشد. سیاهی دیجیتال را بررسی کنید.
• تایم‌کد آغاز bext در سراسر مجموعه سازگار باشد، و کانفورم‌های استریو و باینورال از مستر جاری بازرندر شده باشند. کانفورمی که 40 ms زودتر از والد ایمرسیوش باشد از وارسی حضور فایل سربلند بیرون می‌آید و در گوش دادن هم‌زمان رد می‌شود.
• از هر تحویلی چک‌سام بگیرید، فهرست را نگه دارید، و XML مربوط به ADM را جدا از BW64 بایگانی کنید — ‏XMLی که بتوانید تفاوتش را بگیرید بعدها بیش از باینری‌ای می‌ارزد که فقط می‌توانید دوباره تجزیه‌اش کنید.

‏BW64 و ADM استانداردهایی باز، منتشرشده و آزادانه خواندنی‌اند، و این ارزش استفاده دارد: می‌توانید BS.2088 و BS.2076 را خودتان بخوانید، یک چانک chna را با چهل خط کد تجزیه کنید، و وارسی کنید که خروجی‌گیر یک فروشنده واقعاً چه نوشته است نه آنچه پنجرهٔ گفت‌وگویش ادعا کرده. تقریباً همهٔ مردودی‌های غیرضروری ایمرسیو خطاهای یکپارچگی ارجاع‌اند که یک اعتبارسنج در کمتر از یک ثانیه می‌گیردشان.

بازرس رایگان BW64/ADM مازوفا در mazufa.com/immersive-master-check کانتینر و متادیتا را تماماً روی دستگاه خودتان تجزیه می‌کند و هیچ چیز بارگذاری نمی‌کند، و همین آن را روی موادی به کار می‌آورد که قراردادی نمی‌توانند از ساختمان بیرون بروند. خود مازوفا برای انتشار رایگان است، 0% کمیسیون برمی‌دارد، و دعوت‌محور است با بازبینی انسانی هر درخواست کامل.

منابع

‏ITU-R Recommendations

• 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 Technical documents

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (and supplements), 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 reference implementation — 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/

مستندات سرویس‌ها

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