تحویل صدای ایمرسیو با

BW64 و ADM: یک مرجع فنی برای مهندسان و نوازندگان ایرانی

از چیدمان چانک‌ها در فایل تا رندر روی چیدمان‌های بلندگویی استاندارد و اندازه‌گیری بلندی صدا — با نگاه به اینکه بیشتر استودیوهای ایران مانیتورینگ ایمرسیو ندارند و باید فایلی را تحویل بدهند که نمی‌توانند درست بشنوند.

پاسخ کوتاه

مدل تعریف صدا یا ADM — توصیهٔ ITU-R BS.2076 — یک استاندارد باز برای متادیتا است که می‌گوید هر ترک صوتی داخل یک فایل چیست: کانالِ یک بلندگوی ثابت، یک شیء متحرک، یا مؤلفه‌ای از یک میدان صوتی. این متادیتا به شکل XML داخل ظرفی به نام BW64 — توصیهٔ ITU-R BS.2088 — حمل می‌شود؛ ظرفی که همان RIFF/WAVE است با آدرس‌دهی ۶۴بیتی، تا سقف ۴ گیگابایتیِ WAV کلاسیک را بشکند. علت اصلیِ ردشدن فایل‌های ایمرسیو در کنترل کیفیت این است که صوت و متادیتا دو چیز جدا هستند و هیچ‌چیز در خودِ قالب فایل، آن دو را مجبور به تطابق نمی‌کند: تعداد کانال در fmt که با جدول chna نمی‌خواند، یک audioTrackUID که هیچ شیئی به آن ارجاع نمی‌دهد، بلوکی که زمانش رو به عقب می‌رود، یا بستری که در XML توصیف شده ولی هرگز روی دیسک نوشته نشده — هیچ‌کدام از این‌ها را با گوش نمی‌شنوید و همه‌شان کشنده‌اند. کنترل کیفیتِ ADM شنیدن نیست؛ بررسی یکپارچگیِ ارجاع‌هاست، و همین است که آن را برای استودیویی که مانیتورینگ ایمرسیو ندارد هم کاملاً شدنی می‌کند.

۱. سه نوع صدا — و اینکه چرا این تفکیک، قالب فایل را تعیین می‌کند

قبل از ظرف، مدل. هر مشکل تحویلِ ایمرسیو از یک ابهام شروع می‌شود: این ترک واقعاً کدام‌یک از سه چیز زیر است؟

صدای کانال‌محور

در صدای کانال‌محور، هر ترک به یک موقعیت ثابتِ بلندگو تخصیص داده می‌شود. استریو کانال‌محور است. ۵٫۱ هم همین‌طور، و بستر 7.1.4 هم. موقعیت، در خودِ هویت کانال پخته شده است: ترک سوم، بلندگوی مرکزی است و روی هر سیستمی که پخشش کند بلندگوی مرکزی می‌ماند.

توصیهٔ ITU-R BS.2051 همین را برای «سیستم‌های صوتی پیشرفته» رسمی می‌کند و چیدمان‌ها را به‌صورت شمارشِ لایه‌ایِ بالا + میانی + پایین تعریف می‌کند: System A یعنی ۰+۲+۰ (استریو)، System B یعنی ۰+۵+۰ (۵٫۱)، System D یعنی ۴+۵+۰، System J یعنی ۴+۷+۰، و System H یعنی ۹+۱۰+۳ که همان چیدمان ۲۲٫۲ است. در ADM، محتوای کانال‌محور با typeDefinition برابر DirectSpeakers و برچسبِ نوعِ 0001 مشخص می‌شود.

مثال ایرانیِ درست برای کانال‌محور: ارکستر ملی. وقتی یک ارکستر بزرگ ایرانی را ضبط می‌کنید — با ردیف‌های سازهای زهی، بخش بادی، سنتورها و قانون‌ها در جای همیشگی خود روی صحنه، و کوبه‌ای‌ها در پشت — شما با چند دهه نوازنده روبه‌رو نیستید که هرکدام یک «شیء» باشند. شما با یک صحنهٔ ثابت روبه‌رو هستید که چیدمانش بخشی از هویت صوتی اثر است. اینجا آرایهٔ میکروفون اصلی و میکروفون‌های ارتفاع، یک بستر کانال‌محور تولید می‌کنند که هر کانالش از پیش می‌داند به کدام بلندگو می‌رود. تلاش برای تبدیل هر پالت ویولن به یک شیء مستقل، نه دقت اضافه می‌کند و نه اطلاعات؛ فقط سی شیء می‌سازد که همگی در یک نقطه ایستاده‌اند و رندرر باید دوباره آن‌ها را روی همان بلندگوها جمع کند.

صدای شیءمحور

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

مثال ایرانیِ درست برای شیءمحور: یک گروه کوچک. تار، سه‌تار، کمانچه، نی، تنبک و آواز. شش نوازنده در یک اتاق، هرکدام در یک نقطهٔ مشخص و ثابت، هرکدام با یک میکروفون نزدیک. اینجا هر نوازنده به معنای دقیق کلمه یک شیء گسسته با موقعیت معیّن است. آواز کمی جلوتر و در مرکز؛ تار در سمت چپ و اندکی عقب‌تر؛ کمانچه روبه‌روی او؛ تنبک پشت و پایین‌تر از خط گوش. این‌ها موقعیت‌های تخیلیِ یک میکس نیستند، واقعیت فیزیکیِ آن اجرا هستند، و ADM دقیقاً برای ثبت همین ساخته شده است.

