امرسو آڈیو کی ڈیلیوری: کنٹینر، میٹا ڈیٹا، اور وہ فائل جسے آپ سن نہیں سکتے

ایک عملی حوالہ اُن انجینئروں کے لیے جو آبجیکٹ بیسڈ ماسٹر تیار کرتے ہیں، اور اُن موسیقاروں کے لیے جنہیں "امرسو ڈیلیوریبل" بنانے کو کہا گیا ہے حالانکہ اسٹوڈیو میں سننے کا نظام موجود ہی نہیں۔

مختصر جواب

امرسو ڈیلیوری میں دو الگ چیزیں ایک ساتھ بھیجی جاتی ہیں: آواز خود، اور ایک تحریری بیان کہ وہ آواز کیا ہے۔ آواز ایک کنٹینر میں جاتی ہے جس کا نام

BW64

ہے اور جس کی تفصیل سفارش

ITU-R BS.2088

میں درج ہے؛ بیان ایک

XML

دستاویز کی صورت میں جاتا ہے جس کا ماڈل

ADM

کہلاتا ہے اور جو سفارش

ITU-R BS.2076

میں بیان ہوا ہے۔ امرسو فائلیں کیو سی میں اس لیے رد ہوتی ہیں کہ یہ دونوں چیزیں الگ الگ بنتی ہیں، ایک دوسرے سے بالکل مطابقت رکھنا لازم ہے، اور فائل فارمیٹ میں ایسی کوئی چیز نہیں جو اس مطابقت کو خود سے نافذ کرے۔ عملی نتیجہ یہ ہے کہ امرسو کیو سی سننے کا کام نہیں، حوالوں کی جانچ کا کام ہے — اور یہی وہ کام ہے جو برصغیر کے اُس اسٹوڈیو میں بھی ٹھیک طور پر کیا جا سکتا ہے جس کے پاس بارہ اسپیکر نہیں، صرف ایک درست پارسر اور ایک چیک لسٹ ہے۔

۱۔ قوالی پارٹی: ایک ایسا جوڑ جو پہلے ہی سے آبجیکٹ بیسڈ ہے

اردو کے قاری کو آبجیکٹ بیسڈ آڈیو سمجھانے کے لیے کسی مغربی مثال کی ضرورت نہیں۔ قوالی پارٹی کی بیٹھک خود ایک آبجیکٹ بیسڈ ترتیب ہے، اور یہ ترتیب اتفاقی نہیں بلکہ سخت اور معنی خیز ہے۔

سامنے کی صف کے وسط میں مرکزی قوال بیٹھتا ہے۔ اس کے دائیں بائیں ہم آواز گانے والے، یعنی سائیڈ سنگرز۔ ان کے کناروں پر ہارمونیم بجانے والے — عام طور پر دو، ایک دائیں اور ایک بائیں — تاکہ سُر مرکزی آواز کو دونوں طرف سے سہارا دے۔ ایک جانب طبلہ اور ڈھولک، ایک ہی طرف، اس لیے کہ تال کا مرکز آواز کے مرکز سے الگ رہے۔ اور پیچھے کی صف میں ہم نوا: تالی بجانے والوں کی قطار، جو مرکزی قوال کے مصرعے کا جواب دیتی ہے۔

اب اس ترتیب کی اصل بات۔ قوالی میں مرکزی قوال اور پچھلی صف کے درمیان جو سوال جواب چلتا ہے، وہ صرف موسیقی کا سوال جواب نہیں — وہ مکانی سوال جواب ہے۔ مصرع سامنے سے آتا ہے، جواب پیچھے سے آتا ہے، اور سننے والا اس فاصلے کو سنتا ہے۔ جب "اللہ ہو" کی گردان پچھلی صف اٹھاتی ہے تو محفل میں بیٹھے شخص کے لیے وہ آواز جسمانی طور پر کہیں اور سے آتی ہے۔ اسی فاصلے سے وہ اثر پیدا ہوتا ہے جسے سامعین "چڑھنا" کہتے ہیں۔

اسٹیریو میں یہ فاصلہ باقی نہیں رہتا۔ اسٹیریو کے پاس صرف ایک محور ہے، دائیں سے بائیں؛ اس کے پاس "پیچھے" کہنے کا کوئی طریقہ نہیں۔ چنانچہ ہم نوا کی صف کو یا تو ری ورب میں پیچھے دھکیلا جاتا ہے (جو گہرائی کا دھوکہ ہے، سمت نہیں) یا کناروں پر پھیلا دیا جاتا ہے۔ دونوں صورتوں میں کال اینڈ رسپانس اپنی جہت کھو دیتا ہے۔ قوالی کو اسٹیریو میں سمیٹنا اُسی چیز کو ختم کر دیتا ہے جو زندہ قوالی کو مغلوب کن بناتی ہے۔

اسی وجہ سے قوالی امرسو ڈیلیوری کی سب سے صاف مثال ہے۔ یہ کوئی ایسا جوڑ نہیں جسے مصنوعی طور پر تین جہتوں میں پھیلانا پڑے؛ یہ پہلے ہی تین جہتوں میں بیٹھا ہوا ہے، اور آبجیکٹ بیسڈ ڈیلیوری صرف اس جیومیٹری کو ضائع ہونے سے بچاتی ہے۔

۲۔ آواز کی تین قسمیں، اور یہ فرق فارمیٹ کا فیصلہ کیوں کرتا ہے

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

چینل بیسڈ آڈیو میں ہر ٹریک ایک مقررہ لاؤڈ اسپیکر کی جگہ سے بندھا ہوتا ہے۔ اسٹیریو چینل بیسڈ ہے۔ فائیو پوائنٹ ون بھی، اور سیون پوائنٹ ون فور کا "بیڈ" بھی۔ جگہ ٹریک کی شناخت میں پکی ہو چکی ہوتی ہے: تیسرا ٹریک سینٹر اسپیکر ہے، اور ہر نظام پر سینٹر ہی رہے گا۔ سفارش

ITU-R BS.2051

اسی کو باقاعدہ بناتی ہے اور لاؤڈ اسپیکر کی ترتیبوں کو تین تہوں کی گنتی سے لکھتی ہے — اوپر، درمیان، نیچے۔ سسٹم

A

صفر جمع دو جمع صفر ہے یعنی اسٹیریو؛ سسٹم

B

صفر جمع پانچ جمع صفر یعنی فائیو پوائنٹ ون؛ سسٹم

D

چار جمع پانچ جمع صفر؛ سسٹم

J

چار جمع سات جمع صفر؛ اور سسٹم

H

نو جمع دس جمع تین، یعنی بائیس پوائنٹ دو۔ اے ڈی ایم میں چینل بیسڈ مواد کی ٹائپ ڈیفینیشن ہے

DirectSpeakers

اور اس کا ٹائپ لیبل

0001

آبجیکٹ بیسڈ آڈیو میں ایک مونو سگنل کے ساتھ ایسا میٹا ڈیٹا چلتا ہے جو وقت کے ساتھ بدلتی ہوئی جگہ بیان کرتا ہے۔ کون سے اصل اسپیکر اسے بجائیں گے، یہ فیصلہ رینڈرر کرتا ہے، اُس کمرے کی ترتیب دیکھ کر جو واقعی موجود ہے۔ ٹریک خود کسی اسپیکر کا دعویٰ نہیں کرتا۔ ٹائپ ڈیفینیشن

Objects

اور ٹائپ لیبل

0003

سین بیسڈ آڈیو، عملاً ہائر آرڈر ایمبیسونکس، پوری صوتی فضا کو کروی ہارمونکس کے اجزا کی صورت میں محفوظ کرتا ہے۔ کوئی ایک جزو خود سے کسی سمت کی نمائندگی نہیں کرتا؛ سمت اُن کے مجموعے سے پیدا ہوتی ہے۔ ٹائپ ڈیفینیشن

