لماذا يجتاز ماستر الصوت الغامر محرّر الموجات ويرسب في مراقبة الجودة

قد يُفتح ملف تسليم غامر في محرّر موجات، فيُظهر اثني عشر أو ستة عشر مسارًا سليمة المظهر، ويعمل تشغيله على نحو معقول، ويُرفض مع ذلك. والسبب بنيوي: ففي ملف BW64 يكون الصوت والبيانات الوصفية شيئين منفصلين يجب أن يتطابقا تمامًا، ولا شيء في الصيغة نفسها يُلزمهما بذلك. المُصيِّر يحلّ المراجع. والمحرِّر يرسم العيّنات. وظيفتان مختلفتان — ولهذا فإن مراقبة جودة ADM هي فحص لسلامة المراجع، لا استماع. وفيما يلي ما يقوله المعياران، وأين تنكسر المراجع، وأي فحص يلتقط أيّ عطل.

ثلاثة أنواع من الصوت، ولماذا يحسم التمييز بينها كل شيء

كل مشكلة في تسليم الصوت الغامر تبدأ من التباس حول أيّ الأنواع الثلاثة ينتمي إليه المسار.

الصوت القائم على القنوات يُسنِد كل مسار إلى موضع مكبّر صوت ثابت. الستيريو قائم على القنوات، وكذلك 5.1، وكذلك فراش 7.1.4. الموضع مخبوز داخل هوية القناة: المسار 3 هو مكبّر المنتصف، وهو مكبّر المنتصف في كل نظام يشغّله. ويصوغ ITU-R BS.2051 هذا رسميًا لأنظمة الصوت المتقدمة، واصفًا التخطيطات بعدد الطبقات Upper + Middle + Bottom — فالنظام A هو 0+2+0 (ستيريو)، والنظام B هو 0+5+0 (5.1)، والنظام D هو 4+5+0، والنظام J هو 4+7+0، والنظام 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 بحجم بايتين وnumUIDs بحجم بايتين، يحمل مصفوفة مسطّحة من مدخلات 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 واحد في عدة مدخلات. وأدوات مراقبة الجودة التي تفترض 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 مقابلة، تعني بيانات وصفية تتوقع مسارًا غير موجود. ابنِ مجموعة المعرّفات من 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 (November 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) هو الطريق العملي إلى رقم قابل لإعادة الإنتاج.

لا تنشر أي خدمة بث موسيقي هدف جهارة متكاملة للتسليم الغامر. تتداول أرقام في المنتديات وفي مواد تدريب الموردين؛ ولا واحد منها مواصفة منشورة، ولن يكرر هذا المقال رقمًا منها كأنه كذلك. أما المنشور فهو للستيريو القائم على القنوات — هدف Spotify المتكامل عند −14 LUFS مع سقف ذروة حقيقية عند −1 dBTP، يُشدَّد إلى −2 dBTP فوق −14 LUFS، ورقم −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 عن أصلها الغامر تجتاز فحص وجود الملفات وترسب في استماع متزامن.
• احسب مجموع تحقق لكل ملف تسليم، واحتفظ بالبيان، وأرشِف ADM XML بمعزل عن BW64 — فـXML يمكنك مقارنته سطرًا بسطر يساوي لاحقًا أكثر من ثنائي لا تملك إلا إعادة تحليله.

BW64 وADM معياران مفتوحان ومنشوران وقابلان للقراءة مجانًا، وهذا يستحق الاستفادة: يمكنك أن تقرأ BS.2088 وBS.2076 بنفسك، وأن تحلّل مقطع chna بأربعين سطر شيفرة، وأن تتحقق مما كتبه مصدّر المورّد فعلًا بدل ما ادّعاه مربّع الحوار. وتكاد كل حالات رفض الصوت الغامر التي لا داعي لها تكون أخطاء في سلامة المراجع يلتقطها مدقّق في أقل من ثانية.

فاحص BW64/ADM المجاني من Mazufa على mazufa.com/immersive-master-check يحلّل الحاوية والبيانات الوصفية على جهازك أنت بالكامل ولا يرفع شيئًا، ما يجعله صالحًا للاستعمال على مواد لا يجوز تعاقديًا أن تغادر المبنى. وMazufa نفسها مجانية للإصدار، وعمولتها 0%، وهي بالدعوة فقط مع مراجعة بشرية لكل طلب مكتمل.

المصادر

توصيات 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.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 التقنية

• 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/