و نکته‌ای که در بحث‌های ایمرسیو کمتر گفته می‌شود: ضبط موسیقی کلاسیک ایرانی همیشه دربارهٔ صدای یک اتاق واقعی با نوازنده‌های واقعی در آن بوده است. یک اجرای گروهی، یک اتاق، یک زمان، بدون لایه‌گذاری. آن‌چه صدای این ضبط را می‌سازد فقط نت‌ها نیست؛ فاصلهٔ نوازنده‌ها از هم، بازتاب اتاق، و اینکه گوش شنونده در کجای آن جمع نشسته است. این دقیقاً همان چیزی است که صدای شیءمحور برای آن اختراع شده. در مقابل، یک تولید پاپِ چندلایه — که در آن هر ساز در روز دیگری، در اتاق دیگری، و اغلب داخل یک برنامهٔ نرم‌افزاری بدون هیچ اتاقی ضبط شده — فضایی برای ثبت‌کردن ندارد؛ فضایش را باید از صفر اختراع کرد. هر دو کار مشروع‌اند، اما فقط یکی از آن‌ها ثبتِ یک واقعیت است و دیگری ساختِ یک تخیل. اگر می‌خواهید بدانید ایمرسیو برای چه ساخته شده، به گروه شش‌نفره نگاه کنید، نه به سشن پاپ.

صدای صحنه‌محور

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

صدای کانال‌محور به فایل می‌گوید بلندگوها کجا هستند؛ صدای شیءمحور از حدس‌زدن سر باز می‌زند؛ و صدای صحنه‌محور به‌جای منابع، خودِ میدان را توصیف می‌کند.

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

۲. چرا BW64 وجود دارد — با حسابِ بایت

فایل WAV کلاسیک یک فایل RIFF است. قالب RIFF، از سال ۱۹۹۱، پیش از هر چانک یک فیلد اندازهٔ ۳۲بیتی می‌گذارد. سی‌ودو بیت، ۴٬۲۹۴٬۹۶۷٬۲۹۶ بایت — یعنی ۴ گیبی‌بایت — را آدرس‌دهی می‌کند و این سقفِ سخت، هم برای کل فایل و هم برای چانک data داخل آن اعمال می‌شود.

حساب کنیم، چون عدد اینجا همه‌چیز را روشن می‌کند. نرخ بایت خام برابر است با: نرخ نمونه‌برداری × تعداد کانال × تعداد بایت هر نمونه.

استریو، ۴۸ کیلوهرتز، ۲۴ بیت. هر نمونه ۳ بایت است، پس هر ثانیه: ۴۸۰۰۰ × ۲ × ۳ = ۲۸۸٬۰۰۰ بایت. سقف ۴ گیبی‌بایت تقسیم بر این عدد می‌شود ۱۴٬۹۱۳ ثانیه، یعنی حدود ۴ ساعت و ۸ دقیقه. برای یک آلبوم استریو، این سقف عملاً وجود ندارد.

**بستر 7.1.4 یعنی ۱۲ کانال، ۴۸ کیلوهرتز، ۲۴ بیت. هر ثانیه: ۴۸۰۰۰ × ۱۲ × ۳ = ۱٬۷۲۸٬۰۰۰ بایت. سقف تقسیم بر این می‌شود ۲٬۴۸۵ ثانیه، یعنی حدود ۴۱ دقیقه**. یک کنسرت کامل ارکستر ملی، در یک فایل پیوسته، از این سقف رد می‌شود.

۱۲۸ ترک شیءمحور، ۹۶ کیلوهرتز، ۲۴ بیت. هر ثانیه: ۹۶۰۰۰ × ۱۲۸ × ۳ = ۳۶٬۸۶۴٬۰۰۰ بایت، یعنی نزدیک ۳۵ مبی‌بایت در ثانیه. سقف ۴ گیبی‌بایت تقسیم بر این می‌شود ۱۱۶٫۵ ثانیه — کمتر از دو دقیقه. یک مستر شیءمحورِ بزرگ، سقف RIFF را حتی پیش از پایان اولین قطعه رد می‌کند.

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

اتحادیهٔ رادیو و تلویزیون اروپا این را نخست با RF64 حل کرد (سند EBU Tech 3306). سپس ITU همان کار را در قالب **توصیهٔ ITU-R BS.2088** با عنوان قالب فایل بلندفرم برای تبادل بین‌المللی مواد برنامه‌ای صوتی همراه با متادیتا — یعنی BW64 — پیش برد. متن BS.2088 دربارهٔ سازوکار صریح است:

"The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file"

و دربارهٔ فیلدهای اندازه:

"If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

کل ترفند همین است و ارزش دارد صریح گفته شود:

BW64 فیلدهای اندازهٔ RIFF را پهن‌تر نمی‌کند؛ آن‌ها را با 0xFFFFFFFF به‌عنوان یک نشانگر پر می‌کند و اندازهٔ ۶۴بیتیِ واقعی را در چانکی به نام ds64 می‌گذارد که باید نخستین چانک فایل باشد.

بهترین راه فهم BW64 این است که آن را نسل سوم یک تبار واحد ببینید: RIFF/WAVE ظرفِ چانکی را داد؛ Broadcast Wave یا BWF (سند EBU Tech 3285) چانک bext را افزود — پدیدآورنده، مرجع تایم‌کد، تاریخچهٔ کدینگ — و WAV را به یک قالب تبادل پخش تبدیل کرد؛ و BW64 همهٔ این‌ها را نگه داشت، آدرس‌دهی ۶۴بیتی افزود و چانک‌های حاملِ ADM را اضافه کرد. یک فایل BW64 زیر ۴ گیبی‌بایت، جز در چهار بایت امضای فایل، از هر نظر با یک خوانندهٔ WAV سازگار است؛ خیلی از ابزارها می‌پذیرندش و بعضی سرسختانه نمی‌پذیرند.

۳. چیدمان چانک‌ها، با جزئیات

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

چانک ds64 — جدول اندازه‌های ۶۴بیتی

باید نخستین چانک بعد از امضای BW64 باشد، چون خواننده پیش از پیمودن هر چیز دیگری باید اندازه‌های واقعی را بداند. فیلدهایش نیمه‌های ۳۲بیتیِ کمیت‌های ۶۴بیتی‌اند:

آن table[] از آنچه به‌نظر می‌رسد مهم‌تر است. یک چانک axml که هزاران شیء را با اتوماسیون دقیق در سطح نمونه توصیف می‌کند، خودش می‌تواند به ۴ گیبی‌بایت نزدیک یا از آن رد شود؛ این جدول تنها راهی است که چانکی غیر از data می‌تواند اندازهٔ ۶۴بیتی اعلام کند.

چانک fmt — توصیف ذاتِ صوت

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

چانک chna — جدول تخصیص کانال، و حساب چهل بایت

چانک chna پل میان ترک‌های فیزیکی و ADM است. سرآغازش این‌هاست:

و پس از آن یک آرایهٔ مسطح از ورودی‌های audioID با عرض ثابت. هر ورودی دقیقاً ۴۰ بایت است:

حساب را ببینید: ۲ + ۱۲ + ۱۴ + ۱۱ + ۱ = ۴۰. و توجه کنید که رشته‌های نمونه هم دقیقاً همین عرض‌ها را دارند: ATU_00000001 دوازده کاراکتر است، AT_00031001_01 چهارده کاراکتر، و AP_00031001 یازده کاراکتر. این عرض‌ها توصیه نیستند؛ اسکیِ با عرض ثابت‌اند، و نویسنده‌ای که یک UID سیزده‌کاراکتری می‌نویسد جدولی خراب تولید کرده، نه جدولی اندکی غیرمتعارف.

حالا با همان گروه شش‌نفره حساب کنیم. فرض کنید تار، سه‌تار، کمانچه، نی، تنبک و آواز هرکدام یک شیء مونو باشند (۶ ترک) و آرایهٔ میکروفون اتاق یک بستر 7.1.4 بدهد (۱۲ ترک). مجموع ۱۸ ترک، و اگر هر ترک دقیقاً یک تعریف داشته باشد، ۱۸ شناسه. اندازهٔ بدنهٔ chna می‌شود ۴ بایت (برای numTracks و numUIDs) به‌علاوهٔ ۱۸ × ۴۰ = ۷۲۰ بایت، یعنی ۷۲۴ بایت؛ و با احتساب ۸ بایت سرآیندِ ckID و ckSize، کل چانک ۷۳۲ بایت می‌شود. اگر ابزار شما چانکی تولید کرد که اندازه‌اش با این حساب نمی‌خواند، همان‌جا متوقف شوید: بدنهٔ chna همیشه باید برابر ۴ بایت به‌علاوهٔ چهل ضربدر تعداد شناسه‌ها باشد و اگر باقی‌ماندهٔ تقسیم ناسازگار بود، جدول قطعاً خراب است.

قرارداد شناسه‌ها. مقادیر 0x0FFF و پایین‌تر به تعاریف مشترکِ ADM اشاره می‌کنند — یعنی قالب‌های کانال و بستهٔ از پیش تعریف‌شدهٔ استاندارد — در حالی که 0x1000 و بالاتر نشان‌دهندهٔ تعریف سفارشی‌اند که باید در چانک axml حاضر باشد. پس AP_00010003 به‌حکم تعریف مشترک یعنی ۵٫۱ و به هیچ XML ای نیاز ندارد؛ اما AP_00031001 یک بستهٔ شیءِ سفارشی است و بدون XML یک ارجاع آویزان می‌شود. در مثال ما، دوازده کانال بستر با تعاریف مشترک پوشش داده می‌شوند و شش شیءِ نوازنده حتماً باید در XML تعریف شده باشند.