HOA

ٹائپ لیبل

0004

اے ڈی ایم میں دو اور اقسام بھی ہیں: میٹرکس شدہ سگنلوں کے لیے

Matrix

یعنی

0002

اور ہیڈ فون کے لیے تیار جوڑوں کے لیے

Binaural

یعنی

0005

چینل بیسڈ آڈیو فائل کو بتاتا ہے کہ اسپیکر کہاں ہیں؛ آبجیکٹ بیسڈ آڈیو اندازہ لگانے سے انکار کرتا ہے؛ اور سین بیسڈ آڈیو ذرائع کے بجائے پوری فضا بیان کرتا ہے۔

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

BW64

اور

ADM

کے وجود کی پوری وجہ ہے، اور یہی وجہ ہے کہ امرسو کیو سی اسٹیریو کیو سی سے مشکل ہے۔

۳۔ چار جی بی کی دیوار، اور حساب جو اسے حقیقی بناتا ہے

کلاسیکی ویو فائل ایک

RIFF

فائل ہے۔ اُنیس سو اکانوے کا یہ ڈھانچہ ہر چنک سے پہلے ایک بتیس بٹ کا سائز فیلڈ لکھتا ہے۔ بتیس بٹ زیادہ سے زیادہ چار ارب انتیس کروڑ ننانوے لاکھ سڑسٹھ ہزار دو سو چھیانوے بائٹ تک پہنچ سکتا ہے — یعنی

4 294 967 296

بائٹ، چار جی بی — اور یہی حد پوری فائل پر بھی لاگو ہے اور اندر کے

data

چنک پر بھی۔

اب حساب کیجیے، کیونکہ یہی حساب فیصلہ کرتا ہے کہ آپ کو نیا کنٹینر چاہیے یا نہیں۔ فی سیکنڈ بائٹ نکالنے کا طریقہ سادہ ہے: چینلوں کی تعداد ضرب سیمپل ریٹ ضرب بائٹ فی سیمپل۔

اڑتالیس کلوہرٹز، چوبیس بٹ اسٹیریو: دو ضرب اڑتالیس ہزار ضرب تین برابر دو لاکھ اٹھاسی ہزار بائٹ فی سیکنڈ۔ چار جی بی کو اس پر تقسیم کریں تو تقریباً چودہ ہزار نو سو تیرہ سیکنڈ بنتے ہیں، یعنی لگ بھگ چار گھنٹے آٹھ منٹ۔ اسٹیریو کے لیے یہ حد بے معنی ہے۔

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

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

جو رائٹر اس حد سے ٹکرا کر بھی لکھتا رہے وہ یا تو کٹی ہوئی فائل بناتا ہے یا ایسی فائل جس کے سائز فیلڈ خاموشی سے لپیٹ کھا چکے ہوں۔

پہلا حل

EBU

نے دیا:

RF64

یعنی

EBU Tech 3306

اسی کام کو آگے بڑھا کر آئی ٹی یو نے سفارش

ITU-R BS.2088

جاری کی، جس کا عنوان ہے

Long-form file format for the international exchange of audio programme materials with metadata

اور جس کا کنٹینر

BW64

کہلاتا ہے۔ طریقہ کار خود سفارش میں صاف لکھا ہے:

"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."

یعنی:

بی ڈبلیو سکسٹی فور نے رِف کے سائز فیلڈ چوڑے نہیں کیے؛ اس نے اُن میں ایک نشان بھر دیا اور اصل چونسٹھ بٹ سائز ایک الگ چنک میں رکھ دیے۔

وہ نشان ہے

0xFFFFFFFF

یعنی وہی چار ارب انتیس کروڑ ننانوے لاکھ سڑسٹھ ہزار دو سو پچانوے — بتیس بٹ کی سب سے بڑی ممکنہ قیمت۔ چونکہ کوئی حقیقی چنک اتنا بڑا ہو ہی نہیں سکتا کہ اس فیلڈ میں ٹھیک یہی قیمت جائز طور پر آئے، اس لیے یہ قیمت محفوظ نشان کے طور پر استعمال کی جا سکتی ہے۔

بی ڈبلیو سکسٹی فور کو ایک ہی سلسلے کی تیسری نسل سمجھنا سب سے آسان ہے۔ پہلی نسل

RIFF/WAVE

نے چنک والا ڈھانچہ دیا۔ دوسری نسل، براڈکاسٹ ویو یعنی

BWF

اور

EBU Tech 3285

نے

bext

چنک کا اضافہ کیا — اوریجنیٹر، ٹائم کوڈ ریفرنس، کوڈنگ ہسٹری — اور ویو کو نشریاتی تبادلے کا فارمیٹ بنا دیا۔ تیسری نسل، بی ڈبلیو سکسٹی فور، یہ سب رکھتی ہے، چونسٹھ بٹ ایڈریسنگ شامل کرتی ہے، اور وہ چنک شامل کرتی ہے جو اے ڈی ایم اٹھاتے ہیں۔ چار جی بی سے چھوٹی بی ڈبلیو سکسٹی فور فائل ایک ویو ریڈر کے لیے ہر لحاظ سے قابلِ قبول ہوتی ہے سوائے پہلے چار بائٹ کے دستخط کے؛ بہت سے ٹُول اسے قبول کر لیتے ہیں، اور کچھ ضد کے ساتھ نہیں کرتے۔

۴۔ چنک کی ساخت، بائٹ در بائٹ

سفارش

BS.2088

کے مطابق ایک بی ڈبلیو سکسٹی فور فائل میں کم از کم یہ ہونے چاہئیں: ڈی ایس سکسٹی فور، ایف ایم ٹی، سی ایچ این اے، اے ایکس ایم ایل (جس کے متبادل کے طور پر بی ایکس ایم ایل اور ایس ایکس ایم ایل بھی ہو سکتے ہیں) اور ویو ڈیٹا۔

ڈی ایس سکسٹی فور — چونسٹھ بٹ سائز کی میز

یہ چنک، یعنی

ds64

دستخط کے فوراً بعد پہلا چنک ہونا لازم ہے، کیونکہ ریڈر کو باقی فائل چلنے سے پہلے اصل سائز معلوم ہونے چاہئیں۔ اس کے فیلڈ چونسٹھ بٹ مقداروں کے بتیس بٹ نصف حصوں کی صورت میں ہوتے ہیں:

حساب سیدھا ہے۔ اگر میز خالی ہو تو ادائیگی (یعنی وہ حصہ جو

ckSize

گنتا ہے) چار جمع چار جمع چار جمع چار جمع چار جمع چار جمع چار برابر اٹھائیس بائٹ ہے، اور پورا چنک ہیڈر کے آٹھ بائٹ ملا کر چھتیس بائٹ۔ ہر اضافی اندراج آٹھ بائٹ کے چونسٹھ بٹ سائز کے ساتھ اپنا چار بائٹ کا چنک شناخت کنندہ لاتا ہے، یعنی بارہ بائٹ فی اندراج۔

میز والا حصہ ظاہری اہمیت سے زیادہ اہم ہے۔ ایک ایسا

axml

چنک جو ہزاروں آبجیکٹ کی سیمپل کی سطح پر آٹومیشن بیان کرے، خود چار جی بی کے قریب یا اس سے آگے جا سکتا ہے؛ میز ہی وہ راستہ ہے جس سے ڈیٹا کے علاوہ کوئی بھی چنک اپنا چونسٹھ بٹ سائز بیان کر سکتا ہے۔

ایف ایم ٹی — جوہر کا بیان

یہ معمول کا ویو فارمیٹ چنک ہے، یعنی

fmt

