امرسِو ماسٹر ویوفارم ایڈیٹر میں پاس اور QC میں فیل کیوں ہوتا ہے

ایک امرسِو ڈیلیوریبل ویوفارم ایڈیٹر میں کھل سکتا ہے، بارہ یا سولہ صحت مند دکھتے ٹریک دکھا سکتا ہے، معقول انداز میں چل سکتا ہے، اور پھر بھی مسترد ہو سکتا ہے۔ وجہ ساختی ہے: BW64 فائل میں آڈیو اور میٹا ڈیٹا دو الگ چیزیں ہیں جن کا آپس میں بالکل ٹھیک متفق ہونا لازم ہے، اور فارمیٹ میں ایسا کچھ نہیں جو انہیں اس پر مجبور کرے۔ رینڈرر حوالے حل کرتا ہے۔ ایڈیٹر سیمپل کھینچتا ہے۔ دو مختلف کام — اور یہی وجہ ہے کہ ADM کا QC حوالہ جاتی سالمیت کی جانچ ہے، سماعت نہیں۔ یہاں درج ہے کہ دونوں معیارات کیا کہتے ہیں، حوالے کہاں ٹوٹتے ہیں، اور کون سی جانچ کون سی ناکامی پکڑتی ہے۔

آڈیو کی تین قسمیں، اور یہ فرق ہر چیز کا فیصلہ کیوں کرتا ہے

امرسِو ڈیلیوری کا ہر مسئلہ اسی الجھن سے شروع ہوتا ہے کہ کوئی ٹریک اِن تین چیزوں میں سے کیا ہے۔

چینل بیسڈ آڈیو ہر ٹریک کو ایک مقررہ لاؤڈ اسپیکر پوزیشن سونپتا ہے۔ اسٹیریو چینل بیسڈ ہے، 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 میں یہ DirectSpeakers typeDefinition ہے، typeLabel 0001۔

آبجیکٹ بیسڈ آڈیو ایک مونو (یا ملٹی چینل پیک) سگنل کے ساتھ پوزیشن کا میٹا ڈیٹا لے کر چلتا ہے جو وقت کے ساتھ بدلتا ہے۔ کمرے میں موجود لے آؤٹ کی بنیاد پر رینڈرر طے کرتا ہے کہ اسے کون سے حقیقی لاؤڈ اسپیکر بجائیں گے۔ ٹریک کے بارے میں کوئی چیز کسی اسپیکر کو فرض نہیں کرتی۔ یہ typeDefinition Objects ہے، typeLabel 0003۔

سین بیسڈ آڈیو، جو عملاً ہائر آرڈر ایمبی سونکس ہے، پوری صوتی فضا کو کروی ہارمونک اجزا کے طور پر انکوڈ کرتا ہے۔ کوئی جزو بذاتِ خود کسی سمت سے مطابقت نہیں رکھتا؛ سمت لینیئر مجموعے سے ابھرتی ہے۔ یہ HOA ہے، typeLabel 0004۔ ADM میٹرکسڈ سگنلز، مثلاً مڈ سائیڈ یا Lt/Rt، کے لیے Matrix (0002) اور Binaural (0005) بھی متعین کرتا ہے۔

یہ فرق درجہ بندی کی موشگافی نہیں۔ چینل بیسڈ ڈیلیوریبل اتنا خود بیان ہوتا ہے کہ سادہ WAV کی صورت میں بھی بچ رہے — چینل کی ترتیب درست رکھیں اور وہ چل پڑے گا۔ آبجیکٹ بیسڈ یا سین بیسڈ ڈیلیوریبل اپنے میٹا ڈیٹا کے بغیر بے معنی ہے: آڈیو غیر متمیز مونو اسٹریموں کا ڈھیر ہے، اور ADM ہی وہ اکلوتی چیز ہے جو اس کے برعکس کچھ کہتی ہے۔ یہی عدمِ توازن BW64 اور ADM کے وجود کی وجہ ہے۔

BW64 ایک 32-bit عدد کی وجہ سے وجود میں آیا

کلاسک WAV ایک RIFF فائل ہے۔ RIFF، جو 1991 کا ہے، ہر چنک سے پہلے ایک 32-bit سائز فیلڈ رکھتا ہے۔ بتیس بٹس 4,294,967,296 بائٹس — 4 GB — تک پتہ دے پاتے ہیں، اور یہی پوری فائل اور اُس کے اندر موجود data چنک، دونوں پر سخت حد ہے۔