شناسهٔ ترک، شمارهٔ سریالِ فایل برای هویت یک ترک فیزیکی است، و برای این وجود دارد که یک ترک بتواند به‌طور مشروع، در میانهٔ یک برنامه، محتوایش را عوض کند.

همین نکته توضیح می‌دهد چرا numUIDs می‌تواند از numTracks بیشتر باشد. راهنمای EBU تصریح می‌کند که وقتی «عناصر صوتیِ یک ترک ممکن است در طول فایل به‌گونهٔ متفاوتی تعریف شوند … برای هر تعریف یک شناسهٔ متفاوت خواهد بود.» پس یک trackIndex می‌تواند در چند ورودی ظاهر شود. در ضبط ما، اگر ترک آواز در بخش «آواز» یک شیء ساکن باشد و در «رِنگ» پایانی تعریف دیگری بگیرد، آن ترک دو شناسه دارد: ۱۹ شناسه برای ۱۸ ترک، بدنهٔ chna برابر ۴ + (۴۰ × ۱۹) = ۷۶۴ بایت و کل چانک ۷۷۲ بایت. ابزارهای کنترل کیفیتی که فرض می‌کنند هر ترک فقط یک شناسه دارد، فایل‌های سالم را خراب اعلام می‌کنند.

چانک axml — خودِ ADM

یک سند XML با کدگذاری UTF-8 که درخت <audioFormatExtended> را در خود دارد. این همان ADM است. متن است، قابل بازرسی است، و عملاً تمام خطاهای جالب توجه همین‌جا زندگی می‌کنند.

چانک data — نمونه‌های درهم‌بافته

نمونه‌های PCM درهم‌بافته، دقیقاً مثل WAV. هیچ‌چیز در data از وجود شیء خبر ندارد.

ترتیب چانک‌ها

چانک ds64 همیشه اول. چانک fmt پیش از data. اما چانک axml می‌تواند به‌طور کاملاً مشروع پس از data قرار بگیرد و اغلب هم می‌گیرد، چون همان‌طور که BS.2088 اشاره می‌کند، هنگام ضبط «طول متادیتای XML احتمالاً نامعلوم خواهد بود». فایلی که axml اش در انتهاست خراب نیست؛ ولی خواننده‌ای که فقط مگابایت اول را می‌کاود، گزارش می‌دهد که فایل هیچ متادیتایی ندارد. سهم شگفت‌آوری از گزارش‌های «فایل من متادیتا ندارد» از همین یک واقعیت می‌آید.

۴. مدل شیء در ADM

توصیهٔ ITU-R BS.2076 مدل را به دو نیمه می‌شکند. نیمهٔ قالب «ماهیت فنی صوت را توصیف می‌کند تا بتوان آن را درست دیکد یا رندر کرد» و می‌تواند پیش از وجود هر صوتی نوشته شود. نیمهٔ محتوا «زبان دیالوگ، بلندی صدا و مانند آن» را توصیف می‌کند و فقط پس از وجود سیگنال کامل می‌شود. دانستن اینکه یک عنصر به کدام نیمه تعلق دارد، به شما می‌گوید خطا در کدام مرحلهٔ تولید وارد شده است.

سلسله‌مراتب، از بالا به پایین:

audioProgramme یک ارائهٔ کاملِ تحویل‌شدنی. به یک یا چند عنصرِ محتوا ارجاع می‌دهد.

audioContent جزئی از برنامه با معنای تدوینی: استمِ آواز، استمِ ساز، یک نسخهٔ زبانی. به یک یا چند عنصرِ شیء ارجاع می‌دهد.

audioObject محل اتصال نیت تدوینی به قالب فنی. زمان شروع و مدت را حمل می‌کند و به صفر یا چند قالبِ بسته، صفر یا چند شیءِ تودرتو، و صفر یا چند شناسهٔ ترک ارجاع می‌دهد. اینجاست که محتوا به ذاتِ صوت می‌رسد.

audioPackFormat گروهی از کانال‌ها که به هم تعلق دارند: یک بسترِ دوازده‌کاناله، یک جفت استریو، یا یک مجموعهٔ آمبیسونیک از مرتبه‌ای معیّن.

audioChannelFormat رفتار یک کانال در طول زمان. شامل یک یا چند بلوکِ قالب است.

audioBlockFormat اتم مدل. برای اشیاء: موقعیت — زاویهٔ افقی، زاویهٔ ارتفاع و فاصله، یا همان‌ها به‌صورت مختصات دکارتی — به‌همراه گین، اندازه، پخش‌شدگی، زمان شروعِ نسبی و مدت. یک شیء ساکن یک بلوک دارد؛ شیء متحرک یک دنباله.

audioTrackUID برگ، و تنها عنصری که متناظر با یک ترک فیزیکی است. صفت‌های اختیاریِ نرخ نمونه‌برداری و عمق بیت را حمل می‌کند.