(آخر میں خالی جگہ سمیت چار حروف): سیمپل فارمیٹ، سیمپل ریٹ، چینلوں کی تعداد، بٹ ڈیپتھ، بلاک الائن۔ یہی واحد مستند بیان ہے کہ ڈیٹا میں اصل میں کتنے انٹرلیوڈ چینل موجود ہیں۔ اس کے بعد کی ہر چیز اُن چینلوں کے بارے میں میٹا ڈیٹا ہے، اور میٹا ڈیٹا جھوٹ بول سکتا ہے۔

سی ایچ این اے — چالیس بائٹ فی اندراج

یہ چنک، یعنی

chna

جسمانی ٹریکوں اور اے ڈی ایم کے درمیان پُل ہے۔ اس کا آغاز یوں ہوتا ہے:

اس کے بعد مقررہ چوڑائی والے اندراجات کی سادہ قطار۔ ہر اندراج ٹھیک چالیس بائٹ کا ہے:

دو جمع بارہ جمع چودہ جمع گیارہ جمع ایک برابر چالیس۔ یہ چوڑائیاں مشورہ نہیں، پابندی ہیں: یہ مقررہ چوڑائی کے ایسکی حروف ہیں، اور جو رائٹر تیرہ حروف کا یو آئی ڈی لکھ دے اُس نے "کچھ غیر معمولی" نہیں بلکہ خراب میز لکھی ہے۔

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

numTracks

اور دو بائٹ

numUIDs

بھی شامل ہیں، یعنی نو سو چونسٹھ بائٹ۔ ہیڈر کے آٹھ بائٹ ملا کر پورا چنک نو سو بہتر بائٹ۔ چونکہ نو سو چونسٹھ پہلے ہی جفت ہے، اس لیے چنک کے آخر میں اضافی پیڈنگ کی ضرورت نہیں۔

ایک سو اٹھائیس ٹریک والے ماسٹر کے لیے وہی حساب: ایک سو اٹھائیس ضرب چالیس برابر پانچ ہزار ایک سو بیس، جمع چار برابر پانچ ہزار ایک سو چوبیس بائٹ ادائیگی، اور پورا چنک پانچ ہزار ایک سو بتیس بائٹ۔ اگر آپ کے پارسر کو یہ عدد نہ ملے تو یا تو اندراج چالیس بائٹ کا نہیں، یا اعلان کردہ تعداد غلط ہے۔ دونوں صورتوں میں فائل خراب ہے۔

شناخت کنندوں کے بارے میں ایک اہم اصول: قیمتیں

0x0FFF

اور اس سے نیچے اے ڈی ایم کی مشترکہ تعریفوں کی طرف اشارہ کرتی ہیں، یعنی وہ معیاری چینل اور پیک فارمیٹ جو پہلے سے طے شدہ ہیں؛ جبکہ

0x1000

اور اس سے اوپر کی قیمتیں اپنی مرضی کی تعریفیں ہیں جن کا

axml

میں موجود ہونا لازم ہے۔ چنانچہ

AP_00010003

مشترکہ تعریف کے مطابق فائیو پوائنٹ ون ہے اور اسے کسی ایکس ایم ایل کی ضرورت نہیں؛ جبکہ

AP_00031001

ایک اپنی مرضی کا آبجیکٹ پیک ہے، اور ایکس ایم ایل موجود نہ ہو تو یہ حوالہ لٹکا رہ جاتا ہے۔

ٹریک یو آئی ڈی فائل کے اندر ایک جسمانی ٹریک کی شناخت کا سیریل نمبر ہے، اور اس کا وجود اسی لیے ہے کہ ایک ٹریک پروگرام کے دوران جائز طور پر اپنا مواد بدل سکے۔

اسی سے سمجھ آتا ہے کہ

numUIDs

کیوں

numTracks

سے زیادہ ہو سکتا ہے۔ ای بی یو کی رہنمائی صاف کہتی ہے کہ جہاں ایک ٹریک کے اجزا فائل کے دوران مختلف طور پر بیان کیے جائیں، وہاں ہر تعریف کا اپنا الگ شناخت کنندہ ہوگا:

"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."

چنانچہ ایک ہی ٹریک انڈیکس کئی اندراجات میں آ سکتا ہے۔ جو کیو سی ٹُول یہ فرض کر لے کہ ہر ٹریک کا صرف ایک یو آئی ڈی ہوگا، وہ درست فائلوں کو خراب قرار دے گا۔

یہ فرق قوالی میں تصوراتی نہیں۔ ایک ہی مائیک اور ایک ہی ٹریک پہلے حصے میں ایک ہم نوا کی تالی اٹھا سکتا ہے اور بعد میں، جب وہی شخص آگے بڑھ کر گرہ لگاتا ہے، ایک الگ آبجیکٹ کے طور پر بیان ہو سکتا ہے۔ دو تعریفیں، دو یو آئی ڈی، ایک ٹریک انڈیکس۔

اے ایکس ایم ایل — خود اے ڈی ایم

ایک

XML

دستاویز، یو ٹی ایف ایٹ میں، جس میں

audioFormatExtended

نامی درخت ہوتا ہے۔ یہی اے ڈی ایم ہے۔ یہ متن ہے، پڑھا جا سکتا ہے، اور تقریباً تمام دلچسپ ناکامیاں یہیں رہتی ہیں۔

ڈیٹا — انٹرلیوڈ پی سی ایم

سادہ انٹرلیوڈ سیمپل، بالکل ویو کی طرح۔ ڈیٹا کے اندر کوئی چیز آبجیکٹ کے بارے میں کچھ نہیں جانتی۔

ترتیب

ڈی ایس سکسٹی فور ہمیشہ پہلے۔ ایف ایم ٹی ڈیٹا سے پہلے۔ لیکن اے ایکس ایم ایل جائز طور پر ڈیٹا کے بعد بھی آ سکتا ہے، اور اکثر آتا ہے، کیونکہ جیسا کہ

BS.2088

کہتی ہے، ریکارڈنگ کے دوران

"the XML metadata will likely be of an unknown length."

جس فائل کا اے ایکس ایم ایل آخر میں ہو وہ خراب نہیں؛ مگر جو ریڈر صرف پہلا میگابائٹ اسکین کرے وہ کہے گا کہ فائل میں اے ڈی ایم ہے ہی نہیں۔ "میری فائل میں میٹا ڈیٹا نہیں آ رہا" کی شکایتوں کا ایک بڑا حصہ صرف یہی ہے۔

۵۔ اے ڈی ایم کا ماڈل

سفارش

BS.2076

ماڈل کو دو حصوں میں بانٹتی ہے۔ فارمیٹ والا حصہ

"describes the technical nature of the audio so it can be decoded or rendered correctly"

اور یہ آڈیو کے وجود میں آنے سے پہلے بھی لکھا جا سکتا ہے۔ کنٹینٹ والا حصہ

"the language of dialogue, the loudness, etc."

بیان کرتا ہے اور صرف اُس وقت مکمل ہو سکتا ہے جب سگنل موجود ہوں۔ کوئی خرابی کس حصے میں ہے، اسی سے پتا چلتا ہے کہ وہ پروڈکشن کے کس مرحلے میں داخل ہوئی۔

اوپر سے نیچے کا درجہ:

audioProgramme

ایک مکمل پیشکش۔ ایک یا زیادہ کنٹینٹ کا حوالہ دیتا ہے۔

audioContent

ادارتی معنی رکھنے والا جزو: مکالمہ، موسیقی، یا کوئی زبان کا ورژن۔

audioObject

ادارتی ارادے اور تکنیکی فارمیٹ کا جوڑ۔ آغاز کا وقت اور دورانیہ رکھتا ہے، اور پیک فارمیٹ، دوسرے آبجیکٹ اور ٹریک یو آئی ڈی کے حوالے دیتا ہے۔ یہیں مواد اور جوہر ملتے ہیں۔

audioPackFormat

وہ چینل جو ایک ساتھ چلتے ہیں: ایک سیون پوائنٹ ون فور بیڈ، ایک اسٹیریو جوڑا، کسی درجے کا ایمبیسونک سیٹ۔