48 kHz / 24-bit پر اسٹیریو کے لیے ڈیٹا ریٹ 288,000 بائٹس فی سیکنڈ ہے، یعنی 4 GB تقریباً 4 گھنٹے 8 منٹ بنتے ہیں۔ غیر متعلق۔ 96 kHz / 24-bit پر 128 ٹریک والے آبجیکٹ بیسڈ ماسٹر کے لیے یہی ریٹ 36,864,000 بائٹس فی سیکنڈ ہے، اور 4 GB دو منٹ سے بھی کم — 116.5 سیکنڈ بنتے ہیں۔

امرسِو ماسٹرز یہ حد معمول کے مطابق پار کرتے ہیں، اور جو WAV رائٹر اس سے ٹکراتا ہے وہ یا تو کٹی ہوئی فائل بناتا ہے یا ایسی جس کے درج کردہ سائز خاموشی سے لپیٹ کھا چکے ہیں۔ EBU نے سب سے پہلے RF64 (EBU Tech 3306) سے اس کا علاج کیا؛ ITU نے اسے آگے بڑھا کر Recommendation 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-bit سائز فیلڈز ایسکیپ فلیگ بن جاتی ہیں: "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-bit سائز ایک ds64 چنک میں رکھ دیتا ہے، جسے فائل میں سب سے پہلے ہونا لازم ہے۔ چنانچہ 4 GB سے چھوٹی BW64 فائل چار حرفی دستخط کے سوا ہر لحاظ سے WAV ریڈر کے لیے بائٹ کی سطح پر ہم آہنگ ہے۔ بہت سے ٹولز اسے قبول کر لیتے ہیں؛ کچھ ہٹ دھرمی سے نہیں کرتے۔

چنکس، اور وہ ایک جو فی اندراج ٹھیک 40 بائٹس کا ہے

BS.2088 کے مطابق BW64 فائل میں کم از کم ds64، fmt ، chna، axml (اور متبادل میٹا ڈیٹا حاملین کے طور پر bxml اور sxml) اور ویو ڈیٹا ہونے کی توقع کی جاتی ہے۔

ds64 کو دستخط کے بعد پہلا چنک ہونا چاہیے، کیونکہ ریڈر کو کسی اور چیز پر چلنے سے پہلے اصل سائز معلوم ہونا ضروری ہے۔ یہ پوری فائل کے سائز اور data کے سائز کے لیے 32-bit نچلے/بالائی نصف رکھتا ہے، اور ساتھ کسی بھی دوسرے حد سے بڑے چنک کے لیے ChunkSize64 اندراجات کا ایک جدول — ہزاروں آبجیکٹس کو سیمپل کی سطح تک درست آٹومیشن کے ساتھ بیان کرنے والا axml چنک خود 4 GB کے قریب پہنچ سکتا ہے یا اس سے آگے نکل سکتا ہے۔

fmt معیاری WAVE فارمیٹ چنک ہے — سیمپل فارمیٹ، سیمپل ریٹ، چینل کی تعداد، بٹس فی سیمپل، بلاک الائن۔ یہی اکلوتا مستند بیان ہے کہ data میں کتنے انٹرلیوڈ چینل ہیں۔ اس کے بعد کی ہر چیز اُن چینلوں کے بارے میں میٹا ڈیٹا ہے، اور میٹا ڈیٹا جھوٹ بول سکتا ہے۔

chna طبیعی ٹریکوں اور ADM کے درمیان پل ہے۔ ckID، ckSize، 2 بائٹ کے numTracks اور 2 بائٹ کے numUIDs کے بعد یہ مقررہ چوڑائی والے audioID اندراجات کی ایک ہموار صف رکھتا ہے، ہر ایک ٹھیک 40 بائٹس کا:

2 + 12 + 14 + 11 + 1 = 40۔ یہ چوڑائیاں مشورہ نہیں ہیں: یہ مقررہ چوڑائی والے ASCII ہیں، اور جو رائٹر 13 حرفی UID لکھتا ہے اُس نے خراب جدول بنایا ہے، ذرا سا غیر معمولی جدول نہیں۔

ID کا ضابطہ بھی اہم ہے۔ 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 ایک UTF-8 XML دستاویز ہے جس میں <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 سے اوپر کی مخصوص رینج میں کوئی ID پا کر اور اس کا میچ نہ ملنے پر اُس کی جگہ سکوت بھر سکتا ہے۔ تینوں نتیجوں میں "فائل کھل گئی"۔ صرف ایک سننے سے پکڑا جاتا ہے، اور وہ بھی تب جب آپ کو معلوم ہو کہ وہاں ہونا کیا چاہیے تھا۔

