যে ফাইলের সর্বোচ্চ স্যাম্পল 0.0 dBFS দেখায়, সেটি এমন ফাইল নয় যার সংকেত 0 dB পর্যন্ত পৌঁছয়। যেকোনও দুটি স্যাম্পলের মাঝখানে পুনর্গঠিত তরঙ্গরূপ দুটিরই উপরে উঠে যেতে পারে, আর একটি স্যাম্পল-পিক মিটার গঠনগতভাবেই সেটি দেখতে অক্ষম। তারপর একটি ক্ষতিকর কোডেক — যেটি প্রতিটি স্ট্রিমিং পরিষেবা কেউ শোনার আগেই আপনার মাস্টারে চালায় — ওই বিচ্যুতিগুলিকে আরও উঁচুতে ঠেলে দেয়। ফল হল এমন একটি মাস্টার, যা আপনার DAW-তে পরিষ্কার মেপেছিল আর প্লেব্যাকে বিকৃত হয়, আর এর কিছুই মতামতের ব্যাপার নয়। এটি স্যাম্পলড অডিও কীভাবে পুনর্গঠিত হয় তার পরিণতি।
এই লেখাটি বলছে স্যাম্পল পিক আর ট্রু পিক আসলে কী, দ্বিতীয়টি মাপার একমাত্র উপায় কেন ওভারস্যাম্পলিং, একটি 4× মিটার কী দেখতে পায় আর কী পায় না, আর তিনটি মানসম্মত লাউডনেস মিটারের কোনটি কোন প্রশ্নের উত্তর দেয়। কোন পরিষেবা লক্ষ্যমাত্রা হিসেবে কী প্রকাশ করে আর শান্ত মাস্টারের কী হয়, তা আলাদা করে আছে আপনার মাস্টারের সঙ্গে আসলে কী ঘটে লেখাটিতে।
স্যাম্পল পিক ফাইলের সবচেয়ে উঁচু বিন্দু। ট্রু পিক ফাইলের ভিতরেই নেই।
একটি স্যাম্পল-পিক মিটার ফাইলের বৃহত্তম পরম স্যাম্পল মানটি জানায়। ওটি একটি বাস্তব সংখ্যা আর হিসাব করাও সহজ — প্রতিটি স্যাম্পল দেখুন আর সবচেয়ে বড়টি রেখে দিন।
কিন্তু স্যাম্পল হল একটি অবিচ্ছিন্ন তরঙ্গরূপের উপরের বিন্দু, তরঙ্গরূপটি নয়। ওই বিন্দুগুলির ভিতর দিয়ে যাওয়া তরঙ্গরূপ তাদের মাঝখানে দুটিরই উপরে উঠে যেতে পারে। পুনর্গঠিত অ্যানালগ তরঙ্গরূপ ফাইলের সর্বোচ্চ স্যাম্পলকে ছাড়িয়ে যেতে পারে, আর একটি স্যাম্পল-পিক মিটারের কাছে এটি শনাক্ত করার কোনও উপায় নেই। ওই বিচ্যুতিগুলিই ইন্টার-স্যাম্পল পিক। সেগুলিসহ পুনর্গঠিত তরঙ্গরূপের লেভেলটিই ট্রু পিক, প্রকাশ করা হয় dBTP-তে।
এই কারণেই "কিছু ক্লিপ করেনি" আর "কিছু ক্লিপ করবে না" দুটি আলাদা দাবি। ডিজিটালি নিরাপদ যে ফাইলের স্যাম্পল সর্বোচ্চ −0.1 dBFS-এ থামে, তারও ট্রু পিক 0 dBTP-র অনেক উপরে থাকতে পারে। ফাইলের ভিতরে কিছুই সীমা ছাড়ায়নি। পরে যা কিছু তরঙ্গরূপটি পুনর্গঠন করে — একটি DAC, একটি স্যাম্পল-রেট কনভার্টার, একটি ক্ষতিকর ডিকোডার — সেটি ক্লিপ করতে পারে।
ব্যবহারিক পরীক্ষাটি ভোঁতা: যে মিটারের স্পষ্ট ট্রু-পিক বা dBTP মোড নেই, তার ম্যানুয়াল যা-ই ইঙ্গিত করুক, সেটি একটি স্যাম্পল-পিক মিটার। এর মধ্যে পড়ে DAW-এর ভিতরে বসানো বেশিরভাগ লেভেল মিটার, আর পড়ে বহু লিমিটারের সিলিং নিয়ন্ত্রণও।
ক্ষতিকর এনকোডিং কেন ব্যাপারটা নিরপেক্ষ রাখে না, খারাপ করে
স্ট্রিমিং আপনার WAV পৌঁছে দেয় না। সেটি পৌঁছে দেয় তার একটি AAC, Ogg Vorbis বা MP3 এনকোডিং, আর একটি ক্ষতিকর কোডেক আপনার তরঙ্গরূপ স্যাম্পলে স্যাম্পলে পুনরুৎপাদন করে না। সেটি অনুভূতিগতভাবে কাছাকাছি একটি তরঙ্গরূপ পুনরুৎপাদন করে। ডিকোডারের আউটপুট নিয়মিতই এনকোডারের ইনপুটকে ছাড়িয়ে যায়।
ওই ছাড়িয়ে যাওয়া কোনও নির্দিষ্ট এনকোডারের ত্রুটি নয়। এটি বর্ণালীগত খুঁটিনাটি কোয়ান্টাইজ করা আর ফেলে দেওয়ার অনিবার্য পরিণতি, আর — মাস্টারিংয়ের সিদ্ধান্তের জন্য এই অংশটিই গুরুত্বপূর্ণ — উৎসটিকে কতটা কড়াভাবে লিমিট করা হয়েছে, তার সঙ্গে সঙ্গে এটি বাড়ে। সিলিংয়ের গায়ে সংকেতটিকে যত আক্রমণাত্মকভাবে চ্যাপ্টা করেছেন, ফেরত আসার পথে কোডেক তত বেশি ওভারশুট তৈরি করবে।
ফলে ঠিক 0.0 dBTP-তে বসে থাকা একটি মাস্টার ডিকোড হয় 0 dBFS-এর উপরের পিক নিয়ে, আর ডিকোডার সেগুলি ক্লিপ করে। নিজের ফাইলে আপনি এটি কখনও শোনেন না। শোনেন শ্রোতা যে সংস্করণটি পান, তাতে।
এই বিষয়ে যত প্রকাশিত নির্দিষ্টকরণ আছে, সবই একই সিদ্ধান্তে পৌঁছয়। AES TD1008 বলে: "For all content, it is recommended that the Maximum True Peak level not exceed −1 dBTP at the codec input of lossy-encoded streams." Spotify আপনাকে ট্রু পিক "below −1dB TP (True Peak) max" রাখতে বলে, আর −14 LUFS-এর চেয়ে জোরালো মাস্টারের ক্ষেত্রে "keep True Peak below −2dB to avoid extra distortion."
Spotify-র দ্বিতীয় সংখ্যাটিই কৌতূহলোদ্দীপক। এর অস্তিত্ব ঠিক এই কারণেই যে কড়াভাবে লিমিট করা উপাদান কোডেকে বেশি ওভারশুট করে। সিলিংটি কোনও স্থির কুসংস্কার নয়; উপাদান যত ঘন হয়, সেটি তত কষে বসে।
ওভারস্যাম্পলিং আসলে কী করছে, আর 4× কী দেখতে পায় না
ফাইলের ভিতরে নেই এমন একটি পিক মাপতে হলে স্যাম্পলগুলির মাঝখানে তরঙ্গরূপটি পুনর্গঠন করতেই হবে। ITU-R BS.1770 সেটি করার উপায় হিসেবে ওভারস্যাম্পলিং নির্দিষ্ট করে — বাড়তি স্যাম্পল বিন্দু ইন্টারপোলেট করা, তারপর ঘনতর সংকেতটির পিক মাপা।
সুপারিশটি বেঁধে দেয় 48 kHz-এ ন্যূনতম 4× ওভারস্যাম্পলিং, আর মনে করিয়ে দেয় যে "Higher sampling rates and over-sampling ratios are preferred."
কথাটি যেমন লেখা তেমনই পড়ুন। 4× হল সঙ্গতির মেঝে, নির্ভুল উত্তর নয়। একটি 4× মিটার স্যাম্পল-পিক মিটারের চেয়ে বেশি ধরবেই, কিন্তু সবকিছু ধরার নিশ্চয়তা নেই; 4×-এ মাপটি এখনও সত্যিকারের পিককে দশমাংশ ডেসিবেলের কয়েক ঘর কম পড়তে পারে। ওই দশমাংশগুলিই ঠিক সেই পরিমাণ, যতটা মার্জিন লোকে সিলিং থেকে ছেঁটে নিতে চায়।
| আপনি কী ব্যবহার করছেন | সেটি কী জানায় | সেটি কী ফেলে যায় |
|---|---|---|
| স্যাম্পল-পিক মিটার | ফাইলের বৃহত্তম স্যাম্পল মান | প্রতিটি ইন্টার-স্যাম্পল পিক; কোডেক ওভারশুটের গোটা প্রশ্নটাই |
| 4× ট্রু-পিক মিটার | BS.1770 সঙ্গতির মেঝেতে পুনর্গঠিত পিক | এখনও সত্যিকারের পিককে দশমাংশ ডেসিবেলের কয়েক ঘর কম পড়তে পারে |
| 8× বা 16× ট্রু-পিক মিটার | পুনর্গঠিত পিকের আরও কাছাকাছি একটি অনুমান | ক্রমশ কম, আর CPU-র খরচ নগণ্য |
আপনার মিটারে থাকলে 8× বা 16× ওভারস্যাম্পলিং ব্যবহার করুন। বাড়তি CPU খরচ নগণ্য আর বাড়তি নির্ভুলতা নয়।
লিমিটারের দিকে এর একটি সঙ্গী ফাঁদ আছে। −1.0 dBTP-তে বসানো একটি ট্রু-পিক সিলিং তখনই কিছু বোঝায়, যখন লিমিটারটি সত্যিই ট্রু-পিক লিমিটিং করছে। বহু লিমিটারের সিলিং নিয়ন্ত্রণ স্যাম্পল-পিক, আর সেটিকে −1.0-এ বসালে আপনি পাবেন −0.5 dBTP-র কোথাও উপরে ইন্টার-স্যাম্পল পিক — কোডেক ফাইলটি ছোঁয়ার আগেই আপনার অর্ধেক মার্জিন শেষ।
আপনার মিটার মানটির কোন সংস্করণের উল্লেখ করছে
BS.1770-এর ছয়টি সংস্করণ আছে: 2006, 2007, 2011, 2012, 2015 ও 2023। ব্যবহারে থাকা বেশিরভাগ মিটার BS.1770-4 (October 2015) সংস্করণটির উল্লেখ করে; বর্তমানে বলবৎ সংস্করণটি BS.1770-5 (November 2023)। এখানে বর্ণিত 4× ওভারস্যাম্পলিংয়ের মেঝে, ফিল্টারের ধাপগুলি আর দুটি গেট — সবই প্রকাশিত BS.1770-5-এর সাপেক্ষে যাচাই করা।
এটি জানা দরকার মূলত এই কারণে যে আপনি যেন আপনার মিটারের নথি ঠিকভাবে পড়েন। -4-এর উল্লেখ করা কোনও মিটার তাতেই ভুল হয়ে যায় না, কিন্তু -5-ই চলতি পাঠ্য, আর কোনও দাবি কোনও নথির সাপেক্ষে যাচাই করার সময় নাম করতে হয় সেটিরই।
মুহূর্তিক, স্বল্পমেয়াদি, ইন্টিগ্রেটেড: তিনটি মিটার, তিনটি প্রশ্ন
সমস্যার বাকি অর্ধেক হল, বেশিরভাগ লোক যে সিদ্ধান্ত নিচ্ছেন তার জন্য ভুল লাউডনেস মিটারটি পড়েন। EBU Tech 3341 তিনটি জানালা সংজ্ঞায়িত করে, আর সেগুলি সত্যিই আলাদা তিনটি প্রশ্নের উত্তর দেয়।
মুহূর্তিক (M) — 400 ms, গেটহীন। একটি BS.1770 গেটিং ব্লকের সঙ্গে একই জানালা। মুহূর্তিক লাউডনেস আলাদা আলাদা ঘটনা অনুসরণ করে: একটি স্নেয়ার, একটি কণ্ঠব্যঞ্জন, একটি ডাউনবিট। এটি ব্যবহার করুন জিনিস ধরার জন্য — এমন একটি কিক যা চারপাশের সবকিছুর চেয়ে 6 LU উপরে লাফায়, বা এমন একটি অংশ যা বেরিয়ে আসে। লেভেলের সিদ্ধান্ত নিতে এটি ব্যবহার করবেন না। এটি বড্ড চঞ্চল, আর মুহূর্তিক মিটারের পিছনে ছুটলে ঠিক সেই অতি-কম্প্রেসড ফলটিই তৈরি হয়, যাকে প্লেব্যাক নর্মালাইজেশন শাস্তি দেয়।
স্বল্পমেয়াদি (S) — 3 s, গেটহীন। তিন সেকেন্ড মোটামুটি একটি সংগীত-বাক্যাংশ। একটি ট্র্যাকের ভিতরে ভারসাম্যের সিদ্ধান্তের জন্য স্বল্পমেয়াদি লাউডনেসই সঠিক মিটার, কারণ তিন সেকেন্ডই সেই সময়ের মাপ যেখানে শ্রোতারা সত্যিই কোনও অংশকে জোরালো বা শান্ত বলে অনুভব করেন। এটি ব্যবহার করুন একটি ভার্সের সঙ্গে কোরাসের তুলনা করতে, একটি ব্রিজ ভেঙে পড়ছে কি না দেখতে, আর আপনার সাজানোর আকৃতিটি সংখ্যা হিসেবে দেখতে।
ইন্টিগ্রেটেড (I) — গোটা প্রোগ্রাম, দ্বিগুণ গেটেড। এই সংখ্যাটির সাপেক্ষেই পরিষেবাগুলি নর্মালাইজ করে, আর একমাত্র এটিরই ডেলিভারি স্পেকে থাকার অধিকার আছে। এটি মাপা হয় গোটা ট্র্যাকের উপর, প্রথম স্যাম্পল থেকে শেষ পর্যন্ত, বাছাই করা কোনও অংশের উপর নয়। ইন্টিগ্রেটেড লাউডনেস একটি ডেলিভারি নির্দিষ্টকরণ, মিক্সিংয়ের হাতিয়ার নয়; কাজ করতে করতে এটির দিকে তাকিয়ে থাকলে আপনি ভুল মিটারের দিকে তাকিয়ে আছেন।
| মিটার | জানালা | গেটিং | যে প্রশ্নের উত্তর দেয় |
|---|---|---|---|
| মুহূর্তিক | 400 ms | নেই | এইমাত্র কী ঘটল? |
| স্বল্পমেয়াদি | 3 s | নেই | এই অংশটি কি ওই অংশের সাপেক্ষে ভারসাম্যে আছে? |
| ইন্টিগ্রেটেড | গোটা প্রোগ্রাম | পরম −70 LKFS, তারপর আপেক্ষিক −10 LU | সরবরাহের সময় পরিষেবা কী মাপবে? |
এর থেকে যে নিয়মটি আসে: স্বল্পমেয়াদি দেখে মিক্স ও মাস্টার করুন, ইন্টিগ্রেটেড দেখে যাচাই করুন, আর অসঙ্গতি খতিয়ে দেখুন মুহূর্তিক দিয়ে।
এটি আসলে যে ভুলটি ঘটায়
প্রচলিত ভুলটি হল মাস্টারিংয়ের সময় ইন্টিগ্রেটেড লাউডনেসের দিকে তাকিয়ে থেকে ততক্ষণ লিমিটিং যোগ করা, যতক্ষণ না কেউ আপনাকে বলে দেওয়া সংখ্যাটি সেখানে ফুটে ওঠে। ওই আচরণে দুটি আলাদা ব্যর্থতা একটির উপর আরেকটি চাপানো।
প্রথমটি হল, ইন্টিগ্রেটেড লাউডনেস দ্বিগুণ গেটেড, আর ওই গেটিংয়ের কারণে সেটি লোকে যা ভাবে তা মাপে না। −70 LKFS-এর নিচের ব্লকগুলি একেবারে বাদ পড়ে যায়। তারপর টিকে থাকা ব্লকগুলির গড় বার করা হয়, তা থেকে 10 বিয়োগ করা হয়, আর ওই আপেক্ষিক সীমার নিচের প্রতিটি ব্লকও বাদ পড়ে। আপেক্ষিক গেট বসে পরম-গেট করা গড়ের 10 LU নিচে, গোটা ফাইলের গেটহীন গড়ের 10 LU নিচে নয়। আপনার কাজের সেশনের জন্য এর ফল সরাসরি: আপনার ট্র্যাকের ইন্টিগ্রেটেড লাউডনেস কার্যত তার জোরালো অংশগুলির গড় লাউডনেস, গোটা ট্র্যাকের নয়। ফিসফিসে 40 সেকেন্ডের ইন্ট্রো আর দেয়ালের মতো কোরাসওয়ালা একটি গান প্রায় পুরোপুরি তার কোরাসের উপরেই মাপা হয়। শেষ হয়ে যাওয়া একটি মাস্টারে শান্ত একটি ইন্ট্রো জুড়লে ইন্টিগ্রেটেড পাঠটি সামান্যই নড়ে, আর যে ইঞ্জিনিয়াররা নড়বে বলে আশা করেন তাঁরা অবাক হন।
দ্বিতীয় ব্যর্থতাটি হল, লাউডনেস রেঞ্জ আবার একটি আলাদা গেট ব্যবহার করে। EBU Tech 3342-তে নির্দিষ্ট করা LRA হল স্বল্পমেয়াদি লাউডনেস বণ্টনের 10th ও 95th পার্সেন্টাইলের অনুমানের মধ্যে পার্থক্য, আর Tech 3342 তার আপেক্ষিক সীমা বসায় পরম-গেট করা লাউডনেস লেভেলের −20 LU নিচে, −10 LU নয়। চওড়া গেটটি ইচ্ছাকৃত — LRA বৈচিত্র্যের চরিত্র বর্ণনা করছে, তাই ইন্টিগ্রেটেড মাপ যে শান্ত অংশগুলি বাদ দেওয়ার জন্যই তৈরি, সেগুলিকে তার ঢুকতে দিতেই হবে। যে মিটার LRA-র জন্য ইন্টিগ্রেটেডের −10 LU গেট পুনর্ব্যবহার করে, সেটি ব্যবস্থাগতভাবেই বড্ড ছোট মান জানায়। একই ফাইলে আপনার মিটার যদি অন্য মিটারের চেয়ে লক্ষণীয়ভাবে কম LRA জানায়, সন্দেহ করুন যে সেখানে −20 LU থাকার কথা ছিল আর আছে −10 LU গেট।
এটি আপনি কয়েক মিনিটেই পরীক্ষা করতে পারেন। ট্র্যাকের মূল অংশের চেয়ে 15 LU নিচের 20 সেকেন্ড উপাদান জুড়ে দিন। সঠিক বাস্তবায়নের LRA উল্লেখযোগ্যভাবে বাড়বে। ভাঙা বাস্তবায়নের সামান্যই নড়বে।
আসলে কী সরবরাহ করবেন
নির্দেশনাটি সংক্ষিপ্ত, আর তার প্রতিটি সংখ্যাই প্রকাশিত।
- আগে সিলিং ঠিক করুন: −1.0 dBTP, ট্রু-পিক, ওভারস্যাম্পল করা। এই তালিকায় এটিই একমাত্র সত্যিকারের কঠিন শর্ত। আপনার মাস্টার −14 LUFS ইন্টিগ্রেটেডের চেয়ে জোরালো হলে −2.0 dBTP ব্যবহার করুন — কড়া সংখ্যাটির অস্তিত্ব এই কারণে যে কড়াভাবে লিমিট করা উপাদান কোডেকে বেশি ওভারশুট করে।
- সংগীতের জন্য মাস্টার করুন। লিমিটারকে যতটা সম্ভব কম কাজ করিয়ে ভারসাম্য, টোন ও গতিশীলতা ঠিক করুন, আর এই পর্যায়ে ইন্টিগ্রেটেড মিটারের দিকে তাকাবেন না।
- ফলাফলটি মাপুন। যে ইন্টিগ্রেটেড লাউডনেসে আপনি পৌঁছেছেন, সেটিই আপনার প্রার্থী। সেটি মোটামুটি −14 আর −9 LUFS-এর মধ্যে বসলে প্রতিটি প্রকাশিত লক্ষ্যমাত্রা আর প্রতিটি কথিত সংখ্যা আপনার কয়েক LU-র মধ্যেই আছে। −9 LUFS-এর চেয়ে জোরালো হলে জিজ্ঞাসা করুন লিমিটিং আপনাকে কী কিনে দিল।
- লিমিটিং যোগ করে নয়, মাস্টারিং বদলে সমন্বয় করুন। মিটারে ঠিক পাঠ না আসা পর্যন্ত লিমিটিং যোগ করে কোনও LUFS সংখ্যায় পৌঁছনো ঠিক সেই আচরণ, যেটিকে অর্থহীন করে দেওয়ার জন্যই নর্মালাইজেশন তৈরি হয়েছিল।
দুটি কাজ করবেন না। −0.1 dBTP-র একটি সিলিং স্ট্রিমিংয়ের জন্য একটি ডেলিভারি ত্রুটি, শৈলীগত সিদ্ধান্ত নয়। আর আলাদা আলাদা পরিষেবার জন্য আলাদা আলাদা মাস্টার কাটবেন না — প্রকাশিত ও কথিত লক্ষ্যমাত্রাগুলি মোটামুটি 2 LU-র মধ্যে ছড়ানো, কোনও সংখ্যায় হুবহু পৌঁছনোয় শোনার মতো কিছুই বদলায় না, আর যুক্তিসঙ্গত গতিশীলতাসহ −1 dBTP-তে করা একটিই মাস্টার সর্বত্র সঠিক।
সরবরাহের আগে শেষ করা কোনও ফাইল যাচাই করতে চাইলে, Mazufa-র বিনামূল্যের লাউডনেস ও ট্রু-পিক চেকার আছে /loudness-checker ঠিকানায়। এটি সম্পূর্ণভাবে আপনার নিজের ব্রাউজারে চলে আর কোনও অডিও আপলোড করে না।
সূত্র
ITU-R BS.1770 — মাপার অ্যালগরিদম, K-weighting, গেটিং, ট্রু পিক
- Recommendation ITU-R BS.1770-5 (11/2023), Algorithms to measure audio programme loudness and true-peak audio level (সম্পূর্ণ পাঠ্য PDF): https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-5-202311-I!!PDF-E.pdf
- BS.1770 সুপারিশের পাতা ও সংস্করণ ইতিহাস (BS.1770-0 থেকে BS.1770-5): https://www.itu.int/rec/R-REC-BS.1770/en
EBU — মিটারের জানালা ও লাউডনেস রেঞ্জ
- EBU Tech 3341, Loudness Metering: EBU Mode metering to supplement EBU R 128 (মুহূর্তিক 400 ms, স্বল্পমেয়াদি 3 s): https://tech.ebu.ch/publications/tech3341
- EBU Tech 3342, Loudness Range: A measure to supplement EBU R 128 loudness normalisation (−20 LU গেট; 10th/95th পার্সেন্টাইল), PDF: https://tech.ebu.ch/docs/tech/tech3342.pdf
AES — কোডেক ইনপুটে ট্রু-পিক সিলিং
- AES TD1008.1.21-9, Recommendations for Loudness of Internet Audio Streaming and On-Demand Distribution (কোডেক ইনপুটে −1 dBTP), PDF: https://aes2.org/wp-content/uploads/2024/01/20210924_TD1008_v3.13.pdf
- AES TD1008 নথির পাতা: https://aes.org/technical-council/technical-document-aestd1008/
Spotify — প্রকাশিত ট্রু-পিক সিলিং
- Spotify for Artists, Loudness normalization (−1 dBTP; −14 LUFS-এর চেয়ে জোরালো মাস্টারের জন্য −2 dBTP): https://support.spotify.com/us/artists/article/loudness-normalization/