audioChannelFormat

ایک چینل کا وقت کے ساتھ رویہ۔

audioBlockFormat

سب سے چھوٹا جزو۔ آبجیکٹ کے لیے: جگہ (ایزیمتھ، ایلیویشن، ڈسٹینس یا کارٹیزین ایکس، وائی، زیڈ)، گین، سائز، ڈفیوزنیس، اور آغاز کا وقت یعنی

rtime

اور دورانیہ یعنی

duration

ساکن آبجیکٹ ایک بلاک ہے؛ چلتا ہوا آبجیکٹ بلاکوں کا سلسلہ۔

audioTrackUID

پتّا، اور واحد عنصر جو کسی جسمانی ٹریک سے مطابقت رکھتا ہے۔

درمیان میں

audioStreamFormat

اور

audioTrackFormat

بھی آتے ہیں۔ سفارش کا تیسرا ایڈیشن کہتا ہے کہ پی سی ایم کے لیے یہ عملاً غیر ضروری ہیں —

"the audioStreamFormat and the audioTrackFormat should be omitted"

— مگر ریڈر کو یہ بھی معلوم ہونا چاہیے کہ پرانی فائلوں میں

"existing ADM files (based on Recommendation ITU-R BS.2076-2 and earlier) for PCM audio may contain"

یہ عناصر موجود ہو سکتے ہیں۔ دونوں شکلیں جائز ہیں۔ جو ویلیڈیٹر صرف ایک شکل پر اصرار کرے وہ دوسری کے بارے میں غلط ہے۔

اے ڈی ایم ایک نیسٹڈ دستاویز نہیں، حوالوں کا گراف ہے — اور ڈیلیوری کی ہر سنجیدہ ناکامی اس گراف کا ٹوٹا ہوا کنارہ ہے۔

جب کوئی حوالہ لٹکا ہوا رہ جائے تو نتیجہ ایک نہیں ہوتا، اور یہی اصل مسئلہ ہے۔ رینڈرر پارس روک کر فائل رد کر سکتا ہے؛ یا اُس آبجیکٹ کو چھوڑ کر باقی سب رینڈر کر سکتا ہے، جس سے ایک مکس بنتا ہے جس میں سے ایک پورا حصہ خاموشی سے غائب ہے؛ یا مشترکہ تعریفوں میں تلاش کر کے، اپنی مرضی والی حد کا شناخت کنندہ نہ پا کر، اس کی جگہ سکوت رکھ سکتا ہے۔ تینوں صورتوں میں "فائل کھل گئی"۔ صرف ایک صورت کان سے پکڑی جا سکتی ہے، اور وہ بھی تب جب آپ کو پہلے سے معلوم ہو کہ وہاں کیا ہونا چاہیے تھا۔ کان اُس غیر حاضری کو نہیں سن سکتا جس کی اسے خبر ہی نہ دی گئی ہو — یہی وجہ ہے کہ اے ڈی ایم کیو سی خودکار ہونا چاہیے۔

۶۔ قوالی پارٹی کو اے ڈی ایم میں لکھنا

اب اصل کام۔ فرض کیجیے ایک محفل کی ملٹی ٹریک ریکارڈنگ ہے اور آپ اسے آبجیکٹ بیسڈ ماسٹر کے طور پر تیار کر رہے ہیں۔

مرکزی قوال ایک آبجیکٹ ہے، سامنے، ایزیمتھ صفر پر۔ دائیں اور بائیں سائیڈ سنگرز الگ آبجیکٹ، تقریباً پندرہ سے پچیس درجے کے فاصلے پر۔ دو ہارمونیم دو آبجیکٹ، ان سے کچھ باہر۔ طبلہ اور ڈھولک ایک ہی طرف، مگر الگ الگ آبجیکٹ — یہ اہم ہے، کیونکہ ان دونوں کی تال اکثر ایک دوسرے کے خلاف چلتی ہے اور اگر انہیں ایک پیک میں باندھ دیا جائے تو یہ کشمکش سنائی نہیں دیتی۔ اور ہم نوا کی صف: تالی بجانے والوں کے لیے یا تو کئی الگ آبجیکٹ، یا ایک آبجیکٹ جس کا

size

پیرامیٹر بڑا رکھا جائے تاکہ وہ ایک نقطہ نہیں بلکہ ایک چوڑی قطار محسوس ہو۔

یہاں ایک عام غلطی کی نشان دہی ضروری ہے۔ بہت سے انجینئر پوری پارٹی کو ایک "بیڈ" میں ڈال کر اوپر ایک دو سولو آبجیکٹ رکھ دیتے ہیں۔ نتیجہ یہ نکلتا ہے کہ سوال جواب کا وہی مکانی رشتہ ختم ہو جاتا ہے، کیونکہ بیڈ اسپیکر کی جگہوں سے بندھا ہوتا ہے اور اُس رینڈرنگ میں جس میں پیچھے کے اسپیکر کم ہوں، پوری پچھلی صف سامنے آ گرتی ہے۔ جس چیز کا جواب دینا ضروری ہے اسے آبجیکٹ بنائیے؛ جو چیز صرف ماحول ہے اسے بیڈ میں رکھیے۔

اور ماحول یہاں سنجیدہ چیز ہے۔ درگاہ کے صحن اور محفل خانے کی صوتیات بالکل مختلف ہیں، اور یہ فرق امرسو میں پہلی بار قابلِ ریکارڈ ہوتا ہے۔

درگاہ کا صحن کھلا ہوتا ہے۔ اوپر آسمان ہے، اس لیے چھت سے آنے والی ابتدائی عکاسی تقریباً موجود نہیں؛ آواز اوپر جا کر واپس نہیں آتی۔ جو ری ورب سنائی دیتا ہے وہ پتھر کی دیواروں، ستونوں اور فرش سے افقی طور پر آتا ہے، اور اکثر دیر سے اور کھلا ہوا۔ سامعین چاروں طرف بیٹھے ہوتے ہیں، اس لیے تالیاں، نعرے اور نذرانے کی حرکت بھی چاروں طرف سے آتی ہے۔ ہائٹ چینل یہاں کمرے کی عکاسی نہیں اٹھاتے — وہ کھلی فضا اور مجمع کی بلندی اٹھاتے ہیں۔ اگر آپ درگاہ کے صحن کو ایسے ہائٹ چینلوں کے ساتھ رینڈر کریں جو مصنوعی چھت کی عکاسی سے بھرے ہوں تو جگہ فوراً جھوٹی لگتی ہے۔

محفل خانہ اس کے الٹ ہے: بند، نسبتاً نیچی چھت، قالین، اور سامعین قریب۔ یہاں ابتدائی عکاسی گھنی اور جلد آتی ہے، اور ہائٹ چینل واقعی چھت کا کام کرتے ہیں۔ ایک ہی قوالی پارٹی، ایک ہی ترتیب، مگر دو بالکل مختلف امرسو تصویریں — اور آبجیکٹ بیسڈ ڈیلیوری میں یہ فرق ماحول کے بیڈ میں محفوظ ہوتا ہے جبکہ ذرائع کی جیومیٹری آبجیکٹ میں محفوظ رہتی ہے۔ یہی وہ تقسیم ہے جو اسٹیریو کر ہی نہیں سکتا۔

۷۔ غزل کی ریکارڈنگ: سارنگی اور طبلہ الگ ذرائع کے طور پر

قوالی کے مقابلے میں غزل کی ریکارڈنگ چھوٹی ہے، اور اسی لیے زیادہ نازک۔

غزل میں آواز اور سارنگی کے درمیان جو جواب داری ہے وہ قوالی کی صف بندی جتنی نمایاں نہیں مگر اتنی ہی حقیقی ہے: گلوکار ایک مصرع پورا کرتا ہے، سارنگی اسی مصرعے کا سایہ بجاتی ہے۔ اسٹیریو میں یہ سایہ عام طور پر ایک طرف پین کر دیا جاتا ہے، اور جیسے ہی سامع ہیڈ فون کے بجائے اسپیکر پر سنتا ہے، وہ فاصلہ کمرے میں گھل جاتا ہے۔