عناصر audioStreamFormat و audioTrackFormat میان قالب کانال و شناسهٔ ترک می‌نشینند و کدگذاری جریان را توصیف می‌کنند. متن BS.2076-3 می‌گوید برای PCM این‌ها عملاً زائدند و «باید حذف شوند»، اما خوانندگان «باید آگاه باشند که فایل‌های ADM موجود (بر پایهٔ ویرایش دوم و پیش از آن) برای صوت PCM ممکن است آن‌ها را داشته باشند». هر دو شکل قانونی‌اند و اعتبارسنجی که فقط یکی را بپذیرد، دربارهٔ دیگری اشتباه می‌کند.

مدل

ADM یک گراف از ارجاع‌هاست، نه یک سند تودرتو؛ و هر شکست جدیِ تحویل، یک یالِ شکسته در آن گراف است.

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

۵. رندر: از ADM به چیدمان‌های BS.2051

یک مستر شیءمحور، پیش از آنکه از بلندگویی بیرون بیاید، باید رندر شود. توصیهٔ ITU-R BS.2127 همین را تعریف می‌کند: رندررِ مرجعِ ADM برای سیستم‌های صوتی پیشرفته. ورودی‌اش یک فایل BW64 با متادیتای ADM است و خروجی‌اش سیگنال کانال‌محور برای یکی از چیدمان‌های تعریف‌شده در BS.2051. همزادِ متن‌باز آن، رندررِ ADM اتحادیهٔ اروپا (سند EBU Tech 3388)، راه عملی رسیدن به عددی تکرارپذیر است.

معنای عملی این جمله برای مهندس ایرانی مهم است: تحویلیِ شما یک صدا ندارد، یک خانواده از صداها دارد. همان فایل، رندرشده روی System B (۵٫۱)، روی System J (۴+۷+۰) و روی یک خروجی باینورال برای هدفون، سه نتیجهٔ متفاوت می‌دهد. تصمیم‌های میکس شما باید در برابر این تفاوت مقاوم باشند. شیئی که در چیدمان بزرگ دقیقاً پشت سر شنونده است، در چیدمانی بدون بلندگوی پشتی جایی میان بلندگوهای موجود توزیع می‌شود. اگر تمایز تار و سه‌تار در میکس شما فقط به تفاوت چند درجه در زاویه وابسته باشد، آن تمایز روی چیدمان کوچک‌تر از بین می‌رود؛ اگر به تفاوت رنگ صدا و سطح هم وابسته باشد، می‌ماند.

۶. بلندی صدا در ایمرسیو، زیر BS.1770-5

اینجا باید آنچه منتشر شده را از آنچه در محافل می‌چرخد جدا کرد.

آنچه ITU-R BS.1770 مشخص می‌کند

**ویرایش جاری، BS.1770-5 است که در نوامبر ۲۰۲۳ منتشر شد.** ویرایش BS.1770-4 (اکتبر ۲۰۱۵) منسوخ شده است، هرچند هنوز همان ویرایشی است که بیشتر مترهای مستقر به آن ارجاع می‌دهند. در یادداشت‌های تحویل، همیشه ویرایش پنجم را نام ببرید.

توصیه K-weighting را تعریف می‌کند: یک فیلتر شلف بالا که مدل یک کرهٔ صلب («فیلتر سر») است، و پس از آن یک فیلتر بالاگذرِ RLB. بهرهٔ این منحنی در یک کیلوهرتز برابر +۰٫۶۹۸ دسی‌بل است (به‌صورت خطی ۱٫۰۸۳۶). اندازه‌گیری با بلوک‌های ۴۰۰ میلی‌ثانیه‌ای و همپوشانی ۷۵ درصد انجام می‌شود، با یک دروازهٔ مطلق که بلوک‌های زیر منفی ۷۰ LUFS را دور می‌ریزد، و یک دروازهٔ نسبی که از میانگین بلوک‌هایی محاسبه می‌شود که از دروازهٔ مطلق جان به در برده‌اند و سپس منفی ۱۰ LU جابه‌جا می‌شود. این دروازهٔ نسبی از میانگینِ بلوک‌های بازمانده گرفته می‌شود، نه از میانگین بی‌دروازه — تمایزی که پیاده‌سازی‌ها آن‌قدر اشتباه می‌گیرند که ارزش تکرار دارد.

وزن کانال در الگوریتم هسته برابر ۱٫۰ (صفر دسی‌بل) برای چپ، راست و مرکز است و ۱٫۴۱ (تقریباً +۱٫۵ دسی‌بل) برای کانال‌های احاطه‌ای، و کانال LFE کنار گذاشته می‌شود. دامنهٔ الگوریتم پایه «از یک تا پنج کانال» است. ویرایش پنجم در ضمائم خود از این فراتر می‌رود و سیستم‌های صوتی پیشرفتهٔ BS.2051 — بلندگوهای با موقعیت دلخواه و کانال‌های ارتفاع — و نیز صدای شیءمحور را پوشش می‌دهد؛ صدای شیءمحوری که پیش از اندازه‌گیری باید رندر شود.

بلندی صدای ایمرسیو خاصیتِ فایل نیست؛ خاصیتِ یک رندر است، و عوض‌کردن چیدمان مقصد، عدد را عوض می‌کند.