وہ چار ناکامیاں جو زیادہ تر مستردیوں کا سبب بنتی ہیں

fmt کی ٹریک گنتی جو chna سے متفق نہ ہو۔ fmt .nChannels کہتا ہے 16؛ chna.numTracks کہتا ہے 14۔ فائل پہلے دو چنکس ہی سے اندرونی طور پر متضاد ہے — عام طور پر ایسا باؤنس جس میں میٹا ڈیٹا لکھے جانے کے بعد ٹریکوں کی تعداد بدل گئی، یا ایسا ٹول جس نے chna دوبارہ لکھے بغیر ٹریک گرا دیے۔ اس کی شناخت دو عدد پارس کر کے موازنہ کرنا ہے: پوری پائپ لائن کی سستی ترین جانچ، اور یہ ناکامیوں کا حیران کن حصہ پکڑ لیتی ہے۔ ساتھ ہی یہ بھی جانچ لیں کہ ہر trackIndex 1 … fmt .nChannels کے اندر ہو۔

ایسا audioTrackUID جس کا حوالہ کوئی آبجیکٹ نہ دیتا ہو۔ chna میں موجود وہ UID جس کا کوئی audioObject حوالہ نہ دے، اس کا مطلب ہے کہ آڈیو موجود ہے جسے کچھ بھی رینڈر نہیں کرے گا؛ اور اس کا الٹ، یعنی XML میں ایسا audioTrackUIDRef جس کا chna میں کوئی اندراج نہ ہو، اس کا مطلب ہے کہ میٹا ڈیٹا ایسے ٹریک کی توقع کر رہا ہے جو وہاں ہے ہی نہیں۔ chna سے UIDs کا مجموعہ اور axml سے UIDs کا مجموعہ بنائیں اور دونوں کا متناظر فرق نکالیں؛ اسے خالی ہونا چاہیے۔ 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 ایک 7.1.4 DirectSpeakers پیک کا اعلان کرتا ہے — بارہ چینل — مگر لکھا صرف 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.2051 لے آؤٹ پر BS.2127 کے مطابق رینڈر کو BS.1770-5 میٹر سے ناپیں اور تینوں چیزیں اپنے ڈیلیوری نوٹس میں درج کریں؛ BS.2127 حوالہ جاتی ADM رینڈرر متعین کرتا ہے، اور اس کا اوپن سورس ہم زاد EBU ADM Renderer (EBU Tech 3388) قابلِ اعادہ عدد حاصل کرنے کا عملی راستہ ہے۔

کوئی میوزک اسٹریمنگ سروس امرسِو ڈیلیوری کے لیے انٹیگریٹڈ لاؤڈنیس ہدف شائع نہیں کرتی۔ فورمز اور وینڈر کے تربیتی مواد میں اعداد گردش کرتے ہیں؛ ان میں سے کوئی شائع شدہ تخصیص نہیں، اور یہ مضمون کسی کو ایسے نہیں دہرائے گا جیسے وہ ہو۔ جو شائع شدہ ہے وہ چینل بیسڈ اسٹیریو کے لیے ہے — Spotify کا انٹیگریٹڈ ہدف −14 LUFS، ٹرو پیک حد −1 dBTP، جو −14 LUFS سے بلند ماسٹرز پر −2 dBTP تک سخت ہو جاتی ہے، اور AES TD1008 کا موسیقی کے لیے −16 LUFS (اس کا −18 LUFS والا عدد تقریر پر مبنی مواد پر لاگو ہوتا ہے، اور −18 کو موسیقی کا ہدف کہنا ایک عام اور سنگین غلطی ہے)۔

Dolby Atmos، Dolby Laboratories کی ملکیتی، لائسنس یافتہ ٹیکنالوجی ہے، اور Sony 360 Reality Audio ایک ملکیتی نظام ہے جو MPEG-H پر بنا ہے۔ ان کے تقاضے ان کے مالکان طے کرتے ہیں، ITU یا EBU کے شیڈول کے حوالے کے بغیر بدلتے ہیں، اور یہاں بیان نہیں کیے گئے؛ کسی وابستگی یا توثیق کا دعویٰ نہیں۔ لائسنس دہندہ کی اپنی موجودہ دستاویزات پڑھیں۔