آبجیکٹ بیسڈ ماسٹر میں سارنگی ایک الگ آبجیکٹ ہے جس کی جگہ طے شدہ ہے اور رینڈرنگ کے ساتھ بدلتی نہیں۔ طبلہ ایک اور آبجیکٹ، دوسری طرف، اپنی جگہ پر۔ ہارمونیم، اگر ہو، تیسرا۔ تین ذرائع، تین آبجیکٹ، اور آواز مرکز میں۔ چار ٹریک، چار

audioObject

اور ایک چھوٹا سا محیطی بیڈ۔ یہ پوری فائل شاید بیس آبجیکٹ والی قوالی سے کہیں سادہ ہے، مگر اس کی

chna

میز کا حساب بالکل وہی ہے: پانچ اندراجات ضرب چالیس برابر دو سو بائٹ، جمع چار برابر دو سو چار بائٹ ادائیگی، جمع آٹھ بائٹ ہیڈر برابر دو سو بارہ بائٹ کا چنک۔

ایک عملی تنبیہ: طبلہ کے ٹرانزینٹ بہت تیز ہیں، اور جب کسی آبجیکٹ کو ایسی ترتیب پر رینڈر کیا جائے جس میں اُس سمت کا کوئی اسپیکر موجود نہ ہو، تو رینڈرر اسے دو یا زیادہ اسپیکروں کے درمیان تقسیم کرتا ہے۔ اس تقسیم سے ٹرانزینٹ کی وضاحت کم ہو سکتی ہے۔ اسی لیے طبلہ اور ڈھولک کو ایسی جگہ رکھنا بہتر ہے جو ہدف ترتیبوں میں کسی اصل اسپیکر کے قریب پڑے، نہ کہ ٹھیک دو اسپیکروں کے بیچ میں۔

۸۔ رینڈرنگ: ایک فائل، کئی جواب

آبجیکٹ بیسڈ فائل خود کوئی مکس نہیں۔ وہ ایک نسخہ ہے۔ مکس اُس وقت وجود میں آتا ہے جب رینڈرر اُس نسخے کو ایک مخصوص لاؤڈ اسپیکر ترتیب پر لاگو کرتا ہے۔

اس کام کا معیاری بیان سفارش

ITU-R BS.2127

میں ہے، جو اے ڈی ایم کا حوالہ جاتی رینڈرر متعین کرتی ہے، اور ہدف ترتیبیں وہی ہیں جو

BS.2051

میں بیان ہوئیں۔ اس کا کھلا ذریعہ عملی نفاذ ای بی یو کا

EBU ADM Renderer

ہے، جس کی دستاویز

EBU Tech 3388

ہے۔ ایک ہی فائل کو سسٹم

B

پر رینڈر کیجیے تو پانچ چینل نکلیں گے؛ سسٹم

J

پر گیارہ جمع ایک؛ سسٹم

H

پر بائیس جمع دو۔ ہر بار وہی آبجیکٹ، ہر بار مختلف نتیجہ۔

قوالی کی مثال میں یہ فرق فوراً سنائی دیتا ہے۔ سسٹم

J

پر ہم نوا کی صف واقعی پیچھے رہتی ہے اور سوال جواب کا فاصلہ برقرار رہتا ہے۔ سسٹم

B

پر پیچھے صرف دو سراؤنڈ اسپیکر ہیں؛ صف سکڑ جاتی ہے مگر پھر بھی پیچھے ہی رہتی ہے۔ سسٹم

A

یعنی اسٹیریو پر وہ سامنے آ جاتی ہے اور مکانی جواب ختم ہو جاتا ہے۔ یہی وجہ ہے کہ اسٹیریو کنفارم کو "کم اہم ڈیلیوریبل" سمجھنا غلطی ہے: وہ ایک الگ فنی فیصلہ ہے، خودکار نتیجہ نہیں۔

اسی لیے مکس کے مرحلے میں ایک سے زیادہ ترتیبوں پر جانچنا اصولی طور پر ضروری ہے۔ اگلے حصے میں یہ بات ہوگی کہ جب اسٹوڈیو میں وہ ترتیبیں موجود ہی نہ ہوں تو کیا کیا جا سکتا ہے۔

۹۔ امرسو لاؤڈنیس: کیا شائع شدہ ہے اور کیا نہیں

یہاں شائع شدہ اور گردش کرتی ہوئی معلومات کو الگ رکھنا لازم ہے۔

سفارش کیا کہتی ہے۔ لاؤڈنیس کی پیمائش کا معیار

ITU-R BS.1770

ہے۔ اس کے چھ ایڈیشن ہیں: صفر (۲۰۰۶)، ایک (۲۰۰۷)، دو (۲۰۱۱)، تین (۲۰۱۲)، چار (۲۰۱۵) اور پانچ (نومبر ۲۰۲۳)۔ آج نافذ ایڈیشن پانچواں ہے، یعنی

BS.1770-5

جبکہ چوتھا ایڈیشن، یعنی

BS.1770-4

اکتوبر ۲۰۱۵ کا، منسوخ ہو چکا ہے — اگرچہ زیادہ تر تعینات میٹر آج بھی اسی کا حوالہ لکھتے ہیں۔ اپنی ڈیلیوری نوٹس میں ہمیشہ پانچویں ایڈیشن کا نام لکھیے۔

میکانکس یہ ہے۔ کے ویٹنگ دو مرحلوں کا فلٹر ہے: پہلے ایک ہائی شیلف، جسے "ہیڈ" فلٹر کہتے ہیں اور جو ایک سخت کرے کی نقل کرتا ہے، پھر ایک ہائی پاس جسے

RLB

کہا جاتا ہے۔ ایک کلوہرٹز پر اس منحنی خط کا گین جمع صفر اعشاریہ چھ نو آٹھ ڈیسی بل ہے، یعنی لکیری پیمانے پر ایک اعشاریہ صفر آٹھ تین چھ۔ پیمائش چار سو ملی سیکنڈ کے بلاکوں پر ہوتی ہے جن کا اوورلیپ پچھتر فیصد ہے۔ ایک مطلق گیٹ ہے جو منفی ستّر لاؤڈنیس یونٹ سے نیچے کے بلاک پھینک دیتا ہے۔ اور ایک نسبتی گیٹ ہے جو اُن بلاکوں کے اوسط سے نکالا جاتا ہے جو مطلق گیٹ سے بچ گئے، اور پھر اس اوسط سے دس لاؤڈنیس یونٹ نیچے رکھا جاتا ہے۔ یہ بغیر گیٹ والا اوسط نہیں ہے — یہ فرق نفاذ میں اتنی بار غلط ہوتا ہے کہ اسے صاف لکھنا ضروری ہے۔

بنیادی الگورتھم میں چینل کا وزن بائیں، دائیں اور مرکزی چینل کے لیے ایک اعشاریہ صفر (یعنی صفر ڈیسی بل) ہے اور بائیں و دائیں سراؤنڈ کے لیے ایک اعشاریہ چار ایک (تقریباً جمع ڈیڑھ ڈیسی بل)؛ ایل ایف ای شامل نہیں کیا جاتا۔ بنیادی الگورتھم کا دائرہ "ایک سے پانچ چینل" تک ہے۔ پانچواں ایڈیشن اپنے ضمیموں میں اس سے آگے جاتا ہے اور

BS.2051

کے جدید نظاموں کو شامل کرتا ہے — یعنی من مانی جگہوں پر رکھے اسپیکر اور ہائٹ چینل — اور آبجیکٹ بیسڈ آڈیو کو بھی، جسے ناپنے سے پہلے رینڈر کرنا لازم ہے۔