تفاوت ماهوی با استریو همین است. یک مسترِ استریو یک مقدار بلندی دارد. یک مستر شیءمحور به تعداد مقصدهای رندرش مقدار دارد، و راه صادقانهٔ اعلام یک عدد این است که چیدمانی که روی آن اندازه گرفته شده و رندرری که استفاده شده هم نام برده شوند.

اسناد مرتبط EBU

سند EBU Tech 3341 رفتار مترها را تعریف می‌کند: بلندیِ لحظه‌ای با پنجرهٔ ۴۰۰ میلی‌ثانیه و بلندیِ کوتاه‌مدت با پنجرهٔ ۳ ثانیه. سند EBU Tech 3342 دامنهٔ بلندی یا LRA را تعریف می‌کند که از دروازهٔ نسبیِ منفی ۲۰ LU استفاده می‌کند — نه منفی ۱۰ LU؛ استفاده از منفی ۱۰ برای LRA یک باگ رایج پیاده‌سازی است. توصیهٔ EBU R 128 هدفِ برنامهٔ پخش را منفی ۲۳ LUFS می‌گذارد؛ این یک رویّهٔ نرمال‌سازیِ پخش است، نه مشخصهٔ استریمینگ موسیقی.

آنچه برای موسیقی منتشر شده است

برای موسیقیِ استریوی کانال‌محور، Spotify هدف یکپارچهٔ منفی ۱۴ LUFS و سقف قلهٔ حقیقیِ منفی ۱ dBTP را منتشر می‌کند، که برای مسترهای بلندتر از منفی ۱۴ LUFS به منفی ۲ dBTP سخت‌گیرانه‌تر می‌شود. سند AES TD1008 برای موسیقی منفی ۱۶ LUFS را توصیه می‌کند؛ عدد منفی ۱۸ LUFS در همان سند مربوط به محتوای گفتارمحور است و بیان آن به‌عنوان هدف موسیقی یک خطای رایج و جدی است.

قلهٔ حقیقی هم روی سیگنال بیش‌نمونه‌برداری‌شده اندازه گرفته می‌شود — دست‌کم چهار برابر بر پایهٔ BS.1770، و هشت برابر بهتر است. قلهٔ نمونه با قلهٔ حقیقی یکی نیست و قله‌های میان‌نمونه‌ای می‌توانند از بلندترین مقدار نمونه فراتر بروند.

آنچه منتشر نشده است

هیچ سرویس استریمینگ موسیقی، هدف بلندی یکپارچه‌ای برای تحویل ایمرسیو منتشر نکرده است. اعدادی در انجمن‌ها و مواد آموزشی فروشندگان می‌چرخد؛ بعضی محتمل‌اند و شاید بعضی درست باشند. اما هیچ‌کدام یک مشخصهٔ منتشرشده نیست و این سند هیچ‌یک را به‌جای مشخصه تکرار نمی‌کند.

به‌همین ترتیب، برای استریو هم Apple Music و YouTube Music و Amazon Music و TIDAL و Deezer هیچ هدف نرمال‌سازی‌ای منتشر نکرده‌اند. اعدادی که برای این سرویس‌ها نقل می‌شود به‌طور گسترده گزارش شده اما توسط خودِ سرویس منتشر نشده است و هرگز نباید مبنای محاسبهٔ یک تغییر گین قرار بگیرد.

اگر امروز به عددی قابل دفاع برای بلندی ایمرسیو نیاز دارید: یک رندرِ منطبق بر BS.2127 روی یک چیدمان نام‌برده از BS.2051 بگیرید، با متری منطبق بر BS.1770-5 اندازه بگیرید، و هر سه را در یادداشت تحویل بنویسید.

دربارهٔ سامانه‌های اختصاصی

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

۷. واقعیت استودیوهای ایران: تحویل فایلی که نمی‌توانید بشنوید

بیایید صادق باشیم. بیشتر استودیوهای ایران — از اتاق‌های خصوصی تا مجموعه‌های حرفه‌ای — مانیتورینگ ایمرسیو ندارند. نه دوازده بلندگوی کالیبره‌شده، نه اتاقی که پاسخ ارتفاعش قابل اعتماد باشد، و اغلب نه بودجه‌ای برای هیچ‌کدام. توصیهٔ رایجی که می‌گوید «روی یک سیستم 7.1.4 گوش کنید و تصمیم بگیرید» برای بیشتر خوانندگان این متن، توصیهٔ عملی نیست.

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

چه چیزهایی را بدون مانیتورینگ می‌توانید قطعی بررسی کنید

1. امضای فایل. چهار بایت اول باید

BW64 باشد. اگر RIFF است، فایل یک WAV ساده است و از ۴ گیبی‌بایت رد نمی‌شود.

1. تطابق تعداد کانال. مقدار

nChannels در fmt باید با numTracks در chna یکی باشد. این ارزان‌ترین بررسی کل زنجیره است و سهم شگفت‌آوری از خرابی‌ها را می‌گیرد. علت معمولش این است که یک بونس، تعداد ترک را پس از نوشتن متادیتا عوض کرده.

1. حسابِ ۴۰ بایت. بدنهٔ

chna باید دقیقاً برابر ۴ بایت به‌علاوهٔ چهل ضربدر تعداد شناسه‌ها باشد. اگر نیست، جدول خراب است.

