فرمت های صدا
فرمت های صدا دو دسته اند: با اتلاف، که بخشی از سیگنال را دور می ریزند و دیگر برنمی گردانند، و بدون اتلاف، که فایل را کوچک می کنند ولی عین نمونه های اصلی را نگه می دارند. هیچ کدام بهتر از دیگری نیست؛ آرشیو بدون اتلاف می خواهد و پخش با اتلاف.
- درس ۴ از ۱۰
- مقدماتی
- رایگان، بدون ثبت نام
با اتلاف و بدون اتلاف، دو کار درست
با اتلاف: MP3، AAC، Opus
- بخشی از سیگنال دور ریخته می شود و برنمی گردد
- تا هشتاد و پنج تا نود و پنج درصد کوچک تر
- برای پخش، انتشار و هر چیزی که دانلود می شود
- کدگذاری دوباره روی آن، ضرر را انباشته می کند
بدون اتلاف: WAV، FLAC
- در برگشت دقیقا همان نمونه های اصلی
- FLAC حدود چهل تا پنجاه درصد کوچک تر، WAV اصلا فشرده نمی شود
- برای ضبط، تدوین، مستر و آرشیو
- هر بار خروجی گرفتن از آن، از نقطه صفر شروع می شود
هیچ کدام بهتر از دیگری نیست. اشتباه وقتی پیش می آید که آرشیو را با اتلاف نگه دارید یا فایل پخش را بدون اتلاف بفرستید.
آخرین بررسی: فکت ها و نام ابزارهای این درس در همین تاریخ با منابعشان بازبینی شده اند.
با اتلاف و بدون اتلاف؛ فرقشان دقیقا چیست
یک کدک بدون اتلاف فایل را کوچک می کند و در برگشت دقیقا همان نمونه هایی را می دهد که گرفته بود، بایت به بایت. یک کدک با اتلاف این تعهد را ندارد: بخشی از سیگنال را که به حساب مدل شنوایی کمتر شنیده می شود دور می ریزد و آن بخش دیگر برنمی گردد. راهنمای کدک های صدای موزیلا همین را می گوید و اندازه صرفه جویی را هم می آورد: کدک با اتلاف تا هشتاد و پنج تا نود و پنج درصد فشرده می کند و بدون اتلاف حدود چهل تا پنجاه درصد.
این اختلاف بزرگ است و دلیل وجود هر دو دسته را توضیح می دهد. یک قسمت پادکست بدون اتلاف چند صد مگابایت می شود و کسی آن را دانلود نمی کند. همان قسمت با اتلاف چند ده مگابایت است و تفاوتش را در گوشی و هندزفری نمی شنوید.
ولی جهت را عوض کنید و همه چیز فرق می کند. فایلی که یک بار با اتلاف فشرده شده، آن اطلاعات را برای همیشه از دست داده. می توانید بعدا از آن یک WAV بسازید و فایلتان بزرگ می شود، ولی چیزی که دور ریخته شده برنمی گردد. WAV بزرگ به معنی WAV باکیفیت نیست، و همین جمله جلوی بیشتر اشتباه های این حوزه را می گیرد.
نرخ نمونه و عمق بیت و بیت ریت یعنی چه
صدا در هوا یک موج پیوسته است و کامپیوتر پیوسته نمی فهمد، پس از آن موج در فاصله های منظم عکس گرفته می شود. تعداد این عکس ها در هر ثانیه نرخ نمونه است: 44100 یعنی چهل و چهار هزار و صد بار در ثانیه. دقت هر عکس عمق بیت است: با ۱۶ بیت، هر نمونه یکی از شصت و پنج هزار و پانصد و سی و شش سطح ممکن را می گیرد.
این دو عدد با هم اندازه صدای فشرده نشده را تعیین می کنند و حساب کردنش ساده است. یک ثانیه صدای استریو با نرخ 44100 و عمق ۱۶ بیت می شود 44100 ضربدر ۱۶ ضربدر ۲، یعنی 1411200 بیت در ثانیه. برای همین است که WAV بزرگ است: چیزی را فشرده نمی کند و فقط همان نمونه ها را پشت سر هم می نویسد. در بخش تجربه خودمان همین را با یک فایل واقعی نشان داده ایم.
بیت ریت عدد سوم است و مال کدک های فشرده کننده. می گوید کدک اجازه دارد در هر ثانیه چند بیت خرج کند. موزیلا بازه MP3 را ۳۲ تا ۳۲۰ کیلوبیت بر ثانیه می نویسد و صفحه خود Opus بازه اش را ۶ تا ۵۱۰ کیلوبیت. بازه Opus برای همین این قدر پایین شروع می شود که برای گفتار هم طراحی شده و نه فقط موسیقی.
و یک قاعده که پول و فضا نگه می دارد: بالا بردن نرخ نمونه یا عمق بیت بالاتر از چیزی که در ضبط واقعا ثبت شده، فقط فایل را بزرگ می کند. کیفیت از منبع می آید، نه از عددی که موقع خروجی تایپ می کنید.
صدا چطور فایل می شود
-
۱
موج در هوا
پیوسته و بی نهایت ریز. کامپیوتر این را نمی فهمد.
-
۲
میکروفن
موج را به سیگنال برقی تبدیل می کند. کیفیت نهایی از همین جا سقف می خورد.
-
۳
نمونه برداری
نرخ نمونه: چند بار در ثانیه از موج عکس گرفته می شود.
-
۴
کوانتیزه کردن
عمق بیت: هر نمونه با چه دقتی نوشته می شود.
-
۵
کدگذاری و فایل
بیت ریت و فرمت: اینجا تصمیم گرفته می شود چیزی دور ریخته شود یا نه.
سه عدد این درس در سه مرحله میانی این زنجیره تعیین می شوند. هیچ کدامشان کیفیت ضبط را جبران نمی کنند: اتاق پر پژواک در هر نرخ نمونه ای پر پژواک است.
پنج فرمتی که واقعا استفاده می شوند
ستون های زیر از راهنمای کدک های صدای موزیلا و برای Opus از صفحه خود پروژه خوانده شده اند.
| فرمت | نوع | مجوز | پشتیبانی مرورگر | جای درستش |
|---|---|---|---|---|
| MP3 | با اتلاف | ثبت اختراع هایش منقضی شده، در آمریکا از آوریل ۲۰۱۷ | همه مرورگرهای اصلی | وقتی مقصد فقط MP3 می پذیرد |
| AAC | با اتلاف | پخش و توزیع مجوز نمی خواهد؛ سازنده کدک مجوز می خواهد | وابسته به پشتیبانی خود سیستم عامل؛ کروم فقط داخل MP4 | صدای داخل ویدیو |
| Opus | با اتلاف | کاملا باز و بدون حق امتیاز، استاندارد IETF با شماره RFC 6716 | کروم، فایرفاکس، اج، سافاری ۱۱ به بعد | گفتار و پخش روی وب، و هر جا تاخیر مهم است |
| WAV | بدون فشرده سازی | آزاد | همه جا | ضبط و تبادل بین نرم افزارها |
| FLAC | بدون اتلاف | کاملا باز و بدون حق امتیاز | کروم، فایرفاکس ۵۱ به بعد، سافاری ۱۱ به بعد | آرشیو و نسخه مستر |
دو ستون این جدول بیشتر از بقیه تصمیم می سازند. اول مجوز، که توضیح می دهد چرا Opus و FLAC در هر پروژه ای بدون سوال حقوقی قابل استفاده اند. دوم تاخیر، که در جدول نیامده ولی در متن موزیلا هست: Opus بین ۵ تا ۶۶.۵ میلی ثانیه تاخیر دارد و کمترین تاخیر بین کدک های همه منظوره است. برای تماس صوتی و پخش زنده همین یک عدد انتخاب را تمام می کند.
اگر فقط یک فرمت با اتلاف می توانید پشتیبانی کنید، توصیه خود موزیلا AAC است. این توصیه با آنچه بالا گفتیم تناقض ندارد: AAC انتخاب امن است وقتی نمی دانید آن طرف چیست، و Opus انتخاب بهتر است وقتی می دانید.
سازنده پادکست، تدوینگر و آرشیو؛ هر کدام چه لازم دارند
سه نفر با سه نیاز، و همین سه تا تقریبا همه حالت ها را می پوشانند.
سازنده پادکست با WAV ضبط می کند و با MP3 منتشر می کند، و بین این دو هیچ فایل با اتلاف دیگری نباید وجود داشته باشد. WAV چون در حین ضبط و تدوین هیچ چیزی از دست نمی رود، و MP3 چون فهرست پلتفرم های پادکست هنوز آن را می خواهد. اگر مقصد Opus را قبول می کند، فایل کوچک تری با همان کیفیت می گیرید؛ ولی این را از مستندات همان پلتفرم بخوانید و نه از حافظه.
تدوینگر ویدیو معمولا انتخابی ندارد و همان چیزی را می گذارد که ظرف قبول می کند: AAC داخل MP4، Opus داخل WebM. نکته ای که راحت فراموش می شود این است که صدا هم بیت ریت دارد و در فایل نهایی سهم می گیرد. برای صدای گفتاری، بیت ریت پایین تر و یک کانال به جای دو کانال، حجم را محسوس کم می کند و کسی متوجه نمی شود.
و آرشیو ساده ترین قاعده را دارد: هر چیزی که دوباره ساختنش گران است، بدون اتلاف نگه دارید. FLAC برای همین ساخته شده و موزیلا هم دقیقا آرشیو موسیقی را کاربردش می نویسد. اگر فایل خام WAV دارید و جا کم آورده اید، تبدیلش به FLAC هیچ چیزی از دست نمی دهد؛ در بخش تجربه خودمان همین را با یک آزمایش نشان داده ایم.
چهار کاری که فرمت صدا را انتخاب می کنند
خانه ها محور ندارند: هر خانه یک کار است و جوابش کنارش نوشته شده.
-
پادکست و گفتار
با WAV ضبط کنید، با MP3 منتشر کنید. Opus اگر مقصد قبولش کند.
-
صدای داخل ویدیو
AAC داخل MP4، Opus داخل WebM. ظرف انتخاب را تنگ می کند.
-
آرشیو و مستر
FLAC، یا همان WAV اصلی اگر جا دارید. هرگز با اتلاف.
-
پخش روی وب
Opus کوچک ترین است و کمترین تاخیر را دارد؛ MP3 امن ترین جایگزین.
این چهار خانه فرمت را حل می کنند، نه بیت ریت را. عدد بیت ریت را باید از مشخصات خود مقصد بردارید.
چرا نباید از یک فایل با اتلاف دوباره خروجی با اتلاف گرفت
هر بار که یک فایل با اتلاف کدگذاری می شود، کدک تصمیم می گیرد چه چیزی را دور بریزد. حالا اگر ورودی خودش یک بار این مرحله را گذرانده باشد، تصمیم دوم روی چیزی گرفته می شود که قبلا از آن دور ریخته اند. نتیجه انباشته می شود و برگشت پذیر نیست.
در عمل این اتفاق بی سر و صدا می افتد و کسی متوجه اش نمی شود: فایل MP3 را در نرم افزار تدوین می اندازید، یک برش می زنید، دوباره MP3 خروجی می گیرید. یا صدای یک ویدیو را که خودش AAC است، جدا می کنید و برای پادکست به MP3 تبدیل می کنید. هر دو کار شدنی است و هر دو یک مرحله دور ریختن اضافه دارند.
راه درست همان قاعده آرشیو است. یک نسخه بدون اتلاف نگه دارید، همه ویرایش ها را روی آن انجام دهید، و هر خروجی با اتلاف را مستقیم از همان نسخه بگیرید. اگر مجبورید از یک فایل با اتلاف کار کنید، لااقل کاری کنید که فقط یک بار دیگر کدگذاری شود و نه سه بار.
مسیر سریع با هوش مصنوعی
چیزی که یک پادکست حرفه ای را از یک پادکست خانگی جدا می کند معمولا میکروفن نیست، یکدست بودن بلندی صدا بین قسمت هاست. راه معمول این است که در نرم افزار یک دکمه Normalize بزنید، که فقط بلندترین قله را می برد بالا و هیچ ربطی به بلندی شنیده شده ندارد. راه حرفه ای اندازه گیری بلندی یکپارچه و اصلاح کردن آن است، و ffmpeg برای همین فیلتر loudnorm را دارد که خودش را پیاده سازی EBU R128 معرفی می کند. شکل دو مرحله ای آن دقیقا همان جایی است که مدل زبانی به درد می خورد: مرحله اول عددهای اندازه گیری شده را به شکل JSON چاپ می کند و مرحله دوم باید همان عددها را عینا بگیرد. این پر کردن مکانیکی، همان کاری است که آدم ها در آن اشتباه می کنند.
- مرحله اول، اندازه گیری. یک خط: ffmpeg -i in.wav -af loudnorm=print_format=json -f null - که در خروجی measured_I و measured_TP و measured_LRA و measured_thresh را چاپ می کند و هیچ فایلی نمی نویسد.
- هدف را از مستندات خود مقصد بردارید، نه از یک عدد که در جایی خوانده اید. اگر مقصد چیزی اعلام نکرده، پیش فرض های خود loudnorm سر جایشان می مانند: بلندی یکپارچه منفی ۲۴، سقف قله واقعی منفی ۲، و بازه بلندی ۷. اینها را با ffmpeg -h filter=loudnorm خودتان می بینید.
- نسخه پایین را با JSON مرحله اول و هدف مقصد پر کنید. مدل باید دستور مرحله دوم را با همان عددهای اندازه گیری شده بسازد و همان جا خروجی نهایی را هم به فرمت تحویل کدگذاری کند، تا فایل دو بار کدگذاری نشود.
- آخر کار دوباره اندازه بگیرید. همان دستور مرحله اول را روی خروجی اجرا کنید؛ عدد باید روی هدف نشسته باشد. اگر ننشسته، معمولا یعنی منبع بازه دینامیکی خیلی بزرگی داشته و باید تصمیم انسانی گرفت، نه اینکه عدد را دوباره بزور جابه جا کرد.
نسخه آماده کپی
نقش: مهندس صدا. کار تو ساختن دقیق دستور مرحله دوم loudnorm است. هیچ عددی نساز؛ فقط عددهایی را استفاده کن که در JSON زیر یا در هدف مقصد آمده اند.
هدف مقصد:
{اگر مقصد عددی اعلام کرده اینجا بنویس، وگرنه بنویس «اعلام نشده» تا پیش فرض های خود فیلتر بماند}
فرمت و مشخصات تحویل:
{مثلا: MP3 استریو برای هاست پادکست | AAC داخل MP4 برای ویدیو | Opus برای وب}
خروجی JSON مرحله اول:
{JSON را اینجا بگذار}
به این ترتیب جواب بده:
۱. یک دستور ffmpeg بده که هر چهار مقدار measured را عینا از JSON بردارد و linear را روشن نگه دارد.
۲. در همان دستور، خروجی را مستقیم به فرمت تحویل کدگذاری کن. فایل واسط نساز.
۳. زیر دستور، در یک خط بگو هر گزینه چه می کند.
۴. اگر بلندی اندازه گیری شده از هدف خیلی دور است، بگو چقدر گین لازم می شود و هشدار بده که کف نویز هم به همان اندازه بالا می آید.
۵. دستور اندازه گیری دوباره روی فایل خروجی را هم بنویس تا خودم چک کنم.قبل از اعتماد به خروجی: یکدست کردن بلندی، کیفیت نیست. اتاق پر پژواک بعد از این کار هم پر پژواک است، و بالا بردن یک ضبط کم جان، کف نویزش را هم با خودش بالا می آورد. دو چیز را هم هرگز نکنید: نسخه آرشیو را نرمالایز نکنید، فقط نسخه تحویل را؛ و خروجی loudnorm را دوباره از فیلتر رد نکنید، چون هر بار عبور یک کدگذاری اضافه است.
هوش مصنوعی در این کار
صدا برخلاف فرمت تصویر، حوزه ای است که هوش مصنوعی واقعا در آن چیزی عوض کرده: پیاده سازی متن، تمیز کردن گفتار و تولید صدا از متن، هر سه امروز کار می کنند. ولی انتخاب فرمت هنوز حساب و کتاب است و نه سلیقه مدل، و جایی که همه چیز خراب می شود ابزارهایی هستند که ادعا می کنند صدای بد را خوب می کنند.
ابزارهایی که واقعا کمک می کنند
- ElevenLabs برای تبدیل متن به گفتار و دوبله. رتبه بندی مدل هایش با معیار فارسی خواندن در همین سایت هست. بند کنترل صادرات شرایط استفاده خودشان ایران را به اسم می آورد، پس ثبت نام و پرداخت رسمی از ایران وجود ندارد.
- Claude برای ساختن زنجیره فیلترهای ffmpeg و پر کردن مقدارهای اندازه گیری شده در مرحله دوم loudnorm، چون توضیحش را می شود با مستندات فیلتر مقایسه کرد. ایران در فهرست کشورهای پشتیبانی شده انتروپیک نیست.
- FFmpeg هوش مصنوعی نیست و عمدا در فهرست است. اندازه گیری بلندی، تبدیل فرمت و تک کاناله کردن گفتار، هر سه با یک خط دستور انجام می شوند و هیچ مدلی لازم ندارند.
- RGB لایه دسترسی و پرداخت برای ایران، جدا از خود ابزارها.
کجا نتیجه معکوس می دهد
ابزارهای «بهبود» صدا همان کاری را می کنند که همتای تصویری شان: چیزی را که ضبط نشده بازنمی گردانند، بلکه محتمل ترین حدس را جای آن می گذارند. برای یک تیزر مهم نیست. برای مصاحبه، رضایت نامه مشتری، جلسه ضبط شده یا هر فایلی که قرار است سند باشد، نسخه بهبود یافته دیگر همان ضبط اصلی نیست و باید در پرونده مشخص باشد کدام فایل مستر است و کدام پردازش شده. ریسک دوم، مسیر برعکس است: کدگذاری دوباره واترمارک صدای هوش مصنوعی را پاک نمی کند. گوگل درباره SynthID می نویسد واترمارک صوتی اش با تغییرهای رایج مثل اضافه کردن نویز، فشرده سازی MP3 یا تغییر سرعت از بین نمی رود. و ریسک سوم که فنی نیست ولی همه چیز را خراب می کند: کلون کردن صدای یک آدم واقعی بدون اجازه کتبی خودش. این قبل از اینکه یک سوال فنی باشد یک سوال قراردادی است، و جوابش را باید قبل از ضبط گرفت نه بعد از انتشار.
منبع ها: MDN: Web audio codec guide Opus Interactive Audio Codec Google DeepMind: SynthID ElevenLabs Terms of Use
حد این توصیه
فرمت آخرین تصمیم است، نه اولی. اتاق، میکروفن و فاصله دهان تا میکروفن تقریبا همیشه بیشتر از انتخاب کدک روی نتیجه اثر دارند، و هیچ فرمتی صدای ضبط شده در اتاق پر پژواک را نجات نمی دهد. بدون اتلاف هم به معنی خوش صداتر نیست؛ به معنی برگشت پذیر است. اگر روی دستگاه مقصد فرقی نمی شنوید، برای تحویل به فایل بدون اتلاف نیاز ندارید و فقط پهنای باند خرج می کنید. و مثل هر صفحه ای که فهرست پشتیبانی مرورگر دارد، ستون های این جدول در تاریخ بالای صفحه از منابعشان خوانده شده اند و امروز باید دوباره از خود آن منبع خوانده شوند.
از تجربه خود ما
دو ادعای این درس را روی همین سرور اندازه گرفتیم، با ffmpeg نسخه 6.1.1 و در تاریخ بالای همین صفحه. اول حساب WAV: یک فایل سی ثانیه ای با نرخ 44100 و عمق ۱۶ بیت و دو کانال ساختیم و اندازه اش شد 5292078 بایت، در حالی که حاصل ضرب 44100 در ۱۶ در ۲ تقسیم بر ۸ و ضربدر ۳۰ می شود 5292000. یعنی کل فایل جز ۷۸ بایت هدر، همان حساب است و نه چیز دیگری. دوم معنی «بدون اتلاف»: همان فایل را به FLAC و MP3 و Opus و AAC تبدیل کردیم و بعد هر پنج تا را به نمونه های خام برگرداندیم و md5 گرفتیم. WAV و FLAC هر دو 1671d60e646f0e771bbf874a6a5db852 دادند، یعنی بایت به بایت یکی. هر سه فایل با اتلاف سه md5 متفاوت دادند. این تنها آزمایشی است که به گوش احتیاج ندارد و جواب قطعی می دهد.
سوال هایی که واقعا پرسیده می شوند
فرق MP3 و WAV چیست؟
WAV چیزی را فشرده نمی کند و نمونه ها را همان طور که ضبط شده اند نگه می دارد، پس بزرگ است و برای ضبط و تدوین درست است. MP3 با اتلاف فشرده می کند و بخشی از سیگنال را برای همیشه دور می ریزد، پس کوچک است و برای انتشار درست است. مسیر درست از اولی به دومی است و هیچ وقت برعکس.
Opus بهتر است یا MP3؟
از نظر فنی Opus جوان تر است، بدون حق امتیاز است، از بیت ریت های خیلی پایین تر شروع می شود و کمترین تاخیر را بین کدک های همه منظوره دارد. ولی MP3 عملا همه جا پخش می شود و بعضی پلتفرم ها هنوز فقط همان را می پذیرند. اگر مقصد را خودتان تعیین می کنید Opus، و اگر نه MP3.
برای پادکست چه بیت ریتی بگذارم؟
عددش را مشخصات همان جایی که فایل را آپلود می کنید تعیین می کند، نه یک قاعده عمومی. ولی دو چیز تقریبا همیشه صادق است: گفتار به بیت ریت خیلی کمتری از موسیقی نیاز دارد، و یک صدای تک نفره را تک کاناله بفرستید نه استریو، چون استریو حجم را دو برابر می کند بدون اینکه چیزی اضافه کند.