امرسو لاؤڈنیس فائل کی خصوصیت نہیں، ایک رینڈر کی خصوصیت ہے؛ ہدف ترتیب بدلیے، ہندسہ بدل جائے گا۔

اسٹیریو ماسٹر کی ایک لاؤڈنیس ہوتی ہے۔ آبجیکٹ بیسڈ ماسٹر کی اتنی ہوتی ہیں جتنے اس کے رینڈر ہدف۔ اس لیے دیانت دار طریقہ یہ ہے کہ ہندسے کے ساتھ تین چیزیں ہمیشہ لکھی جائیں: کون سی ترتیب، کون سا رینڈرر، اور کون سا میٹر ایڈیشن۔

متعلقہ ای بی یو دستاویزات۔ میٹر کا رویہ

EBU Tech 3341

میں ہے: مومنٹری چار سو ملی سیکنڈ، شارٹ ٹرم تین سیکنڈ۔ لاؤڈنیس رینج

EBU Tech 3342

میں ہے اور یہ منفی بیس لاؤڈنیس یونٹ کا نسبتی گیٹ استعمال کرتی ہے، منفی دس کا نہیں؛ لاؤڈنیس رینج کے لیے منفی دس استعمال کرنا ایک عام نفاذی خرابی ہے۔ نشریات کا ہدف

EBU R 128

میں منفی تئیس لاؤڈنیس یونٹ ہے — یہ نشریاتی معمول ہے، موسیقی کی اسٹریمنگ کا معیار نہیں۔

ٹرو پیک کے بارے میں: یہ اوورسیمپلڈ سگنل پر ناپا جاتا ہے، کم از کم چار گنا، اور آٹھ گنا بہتر ہے۔ سیمپل پیک ٹرو پیک نہیں ہوتا، اور انٹر سیمپل پیک بلند ترین سیمپل سے اوپر جا سکتے ہیں۔

موسیقی کے لیے کیا شائع شدہ ہے۔ اسٹیریو کے لیے اسپاٹی فائی انٹیگریٹڈ ہدف منفی چودہ لاؤڈنیس یونٹ اور ٹرو پیک کی چھت منفی ایک ڈیسی بل شائع کرتا ہے، اور اگر ماسٹر منفی چودہ سے اونچا ہو تو منفی دو۔

AES TD1008

موسیقی کے لیے منفی سولہ کی سفارش کرتا ہے؛ اسی دستاویز کا منفی اٹھارہ کا ہندسہ تقریر پر مبنی مواد کے لیے ہے، اور اسے موسیقی کا ہدف بتانا ایک عام اور سنگین غلطی ہے۔

کیا شائع شدہ نہیں۔ کوئی بھی میوزک اسٹریمنگ سروس امرسو ڈیلیوری کے لیے انٹیگریٹڈ لاؤڈنیس کا ہدف شائع نہیں کرتی۔ فورموں اور تربیتی مواد میں ہندسے گردش کرتے ہیں، کچھ قرینِ قیاس ہیں اور کچھ شاید درست بھی، مگر ان میں سے کوئی شائع شدہ ضابطہ نہیں، اور یہ دستاویز ان میں سے کسی کو ضابطہ بنا کر نہیں دہرائے گی۔

اسی طرح ایپل میوزک، یوٹیوب میوزک، ایمیزون میوزک، ٹائیڈل اور ڈیزر اسٹیریو کے لیے بھی کوئی نارملائزیشن ہدف شائع نہیں کرتیں۔ عام طور پر جو ہندسے بتائے جاتے ہیں (ایپل تقریباً منفی سولہ، یوٹیوب میوزک تقریباً منفی چودہ، ایمیزون تقریباً منفی چودہ، ٹائیڈل تقریباً منفی چودہ، ڈیزر تقریباً منفی پندرہ) صرف اس لیبل کے ساتھ ذکر کیے جا سکتے ہیں: "وسیع پیمانے پر رپورٹ شدہ، مگر سروس کی طرف سے شائع شدہ نہیں"۔ ان سے کوئی گین کا حساب نہ نکالیے۔

اگر آج آپ کو ایک قابلِ دفاع امرسو لاؤڈنیس ہندسہ چاہیے تو طریقہ یہ ہے: ایک

BS.2127

کے مطابق رینڈر کیجیے، کسی نامزد

BS.2051

ترتیب پر، اور اسے

BS.1770-5

میٹر سے ناپیے — اور تینوں باتیں ڈیلیوری نوٹس میں لکھ دیجیے۔

ملکیتی نظاموں کے بارے میں۔ ڈولبی ایٹموس ڈولبی لیبارٹریز کی ملکیتی اور لائسنس یافتہ ٹیکنالوجی ہے، اور سونی کا تین سو ساٹھ رئیلٹی آڈیو ایک ملکیتی نظام ہے جو ایم پی ای جی ایچ پر بنا ہے۔ ان کی ڈیلیوری کی شرائط ان کے مالکان طے کرتے ہیں اور آئی ٹی یو یا ای بی یو کے شیڈول سے بے نیاز بدلتی ہیں۔ اس دستاویز میں کوئی بات ان کمپنیوں کی شرائط کا بیان نہیں، اور کسی وابستگی، سند یا توثیق کا دعویٰ نہیں کیا جا رہا۔ جہاں لائسنس دہندہ خود کوئی شرط شائع کرے، وہیں سے پڑھیے اور اسی کا حوالہ دیجیے۔

۱۰۔ عام ناکامیاں اور ان کی پکڑ

۱۰.۱ ایف ایم ٹی اور سی ایچ این اے میں چینلوں کی تعداد کا اختلاف

ایف ایم ٹی کہتا ہے سولہ، سی ایچ این اے کہتا ہے چودہ۔ فائل پہلے دو چنک سے ہی اپنے آپ سے متصادم ہے۔ عام سبب: باؤنس کے بعد ٹریک بدل گئے مگر میٹا ڈیٹا دوبارہ نہیں لکھا گیا۔

پکڑ: دونوں چنک پارس کر کے اعداد کا موازنہ۔ یہ پوری پائپ لائن کی سب سے سستی جانچ ہے اور حیرت انگیز تعداد میں ناکامیاں پکڑتی ہے۔ ساتھ ہی یہ بھی دیکھیے کہ ہر ٹریک انڈیکس ایک اور کل چینلوں کی تعداد کے درمیان ہے۔

۱۰.۲ لاوارث ٹریک یو آئی ڈی

سی ایچ این اے میں موجود ایسا یو آئی ڈی جس کا حوالہ کوئی آبجیکٹ نہ دے؛ یا ایکس ایم ایل میں ایسا حوالہ جس کا سی ایچ این اے میں کوئی اندراج نہ ہو۔ پہلی صورت میں آڈیو موجود ہے جسے کوئی رینڈر نہیں کرے گا؛ دوسری میں میٹا ڈیٹا ایک ایسے ٹریک کا انتظار کر رہا ہے جو ہے ہی نہیں۔

پکڑ: دونوں مجموعوں کا متناسب فرق نکالیے؛ خالی ہونا چاہیے۔

EBU Tech 3392

ارادہ صاف کرتی ہے:

"If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

۱۰.۳ بلاک کی ٹائمنگ غائب یا الٹی

سفارش دو ٹوک ہے:

"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

سے شروع ہو، کوئی بلاک ایک سیمپل سے چھوٹا نہ ہو، اور دورانیوں کا مجموعہ والد آبجیکٹ کے دورانیے سے میل کھائے۔

پکڑ: ہر چینل فارمیٹ کے بلاک ترتیب سے چل کر جانچیے کہ ایک بلاک کا آغاز جمع دورانیہ اگلے بلاک کے آغاز کے برابر ہے۔ ناکامیاں تین شکلوں میں آتی ہیں: خلا (رینڈرر کا رویہ غیر متعین — کوئی آخری جگہ پکڑے رکھتا ہے، کوئی خاموش کر دیتا ہے)، تداخل (بلاک آپس میں لڑتے ہیں)، اور ترتیب سے باہر بلاک (آٹومیشن جو درمیان میں پیچھے کود جائے)۔