بھیجنے سے پہلے کیا جانچیں

ساختی جانچیں پہلے؛ وہ تیز ہیں اور ناکام ہونے کی صورت میں اپنے بعد کی ہر چیز کو کالعدم کر دیتی ہیں۔

• پہلے چار بائٹس BW64 ہوں۔ اگر وہ RIFF پڑھے جائیں تو یہ سادہ WAV ہے اور 4 GB سے آگے نہیں جا سکتا۔
• ds64 دستخط کے بعد پہلا چنک ہو، اس کے 64-bit سائز ڈسک پر فائل اور data کے سائز سے مطابقت رکھتے ہوں، اور data کے علاوہ کسی بھی حد سے بڑے چنک کا جدول میں ChunkSize64 اندراج موجود ہو۔
• axml کو صراحتاً تلاش کریں، بشمول data کے بعد — نامکمل اسکین سے کبھی یہ نتیجہ نہ نکالیں کہ "ADM ہے ہی نہیں"۔
• fmt کا سیمپل ریٹ اور بٹ ڈیپتھ ڈیلیوری تخصیص سے بالکل ٹھیک مطابقت رکھتے ہوں۔ ADM لکھنے کے بعد سیمپل ریٹ کی تبدیلی نہیں — یہ سیمپلوں میں بیان کردہ ہر rtime اور duration کو باطل کر دیتی ہے۔
• fmt .nChannels chna.numTracks کے برابر ہو؛ ہر trackIndex حد کے اندر اور 1 سے شروع ہو۔
• chna کا ہر اندراج ٹھیک 40 بائٹس کا ہو، جس کی مقررہ چوڑائی والی فیلڈز درست پیڈ ہوں، اور 0x1000 یا اس سے اوپر کا ہر packRef axml میں موجود کسی مخصوص تعریف تک پہنچے۔
• ہر audioContentIDRef، audioObjectIDRef، audioPackFormatIDRef، audioChannelFormatIDRef اور audioTrackUIDRef حل ہو۔ کسی بھی سمت میں صفر لٹکتے کنارے، اور کوئی دائروی حوالہ نہیں۔
• کثیر بلاک چینل فارمیٹس کے ہر بلاک پر rtime اور duration دونوں ہوں؛ بلاکس متصل اور یک رخی ہوں؛ آبجیکٹس 00:00:00.00000 سے شروع ہوں۔
• اعلان شدہ بیڈ کے ہر چینل میں وہی ہو جو ہونا چاہیے۔ ڈیجیٹل بلیک کی تحقیق کریں۔
• bext کا اسٹارٹ ٹائم کوڈ پورے سیٹ میں یکساں ہو، اور اسٹیریو اور بائنورل کنفارمز موجودہ ماسٹر سے دوبارہ رینڈر کیے گئے ہوں۔ اپنے امرسِو والد کے مقابلے میں 40 ms پہلے چلنے والا کنفارم فائل کی موجودگی کی جانچ پاس کر لیتا ہے اور ہم وقت سماعت میں ناکام ہو جاتا ہے۔
• ہر ڈیلیوریبل کا چیک سم لیں، مینی فیسٹ محفوظ رکھیں، اور ADM XML کو BW64 سے الگ آرکائیو کریں — جس XML کا آپ diff نکال سکیں، وہ بعد میں اُس بائنری سے زیادہ قیمتی ہے جسے آپ صرف دوبارہ پارس کر سکتے ہیں۔

BW64 اور ADM کھلے، شائع شدہ، آزادانہ پڑھے جا سکنے والے معیارات ہیں، اور اس سے فائدہ اٹھانا چاہیے: آپ BS.2088 اور BS.2076 خود پڑھ سکتے ہیں، چالیس سطروں کے کوڈ سے chna چنک پارس کر سکتے ہیں، اور تصدیق کر سکتے ہیں کہ وینڈر کے ایکسپورٹر نے اصل میں لکھا کیا ہے، نہ کہ اس کے ڈائیلاگ باکس نے دعویٰ کیا کیا تھا۔ غیر ضروری امرسِو مستردیوں میں سے تقریباً ساری حوالہ جاتی سالمیت کی وہ غلطیاں ہیں جو کوئی ویلی ڈیٹر ایک سیکنڈ سے کم میں پکڑ لیتا ہے۔

Mazufa کا مفت BW64/ADM انسپکٹر 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/