1. شناسه‌های یتیم. مجموعهٔ شناسه‌ها را از

chna و از axml بسازید و تفاضل متقارنشان را بگیرید؛ باید تهی باشد. سند EBU Tech 3392 نیت را صریح می‌کند: «اگر audioObject به یک audioPackFormat ارجاع می‌دهد، باید به audioTrackUID های متناظر هم ارجاع بدهد.»

1. زمان‌بندی بلوک‌ها. متن

BS.2076 صریح است: وقتی بیش از یک audioBlockFormat در یک audioChannelFormat هست، «هر دوی rtime و duration باید حاضر باشند». سند EBU Tech 3392 آن را به قاعدهٔ پیوستگی سفت می‌کند: مجموع rtime و duration هر بلوک باید با rtime بلوک بعدی برابر باشد، بلوک نخستِ هر شیء از 00:00:00.00000 شروع شود، هیچ بلوکی کوتاه‌تر از یک نمونه نباشد، و جمع مدت‌ها با مدت audioObject والد بخواند. خطاها در سه شکل خوشه می‌شوند: شکاف (رفتار رندرر تعریف‌نشده است — بعضی موقعیت آخر را نگه می‌دارند، بعضی سکوت می‌کنند)، همپوشانی (بلوک‌هایی که با هم می‌جنگند)، و بلوک‌های خارج از ترتیب زمانی.

1. نرخ نمونه و عمق بیت. عنصر

audioTrackUID می‌تواند صفت‌های sampleRate و bitDepth داشته باشد. اگر با fmt نخوانند، دو ادعای متناقض دربارهٔ یک ذات دارید. موضع EBU Tech 3392 این است که این صفت‌ها «اگر از خود صوت در دسترس‌اند باید نادیده گرفته شوند» — ولی هر رندرری از این راهنما پیروی نمی‌کند. مهم‌تر: **تبدیل نرخ نمونه پس از نوشتن ADM، هر rtime و duration ی را که بر حسب نمونه بیان شده بی‌اعتبار می‌کند.** هرگز پس از نوشتن متادیتا نرخ را عوض نکنید.

1. **جای چانک

axml.** صریحاً کل فایل را برای یافتن axml بگردید، از جمله پس از data. از یک کاوش ناقص نتیجه نگیرید که «متادیتا ندارد».

تنها چیزی که ساختار نمی‌گیرد

یک نکته را باید صریح گفت: **بررسی ساختاری نمی‌تواند بگوید کانالی که در XML اعلام شده، روی دیسک واقعاً سیگنال دارد یا نه.** فرض کنید XML یک بستهٔ DirectSpeakers از نوع 7.1.4 اعلام کرده — دوازده کانال — ولی هنگام بونس فقط زیرمجموعهٔ ۵٫۱ نوشته شده، یا کانال‌های ارتفاع بی‌صدا بوده‌اند و به‌صورت سکوت دیجیتال روی دیسک رفته‌اند. گراف ارجاع سالم است؛ صوت نیست.

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

ظرف می‌تواند کاملاً معتبر باشد،

XML کاملاً خوش‌ساخت باشد، و تحویلی همچنان غلط باشد؛ تنها راه بررسی یک کانال خالیِ بستر، نگاه‌کردن به خودِ نمونه‌هاست.

یک بازرسِ رایگانِ BW64/ADM که در مرورگر کار می‌کند روی mazufa.com موجود است؛ ظرف و متادیتا را کاملاً روی دستگاه خودِ شما تجزیه می‌کند و هیچ فایلی آپلود نمی‌شود، که آن را برای موادی که قراردادی اجازهٔ خروج از استودیو ندارند قابل استفاده می‌کند.

و یک توصیهٔ میکس که بدون مانیتورینگ هم معتبر است

اگر نمی‌توانید ارتفاع را بشنوید، در ارتفاع بلندپروازی نکنید. یک بستر اتاقِ صادق، به‌علاوهٔ اشیائی که در همان جای واقعیِ نوازنده‌ها نشسته‌اند، ترجمهٔ قابل اتکایی روی هر چیدمانی می‌دهد. حرکت‌های تند و تزئینیِ اشیاء در فضا، بدون امکان شنیدن، ریسکی است که سودش نامعلوم و زیانش قطعی است. برای موسیقی کلاسیک ایرانی این محدودیت عملاً محدودیت نیست: هدف، بازسازی یک اتاق واقعی است و نه ساختن یک صحنهٔ متحرک.

۸. چک‌لیست تحویل

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

ظرف

1. چهار بایت اول

BW64 است.

1. چانک

ds64 نخستین چانک پس از امضاست و اندازه‌های ۶۴بیتی‌اش با اندازهٔ واقعی فایل و چانک data روی دیسک می‌خواند.

1. هر چانک بزرگِ غیر از

data یک ورودی اندازهٔ ۶۴بیتی در جدول ds64 دارد.

1. چانک

axml صریحاً پیدا شده، از جمله پس از data.

ذاتِ صوت

1. نرخ نمونه و عمق بیت در