۱۰.۴ سیمپل ریٹ یا بٹ ڈیپتھ کا تضاد

ٹریک یو آئی ڈی

sampleRate

اور

bitDepth

بھی رکھ سکتا ہے۔ جب یہ ایف ایم ٹی سے متصادم ہوں تو ایک ہی جوہر کے بارے میں دو دعوے موجود ہیں۔ ای بی یو کا موقف یہ ہے کہ جہاں یہ معلومات خود آڈیو سے دستیاب ہوں وہاں ان صفات کو نظر انداز کر دینا چاہیے:

"Should be ignored if available from the audio essence"

مگر ہر رینڈرر اس پر عمل نہیں کرتا۔ الگ سے یہ بھی دیکھیے کہ ریٹ وہی ہے جو ڈیلیوری کی شرط ہے: اے ڈی ایم لکھنے کے بعد سیمپل ریٹ بدلنا ہر وہ ٹائمنگ باطل کر دیتا ہے جو سیمپل میں لکھی گئی تھی۔

۱۰.۵ کنفارم کا بہک جانا

زیادہ تر امرسو ڈیلیوری میں امرسو ماسٹر کے ساتھ ایک اسٹیریو، اور اکثر ایک بائنارل، کنفارم بھی مانگا جاتا ہے۔ بار بار ہونے والی خرابی غیر حاضری نہیں — وہ تو ظاہر ہے — بلکہ بہکاؤ ہے: کنفارم کسی پرانے ورژن سے بنا، یا چند فریم آگے پیچھے ہے، یا اس کا ابتدائی ٹائم کوڈ مختلف ہے۔ چالیس ملی سیکنڈ آگے کھسکی ہوئی اسٹیریو فائل "فائل موجود ہے" والی جانچ پاس کر جائے گی اور ہم وقت سماعت میں ناکام ہو جائے گی۔

پکڑ: دورانیے سیمپل کی سطح پر ملائیے،

bext

کا ابتدائی ٹائم کوڈ ملائیے، اور کنفارم کو ماسٹر کے نل رینڈر کے خلاف کراس کوریلیٹ کیجیے۔ جو کنفارم موجودہ ماسٹر سے دوبارہ نہ نکالا جا سکے، اسے دوبارہ جانچنے کے بجائے دوبارہ رینڈر کیجیے۔

۱۰.۶ ایسا بیڈ جو ایکس ایم ایل میں ہے، فائل میں نہیں

ایکس ایم ایل ایک سیون پوائنٹ ون فور بیڈ کا اعلان کرتا ہے — بارہ چینل — مگر پرنٹ صرف فائیو پوائنٹ ون کا ہوا، یا ہائٹ چینل باؤنس کے وقت میوٹ تھے اور ڈجیٹل سیاہی کے طور پر لکھے گئے۔ حوالوں کا گراف بالکل درست ہے؛ آڈیو نہیں۔

پکڑ: ساختی جانچ یہاں بے کار ہے۔ جوہر کی جانچ چاہیے: ہر اعلان شدہ بیڈ چینل میں سگنل کی موجودگی ناپیے۔ اعلان شدہ چینل پر ڈجیٹل سیاہی لازماً خرابی نہیں — ایک جائز مکس کسی ٹاپ ریئر چینل کو خالی چھوڑ سکتا ہے — مگر یہ ہمیشہ انسانی فیصلے کے لائق ہے۔

کنٹینر بالکل جائز ہو سکتا ہے، ایکس ایم ایل بالکل درست، اور ڈیلیوریبل پھر بھی غلط؛ خالی بیڈ چینل کی واحد جانچ سیمپل دیکھنا ہے۔

مازوفا کا ایک مفت براؤزر بیسڈ انسپکٹر کنٹینر اور میٹا ڈیٹا دونوں کو مکمل طور پر آپ ہی کے آلے پر پارس کرتا ہے اور کچھ اپ لوڈ نہیں کرتا، جو اُس مواد کے لیے کارآمد ہے جو معاہدے کی رُو سے عمارت سے باہر نہیں جا سکتا۔

۱۱۔ ایماندار بات: جب اسٹوڈیو میں امرسو مانیٹرنگ ہے ہی نہیں

یہاں صاف بات کرنا ضروری ہے، کیونکہ اکثر تحریریں یہ فرض کر کے لکھی جاتی ہیں کہ قاری کے کمرے میں بارہ کیلبریٹڈ اسپیکر لگے ہیں۔ پاکستان اور بھارت کے بیشتر اسٹوڈیو میں امرسو مانیٹرنگ موجود نہیں۔ لاہور، کراچی، ممبئی یا چنئی کے چند سہولت یافتہ کمروں کے علاوہ، زیادہ تر کام اسٹیریو نیئر فیلڈ اور ہیڈ فون پر ہوتا ہے۔ یہ کوئی عیب نہیں جسے چھپایا جائے؛ یہ وہ حالت ہے جس میں کام کرنا ہے۔

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

جو کچھ بغیر امرسو کمرے کے یقینی طور پر کیا جا سکتا ہے:

• کنٹینر کی مکمل ساختی جانچ: دستخط، ڈی ایس سکسٹی فور کی جگہ اور اس کے سائز، چنک کی ترتیب، اور اے ایکس ایم ایل کا کھوج ڈیٹا کے بعد بھی۔
• سی ایچ این اے کا بائٹ کی سطح پر حساب: اندراجات ضرب چالیس، جمع چار، جمع آٹھ۔ عدد نہ ملے تو فائل خراب ہے، چاہے وہ کتنی ہی اچھی لگے۔
• حوالوں کے گراف کی مکمل جانچ: کوئی لٹکتا کنارہ نہیں، کوئی لاوارث یو آئی ڈی نہیں، کوئی دائرہ نہیں۔
• ٹائمنگ کی جانچ: بلاک متصل، یک رخے، اور والد کے دورانیے کے برابر۔
• ہر اعلان شدہ چینل میں سگنل کی موجودگی کی پیمائش۔ ڈجیٹل سیاہی خودکار طور پر پکڑی جا سکتی ہے۔
• ایک

BS.2127

کے مطابق سافٹ ویئر رینڈر، اور اس رینڈر پر لاؤڈنیس کی پیمائش۔ رینڈر کرنے کے لیے اسپیکر کی ضرورت نہیں — فائل نکل آتی ہے، اور میٹر اسے پڑھ لیتا ہے۔

جو کچھ نہیں کیا جا سکتا، اور جس کا دعویٰ نہیں کرنا چاہیے:

• یہ فیصلہ کہ اونچائی کے اجزا فنی لحاظ سے درست بیٹھے ہیں۔
• یہ فیصلہ کہ ہم نوا کی صف کا فاصلہ کسی مخصوص کمرے میں مؤثر ہے۔
• کسی مخصوص لائسنس یافتہ نظام کی توثیق۔

بائنارل جانچ کا درجہ۔ ہیڈ فون پر بائنارل رینڈر سن لینا مفید ہے مگر یہ اسپیکر کا نعم البدل نہیں۔ بائنارل رینڈر کسی نہ کسی سر سے متعلق منتقلی کے مفروضے پر بنتا ہے جو آپ کے سر کا نہیں ہوتا، اور اسی لیے آگے پیچھے کی الجھن اور اونچائی کے احساس میں فرق عام ہے۔ بائنارل سے آپ یہ تصدیق کر سکتے ہیں کہ آبجیکٹ موجود ہیں اور تقریباً درست سمت میں ہیں؛ آپ اس سے یہ طے نہیں کر سکتے کہ توازن درست ہے۔

عملی مشورہ۔ جو چیز آپ سن نہیں سکتے، اسے لکھ کر بھیجیے۔ ڈیلیوری نوٹس میں یہ درج کیجیے کہ مکس کس ترتیب پر مانیٹر ہوا، رینڈر کس ترتیب اور کس رینڈرر سے بنا، اور لاؤڈنیس کس میٹر سے ناپی گئی۔ ایک ایماندار نوٹ ایک جھوٹے دعوے سے ہمیشہ بہتر ہے، اور کیو سی کرنے والے کے لیے کہیں زیادہ کارآمد۔

۱۲۔ ڈیلیوری چیک لسٹ

ترتیب سے چلیے۔ ساختی جانچ پہلے — وہ تیز ہے اور اس کے بعد کی ہر چیز کو باطل کر سکتی ہے۔

کنٹینر ۱۔ پہلے چار بائٹ

BW64

ہیں۔ اگر

RIFF

ہیں تو یہ سادہ ویو فائل ہے اور چار جی بی سے آگے نہیں جا سکتی۔ ۲۔ ڈی ایس سکسٹی فور دستخط کے بعد پہلا چنک ہے، اور اس کے چونسٹھ بٹ سائز ڈسک پر موجود اصل سائز سے میل کھاتے ہیں۔ ۳۔ ڈیٹا کے علاوہ جو چنک چار جی بی سے بڑا ہو، اس کا اندراج ڈی ایس سکسٹی فور کی میز میں موجود ہے۔ ۴۔ اے ایکس ایم ایل کو صراحتاً تلاش کیا گیا، ڈیٹا کے بعد بھی۔ ادھورے اسکین سے "میٹا ڈیٹا نہیں ہے" کا نتیجہ نہ نکالیے۔

جوہر ۵۔ سیمپل ریٹ اور بٹ ڈیپتھ ڈیلیوری کی شرط کے عین مطابق۔ اے ڈی ایم لکھنے کے بعد کوئی ریٹ کنورژن نہیں۔ ۶۔ ایف ایم ٹی کے چینل اور سی ایچ این اے کے ٹریک برابر۔ ۷۔ ہر ٹریک انڈیکس حد کے اندر اور ایک سے شروع۔

سی ایچ این اے ۸۔ ہر اندراج ٹھیک چالیس بائٹ، فیلڈ درست چوڑائی پر پیڈ شدہ۔ ۹۔ ہر ایسا پیک حوالہ جو

0x1000

یا اس سے اوپر ہو، اے ایکس ایم ایل میں موجود تعریف تک پہنچتا ہے۔ ۱۰۔ دہرایا ہوا ٹریک انڈیکس ارادی ہے (ٹریک نے جائز طور پر تعریف بدلی)، نقل کی غلطی نہیں۔

اے ڈی ایم گراف ۱۱۔ ہر حوالہ حل ہوتا ہے۔ صفر لٹکتے کنارے۔ ۱۲۔ کسی بھی سمت میں کوئی لاوارث ٹریک یو آئی ڈی نہیں۔ ۱۳۔ کوئی دائروی یا خود اپنی طرف اشارہ کرتا عنصر نہیں۔ ۱۴۔ ہر چینل فارمیٹ کا ٹائپ لیبل اپنے والد پیک فارمیٹ سے میل کھاتا ہے۔

ٹائمنگ ۱۵۔ ایک سے زیادہ بلاک والے چینل فارمیٹ میں ہر بلاک پر آغاز اور دورانیہ دونوں موجود۔ ۱۶۔ بلاک متصل اور یک رخے؛ دورانیوں کا مجموعہ والد آبجیکٹ کے برابر۔ ۱۷۔ آبجیکٹ کا آغاز صفر پر۔

مواد ۱۸۔ اعلان شدہ بیڈ کے ہر چینل میں وہی ہے جو ہونا چاہیے؛ ڈجیٹل سیاہی کی تحقیق کیجیے۔ ۱۹۔ آبجیکٹ کی تعداد اور بیڈ کی ترتیب ڈیلیوری کی شرط کے مطابق۔ ۲۰۔ بیکسٹ کا ابتدائی ٹائم کوڈ درست اور پورے سیٹ میں یکساں۔

رینڈر اور کنفارم ۲۱۔ اسٹیریو اور بائنارل کنفارم موجودہ ماسٹر سے دوبارہ بنے، پرانے سے نہیں۔ ۲۲۔ دورانیہ اور ابتدائی ٹائم کوڈ ماسٹر سے سیمپل کی سطح پر ملتے ہیں۔ ۲۳۔ لاؤڈنیس ایک نامزد ترتیب پر، نامزد رینڈرر سے بنے رینڈر پر، نامزد میٹر سے ناپی گئی — اور تینوں نوٹس میں لکھے گئے۔

دہرائی جا سکنے والی حالت ۲۴۔ ہر ڈیلیوریبل کا چیک سم لے کر فہرست محفوظ کیجیے۔ ۲۵۔ سیشن اور اے ڈی ایم ایکس ایم ایل کو بی ڈبلیو سکسٹی فور سے الگ محفوظ کیجیے؛ جس ایکس ایم ایل کا آپ ڈِف نکال سکیں، وہ بعد میں اُس بائنری سے کہیں زیادہ قیمتی ہے جسے آپ صرف دوبارہ پارس کر سکتے ہیں۔

امرسو ڈیلیوریبل اُس وقت مکمل نہیں ہوتا جب وہ اچھا لگنے لگے؛ وہ اُس وقت مکمل ہوتا ہے جب ایک ایسی مشین جس نے اسے کبھی سنا نہیں، ثابت کر دے کہ اس کے سارے حوالے حل ہو رہے ہیں۔

۱۳۔ اختتامیہ

بی ڈبلیو سکسٹی فور اور اے ڈی ایم کھلے، شائع شدہ اور مفت پڑھے جا سکنے والے معیار ہیں۔ صنعت کے اس کونے میں یہ غیر معمولی بات ہے اور اس سے فائدہ اٹھانا چاہیے: آپ خود

BS.2088

اور

BS.2076

پڑھ سکتے ہیں، چالیس سطروں کے کوڈ سے

chna

چنک پارس کر سکتے ہیں، اور یہ تصدیق کر سکتے ہیں کہ کسی وینڈر کے ایکسپورٹر نے اصل میں کیا لکھا — نہ کہ اس کے ڈائیلاگ باکس نے کیا دعویٰ کیا۔ برصغیر کے اُس انجینئر کے لیے جس کے پاس امرسو کمرہ نہیں، یہ ایک اچھی خبر ہے: غیر ضروری رد ہونے والی امرسو فائلوں کی بھاری اکثریت حوالوں کی خرابی ہے، اور ایسی خرابی ایک ویلیڈیٹر ایک سیکنڈ سے کم میں پکڑ لیتا ہے۔

مازوفا پر ریلیز کرنا مفت ہے — کوئی اپ لوڈ فیس نہیں، کوئی سبسکرپشن نہیں، فی ریلیز کوئی چارج نہیں — واحد کٹوتی وصول شدہ رائلٹی کا پانچ فیصد ہے، اور ہر مکمل درخواست کا جائزہ ایک انسان لیتا ہے۔

ماخذ

آئی ٹی یو آر کی سفارشات

• ITU-R BS.2088-2 (11/2025), Long-form file format for the international exchange of audio programme materials with metadata — 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 — https://www.itu.int/rec/R-REC-BS.2127

ای بی یو کی تکنیکی دستاویزات

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

آخری نظرثانی: ستمبر ۲۰۲۶۔ معیارات پر نظرثانی ہوتی رہتی ہے؛ کسی شق کا حوالہ دینے سے پہلے اوپر دیے گئے آئی ٹی یو اور ای بی یو کے صفحات پر موجودہ ایڈیشن ضرور دیکھ لیں۔