fmt دقیقاً با مشخصهٔ تحویل می‌خواند. هیچ تبدیل نرخی پس از نوشتن ADM انجام نشده.

1. مقدار

nChannels برابر numTracks است.

1. هر

trackIndex در محدوده است و از ۱ شروع می‌شود.

**یکپارچگی chna**

1. هر ورودی دقیقاً ۴۰ بایت با فیلدهای عرض‌ثابتِ درست لایی‌گذاری‌شده است، و بدنه برابر ۴ بایت به‌علاوهٔ چهل ضربدر تعداد شناسه‌هاست.
2. هر

packRef در بازهٔ 0x1000 به بالا به تعریفی سفارشی در axml می‌رسد.

1. تکرار

trackIndex عمدی است (ترکی که به‌درستی تعریفش را عوض می‌کند)، نه خطای تکثیر.

**گراف ADM**

1. هر

audioContentIDRef و audioObjectIDRef و audioPackFormatIDRef و audioChannelFormatIDRef و audioTrackUIDRef حل می‌شود. صفر یالِ آویزان.

1. هیچ

audioTrackUID یتیمی در هیچ جهتی نیست.

1. هیچ عنصر دوری یا خودارجاعی وجود ندارد.
2. برچسبِ نوع هر

audioChannelFormat با بستهٔ والدش می‌خواند.

زمان‌بندی

1. قالب‌های کانالِ چندبلوکی، هم

rtime و هم duration را روی هر بلوک دارند.

1. بلوک‌ها پیوسته و یکنواخت‌اند؛ جمع مدت‌ها با مدت

audioObject والد می‌خواند.

1. اشیاء از

00:00:00.00000 شروع می‌شوند.

محتوا

1. هر کانال از بسترِ اعلام‌شده آنچه را که باید دارد؛ سکوت دیجیتال بررسی شده است.
2. تعداد اشیاء و پیکربندی بستر با مشخصهٔ تحویل می‌خواند.
3. تایم‌کد شروع در

bext درست است و در همهٔ فایل‌های مجموعه یکسان است.

رندرها و نسخه‌های تطبیقی

1. نسخه‌های استریو و باینورال از مسترِ جاری دوباره رندر شده‌اند، نه از نسخهٔ قبلی حمل شده‌اند. شکست معمول، نبودِ آن‌ها نیست — نبود آشکار است — بلکه رانش است: نسخه‌ای که از ویرایش قبلی رندر شده و چند فریم جلو یا عقب است. فایلی که ۴۰ میلی‌ثانیه زودتر شروع شود، از بررسی حضور فایل عبور می‌کند و در شنیدن هم‌زمان می‌افتد.
2. مدت‌ها و تایم‌کدهای شروع، نمونه‌به‌نمونه با مستر می‌خوانند.
3. بلندی صدا روی یک رندرِ نام‌برده به یک چیدمان نام‌برده با یک رندررِ نام‌برده اندازه گرفته شده و هر سه در یادداشت تحویل ثبت شده‌اند.

تکرارپذیری

1. برای هر فایل تحویلی چک‌سام گرفته و فهرست را نگه داشته‌اید.
2. سشن و خودِ

XML مربوط به ADM را جدا از فایل BW64 بایگانی کرده‌اید؛ XML ای که بتوانید تفاوتش را ببینید، بعدها از یک باینری که فقط می‌شود دوباره تجزیه‌اش کرد ارزشمندتر است.

یک تحویلیِ ایمرسیو وقتی تمام نمی‌شود که خوب به‌نظر برسد؛ وقتی تمام می‌شود که ماشینی که هرگز آن را نشنیده بتواند ثابت کند ارجاع‌هایش حل می‌شوند.

۹. جمع‌بندی

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

و ارزشش را دارد که تصویر بزرگ‌تر را به یاد داشته باشیم: بیشترین سهمِ ردشدن‌های غیرضروری در تحویل موسیقی امروز، در ایمرسیو اتفاق می‌افتد، و تقریباً همهٔ آن‌ها خطاهای یکپارچگیِ ارجاع‌اند که یک اعتبارسنج در کمتر از یک ثانیه می‌گیرد.

توزیع در Mazufa رایگان است — بدون هزینهٔ آپلود، بدون اشتراک و بدون هزینه به‌ازای هر انتشار — و تنها کسر ما ۵٪ از حق‌الامتیازِ دریافتی است؛ هر درخواستِ کامل هم بازبینی انسانی می‌شود.

منابع

**توصیه‌های 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
• ITU-R BS.2127 landing page — https://www.itu.int/rec/R-REC-BS.2127

**اسناد فنی EBU**

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285, 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 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, EBU Tech 3342 — https://tech.ebu.ch
• 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
• EBU ADM Renderer (EAR), BW64 I/O — https://ear.readthedocs.io/en/latest/BW64.html
• libbw64 — https://github.com/ebu/libbw64
• 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/

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

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

*آخرین بازبینی: شهریور ۱۴۰۵ (سپتامبر ۲۰۲۶). استانداردها بازنگری می‌شوند؛ پیش از نقل هر بند، ویرایش جاری را روی صفحه‌های ITU و EBU بالا بررسی کنید.*