-->

آموزش کاهش حجم آرشیو موسیقی با FFmpeg

آموزش عملی و تجربی کاهش حجم آرشیو موسیقی با FFmpeg؛ مقایسه MP3، AAC و Opus با داریوش حقیقی!  چند روز پیش زمانی که آرشیو موسیقی شخصی خودم را چک و مرتب می‌کردم، متوجه شدم حجم آن کم کم  از چند صد گیگابایت عبور کرده و اکنون به حدود ۴ تا ۵ ترابایت رسیده است. بخش بزرگی از این آرشیو شامل فایل‌های MP3 با نرخ بیت ۳۲۰ کیلوبیت بر ثانیه هست و یا حتی فایل های Flac  حجیم؛ فایل‌هایی که طی سال‌ها از منابع مختلف جمع‌آوری شدند و از نظر کیفیت، انتخاب بسیار مناسبی محسوب می‌شدند. اما افزایش ظرفیت آرشیو تنها به معنای اشغال فضای ذخیره‌سازی نبود. تهیه نسخه پشتیبان، انتقال اطلاعات میان هارددیسک‌ها، همگام‌سازی با NAS و حتی کپی کردن آرشیو روی یک SSD جدید نیز به مرور زمان به فرایندی زمان‌بر و پرهزینه تبدیل میشه.
در همین نقطه این سؤال برایم ایجاد شد که آیا واقعاً لازم است همه فایل‌ها همچنان با همین حجم باقی بمانند یا می‌توان بدون افت محسوس کیفیت، فضای اشغال‌شده را به میزان قابل توجهی کاهش داد. در نگاه اول شاید پاسخ ساده به نظر برسد؛ کافی است فایل‌ها را با یک کدک جدید دوباره Encode کنیم. اما هر کسی که تجربه کار حرفه‌ای با فایل‌های صوتی را داشته باشد می‌داند این تصمیم به همین سادگی نیست. کاهش حجم تقریباً همیشه با نوعی افت کیفیت همراه است و اگر این فرایند بدون برنامه انجام شود، ممکن است نتیجه نهایی دیگر قابل بازگشت نباشد. از طرف دیگر، تبدیل چند ترابایت فایل صوتی می‌تواند روزها یا حتی هفته‌ها زمان پردازشی مصرف کند. بنابراین پیش از اجرای هرگونه تبدیل انبوه، لازم بود یک پروژه آزمایشی طراحی شود تا همه تصمیم‌ها بر اساس اندازه‌گیری، تحلیل و شنیدن واقعی گرفته شوند، نه صرفاً بر اساس تبلیغات یا تجربه دیگران.

حواستون باشه!

هدف این پروژه پیدا کردن «بهترین کدک دنیا» نیست. هدف این است که مشخص شود برای یک آرشیو واقعی چند ترابایتی، کدام گزینه بهترین تعادل میان حجم فایل، کیفیت شنیداری، سازگاری نرم‌افزاری و زمان پردازش را ایجاد می‌کند.

آموزش کاهش حجم آرشیو موسیقی با FFmpeg
آموزش کاهش حجم آرشیو موسیقی با FFmpeg

اینم بگم  که این نتیجه برای من در این تاریخ قابل قبول هست ولی برای چند سال دیگه ممکنه گزینه خوبی نباشه. مورد بعدی اینکه من حدود 20 ساعت زمان برای رسیدن به نتیجه ای که براتون گذاشتم زمان صرف کردم و تست های زیادی انجام دادم پس اگر به کارتون اومد لطفا یک تشکری لایکی چیزی در کنید از خودتون.

هدف پروژه

برخلاف بسیاری از مقالات اینترنتی که تنها چند نمودار یا جدول مقایسه ارائه می‌کنند، این مقاله روند واقعی تصمیم‌گیری یک پروژه داریوش را مستند می‌کند. از انتخاب فایل نمونه گرفته تا بررسی مشخصات آن، تبدیل با FFmpeg، تحلیل خروجی، مقایسه حجم، بررسی نرخ بیت و در نهایت تصمیم‌گیری برای آینده یک آرشیو چند ترابایتی، همه مراحل دقیقاً همان ترتیبی را دنبال می‌کنند که در پروژه واقعی انجام شده‌اند. بنابراین اگر در طول مقاله با دستورهای FFmpeg روبه‌رو می‌شوید، این دستورها صرفاً مثال آموزشی نیستند؛ بلکه همان فرمان‌هایی هستند که در این پروژه مورد استفاده قرار گرفته‌اند. البته چند بار این تست ها را انجام دادم ولی مستندات بر اساس آخرین تست و موثق ترینشون نوشته شده.

سؤال اصلی پروژه نیز بسیار مشخص است. اگر امروز یک آرشیو چند ترابایتی از فایل‌های MP3 با کیفیت ۳۲۰ کیلوبیت بر ثانیه  یا بیشتر داشته باشیم (مثثل اکثر فایل هایی که از سایت ها یا تلگرام یا .. میگیریم) ، آیا تبدیل آن به AAC یا Opus تصمیم منطقی خواهد بود؟ اگر پاسخ مثبت است، چه میزان فضا ذخیره می‌شود؟ کیفیت تا چه اندازه تغییر می‌کند؟ آیا فایل‌ها همچنان روی اکثر دستگاه‌ها قابل پخش خواهند بود؟ و آیا زمانی که برای تبدیل هزاران فایل صرف می‌شود ارزش این صرفه‌جویی را دارد؟ تمام بخش‌های بعدی مقاله برای پاسخ دادن به همین پرسش طراحی شده‌اند. البته الان که دارم من مقاله رو میزارم آرشیو رو گذاشتم برای تبدیل و زمان حدودی رو بعدا بعد از اتمام و تست اضافه میکنم.

چرا MP3، AAC و Opus؟

در این پروژه تنها سه فرمت صوتی بررسی می‌شوند؛ MP3، AAC و Opus. دلیل انتخاب آن‌ها نیز کاملاً بر اساس تجربیات و همچنین استانداردهای 2026 هست . MP3 همچنان رایج‌ترین فرمت آرشیو موسیقی در دنیا محسوب می‌شود و تقریباً روی هر سیستم‌عامل، نرم‌افزار و سخت‌افزاری قابل پخش است. AAC نسل جدیدتری از کدک‌های فشرده‌سازی صوتی به شمار می‌رود و سال‌هاست در سرویس‌هایی مانند Apple Music و بسیاری از دستگاه‌های همراه مورد استفاده قرار می‌گیرد. Opus نیز جدیدترین عضو این مقایسه است؛ کدکی که با هدف دستیابی به کیفیت بالاتر در نرخ بیت یا همون bitrate پایین‌تر طراحی شده و امروزه در بسیاری از سرویس‌های اینترنتی، ارتباطات صوتی و حتی برخی سرویس‌های استریم استفاده می‌شود.

مقایسه MP3، AAC و Opus در پروژه کاهش حجم آرشیو موسیقی با FFmpeg، بررسی فشرده‌سازی، نرخ بیت، صرفه‌جویی در فضای ذخیره‌سازی و انتخاب فرمت مناسب.
مقایسه MP3، AAC و Opus در پروژه کاهش حجم آرشیو موسیقی با FFmpeg، بررسی فشرده‌سازی، نرخ بیت، صرفه‌جویی در فضای ذخیره‌سازی و انتخاب فرمت مناسب.

من در این مقاله قصد ندام وارد جزئیات کامل تاریخچه، الگوریتم‌های فشرده‌سازی یا ساختار داخلی هر کدک شوم، زیرا هر کدام از این موضوعات ارزش یک مقاله مستقل را دارند. در این پروژه تنها آن بخش‌هایی بررسی می‌شوند که مستقیماً روی تصمیم نهایی ما برای کاهش حجم آرشیو تأثیر می‌گذارند. هر جا نیاز به توضیح عمیق‌تر وجود داشته باشد، آن موضوع به مقالات تخصصی آینده مجموعه FFmpeg ارجاع داده خواهد شد.

چرا FFmpeg و FFprobe؟

برای انجام چنین پروژه‌ای ابزارهای مختلفی وجود دارند، اما FFmpeg انتخاب طبیعی این آزمایش بود و آموزش FFMPEG رو هم قبلا قرار دادم. دلیل این انتخاب تنها رایگان یا متن‌باز بودن آن نیست. FFmpeg تقریباً از تمام کدک‌های مهم پشتیبانی می‌کند، امکان کنترل دقیق پارامترهای Encode را در اختیار کاربر قرار می‌دهد، اطلاعات فایل‌ها را با ابزار FFprobe استخراج می‌کند و در محیط‌های ویندوز، لینوکس و macOS رفتار تقریباً یکسانی دارد. مهم‌تر از همه اینکه همین ابزار در بسیاری از نرم‌افزارهای حرفه‌ای و سرویس‌های پردازش رسانه نیز به عنوان موتور اصلی تبدیل فایل‌ها مورد استفاده قرار می‌گیرد.

از آنجا که هدف این پروژه تنها تبدیل چند فایل نمونه نیست و در صورت موفقیت قرار است هزاران فایل صوتی پردازش شوند، استفاده از ابزاری قابل اسکریپت‌نویسی اهمیت زیادی دارد. FFmpeg این امکان را فراهم می‌کند که پس از پایان مرحله آزمایش، همان فرمان‌ها بدون تغییر اساسی در قالب Batch یا PowerShell روی کل آرشیو اجرا شوند. به همین دلیل تمام آزمایش‌های این مقاله از ابتدا بر پایه FFmpeg طراحی شده‌اند. البته به دیل کیفیت پایین تر انکودر پیش فرض FFMPEG از QAAC برای تبدیل فرمت AAC استفاده کردم که نتیجه بهتری میداد.

قبل از تبدیل

یکی از رایج‌ترین اشتباهات هنگام کاهش حجم آرشیو، شروع فوری عملیات Encode است. بسیاری از کاربران پوشه‌ای شامل هزاران فایل را انتخاب می‌کنند، یک Preset آماده را اجرا می‌کنند و امیدوارند نتیجه مطلوب باشد. اگر بعداً مشخص شود کیفیت قابل قبول نیست یا بخشی از اطلاعات فایل‌ها از بین رفته است، بازگشت به وضعیت اولیه تنها در صورتی امکان‌پذیر خواهد بود که نسخه اصلی هنوز نگهداری شده باشد. در پروژه‌ای با حجم چند ترابایت، چنین اشتباهی می‌تواند روزها زمان و چندین ترابایت فضای ذخیره‌سازی را هدر دهد.

به همین دلیل این پروژه با تبدیل انبوه آغاز نمی‌شود. ابتدا تنها یک فایل به عنوان نمونه انتخاب می‌شود. سپس مشخصات دقیق آن بررسی خواهد شد، خروجی کدک‌های مختلف روی همان فایل مقایسه می‌شود، حجم و کیفیت آن‌ها اندازه‌گیری خواهد شد و تنها زمانی که نتیجه رضایت‌بخش باشد، درباره اجرای پروژه روی کل آرشیو تصمیم‌گیری می‌کنیم. این رویکرد شاید در ابتدا زمان بیشتری صرف کند، اما در پروژه‌های بزرگ تقریباً همیشه کم‌هزینه‌ترین و مطمئن‌ترین روش است.

تصمیم این مرحله

در پایان مرحله اول هنوز هیچ فایل صوتی تبدیل نشده است. ابتدا باید یک فایل نماینده از آرشیو انتخاب کنیم و مشخصات واقعی آن را با FFprobe بررسی کنیم. بدون شناخت فایل مبدا، هیچ تصمیم داریوش درباره کدک مقصد قابل اعتماد نخواهد بود و هر نتیجه‌ای بیشتر به حدس شباهت خواهد داشت تا یک ارزیابی فنی.

انتخاب فایل نمونه

پس از مشخص شدن هدف پروژه، نوبت به انتخاب یک فایل نمونه رسید. شاید این مرحله در نگاه اول ساده به نظر برسد، اما در عمل یکی از مهم‌ترین تصمیم‌های کل پروژه است. اگر فایل انتخاب‌شده نماینده مناسبی از آرشیو نباشد، تمام نتایج بعدی نیز اعتبار خود را از دست خواهند داد. برای مثال، آزمایش روی یک قطعه آکوستیک آرام نمی‌تواند رفتار کدک را هنگام فشرده‌سازی موسیقی راک یا الکترونیک نشان دهد. به همین دلیل تصمیم گرفتم تنها یک فایل را به‌صورت آزمایشی انتخاب کنم، اما این فایل باید از نظر ساختار صوتی، کیفیت ضبط و پیچیدگی موسیقی بتواند نماینده بخش بزرگی از آرشیو باشد. هدف این مرحله پیدا کردن بهترین آهنگ دنیا نبود؛ هدف انتخاب فایلی بود که بتواند مبنای تصمیم‌گیری داریوش قرار گیرد.

این مورد را هم اینجا اشاره کنم که اکثر آرشیو موسیقی من در سبک ROCK/METAL هست و این سبک بیت ریت بالاتری نسبت به سبک های موسیقی آروم تر میطلبه لذا حجم فایل هاشم بیشتر هست. اگر سبک های آروم و بیت ریت پایین تر داشته باشید حجم کاهش یافته ممکنه تا دو برابر این مقدار باشه.

فایل انتخاب‌شده نسخه ۳۲۰ کیلوبیت بر ثانیه آهنگ A Perfect Circle - Starless بود. این فایل از نظر مدت زمان، دامنه فرکانسی، وجود سازهای مختلف، وکال و بخش‌های آرام و پرانرژی گزینه مناسبی برای شروع آزمایش محسوب می‌شد. طبیعتاً نتیجه این آزمایش به معنای رفتار تمام فایل‌های موسیقی نیست، اما اگر یک کدک بتواند روی چنین نمونه‌ای عملکرد رضایت‌بخشی داشته باشد، احتمال موفقیت آن روی بخش بزرگی از آرشیو نیز افزایش پیدا می‌کند. در ادامه تمام تبدیل‌ها، اندازه‌گیری‌ها و مقایسه‌ها روی همین فایل انجام خواهند شد تا شرایط آزمایش برای همه کدک‌ها یکسان باقی بماند.

پیشنهاد داریوش

در پروژه‌های واقعی همیشه ابتدا یک نمونه کوچک انتخاب می‌شود. این روش باعث می‌شود مشکلات احتمالی قبل از اجرای پردازش روی هزاران فایل شناسایی شوند و در صورت نیاز بتوان تنظیمات Encode را بدون اتلاف زمان اصلاح کرد. شما هم خواستید یک کپی 100 عددی از فایل هاتون بگیرید تست روش انجام بدید بعد اگر راضی بودید برید سراغ آرشیو اصلی. البته کد هایی که استفاده شده نسخه اصلی را حذف نمیکنند و امن هستند.

چرا فایل را بررسی کنیم؟

قبل از اینکه حتی یک بار دستور FFmpeg را اجرا کنیم، لازم است بدانیم دقیقاً با چه فایلی سروکار داریم. بسیاری از کاربران تنها به پسوند فایل نگاه می‌کنند و فرض می‌کنند همه چیز مشخص است، اما پسوند تنها نام فایل را نشان می‌دهد و اطلاعات واقعی درون آن قرار دارد. ممکن است دو فایل هر دو پسوند MP3 داشته باشند، اما نرخ بیت، نرخ نمونه‌برداری، تعداد کانال‌ها یا حتی وجود Album Art در آن‌ها کاملاً متفاوت باشد. اگر این اطلاعات از ابتدا بررسی نشوند، ممکن است هنگام تبدیل، بخشی از ویژگی‌های فایل اصلی ناخواسته از بین بروند یا نتیجه نهایی با انتظار ما تفاوت داشته باشد.

در این پروژه هدف تنها کاهش حجم نیست. ما می‌خواهیم تا حد امکان کیفیت اصلی و  اطلاعات ارزشمند فایل نیز حفظ شوند. به همین دلیل پیش از هر Encode، ابتدا فایل مبدا با FFprobe بررسی می‌شود. این ابزار اطلاعاتی را استخراج می‌کند که برای تصمیم‌گیری این پروژه ضروری هستند؛ مانند نوع کدک، نرخ نمونه‌برداری، تعداد کانال‌ها، نرخ بیت و همچنین وجود جریان‌های جانبی مانند Album Art. در این مقاله فقط همین اطلاعات بررسی می‌شوند و وارد جزئیات کامل ساختار خروجی FFprobe نخواهیم شد، زیرا آن موضوع در یک مقاله مستقل به‌طور کامل پوشش داده خواهد شد.

همینطور فایل های MP3 تگ های مربوط به خودشون رو دارند که اطلاعات موزیک نظیر آلبوم، سال؛ خواننده و … داخلشون ذخیره میشه و من یکی از هدف های اصلیم انتقال کامل این موارد به فرمت های خروجی و نهایی هست که چیزی رو از دست ندیم.

اجرای FFprobe

برای استخراج اطلاعات فایل، از یک اسکریپت PowerShell استفاده شد تا بتوان همان بررسی را بعداً روی فایل‌های دیگر نیز تکرار کرد. این اسکریپت ابتدا مسیر FFprobe را مشخص می‌کند، سپس همه فایل‌های MP3، AAC و Opus موجود در پوشه را پیدا می‌کند و اطلاعات مهم هر فایل را نمایش می‌دهد. استفاده از اسکریپت به جای اجرای دستی فرمان باعث می‌شود نتایج قابل تکرار باشند و در مراحل بعدی پروژه نیز بدون تغییر قابل استفاده باقی بمانند.

$FFprobe = "C:\D\ffmpeg\ffprobe.exe"

Get-ChildItem -File *.mp3,*.m4a,*.opus | ForEach-Object {

    Write-Host ""
    Write-Host "==================================================" -ForegroundColor Cyan
    Write-Host "File: $($_.Name)"
    Write-Host "Size: $([math]::Round($_.Length / 1MB,2)) MB"
    Write-Host "=================================================="

    & $FFprobe `
        -v error `
        -show_entries format=filename,duration,size,bit_rate:stream=codec_name,codec_long_name,profile,sample_rate,channels,channel_layout,bit_rate `
        -of default=noprint_wrappers=1 `
        $_.FullName
}

در نگاه اول ممکن است این دستور طولانی به نظر برسد، اما در واقع تنها اطلاعاتی را درخواست می‌کند که برای این پروژه لازم هستند. به جای نمایش صدها فیلد مختلف، خروجی به چند مشخصه کلیدی محدود شده است تا مقایسه فایل‌ها ساده‌تر شود. همین رویکرد باعث می‌شود هنگام بررسی صدها یا هزاران فایل، خروجی خواناتر باشد و اطلاعات اضافی تمرکز ما را از تصمیم داریوش دور نکند.

اولین مشاهده

پس از اجرای اسکریپت، اطلاعات چهار فایل نمایش داده شدند؛ فایل MP3 اصلی با نرخ بیت ۳۲۰ کیلوبیت بر ثانیه، نسخه MP3 تبدیل‌شده، نسخه AAC و نسخه Opus. اولین نکته‌ای که بلافاصله جلب توجه می‌کند، کاهش قابل توجه حجم فایل‌ها است. فایل اصلی حدود ۱۰٫۶۳ مگابایت حجم دارد، در حالی که سه فایل تبدیل‌شده همگی در محدوده ۵ مگابایت قرار گرفته‌اند. این یعنی تنها با یک بار Encode تقریباً نیمی از فضای ذخیره‌سازی آزاد شده است. البته کاهش حجم به‌تنهایی معیار موفقیت نیست و هنوز باید بررسی کنیم این صرفه‌جویی چه تأثیری بر کیفیت شنیداری و سایر ویژگی‌های فایل گذاشته است.


==================================================
File: A Perfect Circle-Starless-Starless-320.mp3
Size: 10.63 MB
==================================================

codec_name: mp3
codec_long_name: MP3 (MPEG audio layer 3)
profile: unknown
sample_rate: 44100 Hz
channels: 2
channel_layout: stereo
bit_rate: 320000

codec_name: mjpeg
codec_long_name: Motion JPEG
profile: Baseline
bit_rate: N/A

filename:
E:\IDM\test\A Perfect Circle-Starless-Starless-320.mp3

duration: 272.613878 seconds
size: 11149959 bytes
bit_rate: 327201


==================================================
File: A Perfect Circle-Starless-Starless.mp3
Size: 4.98 MB
==================================================

codec_name: mp3
codec_long_name: MP3 (MPEG audio layer 3)
profile: unknown
sample_rate: 44100 Hz
channels: 2
channel_layout: stereo
bit_rate: 146293

codec_name: mjpeg
codec_long_name: Motion JPEG
profile: Baseline
bit_rate: N/A

filename:
E:\IDM\test\A Perfect Circle-Starless-Starless.mp3

duration: 272.613878 seconds
size: 5217299 bytes
bit_rate: 153104


==================================================
File: A Perfect Circle-Starless-Starless.m4a
Size: 5.32 MB
==================================================

codec_name: aac
codec_long_name: AAC (Advanced Audio Coding)
profile: LC
sample_rate: 44100 Hz
channels: 2
channel_layout: stereo
bit_rate: 155318

codec_name: mjpeg
codec_long_name: Motion JPEG
profile: Baseline
bit_rate: N/A

filename:
E:\IDM\test\A Perfect Circle-Starless-Starless.m4a

duration: 272.623991 seconds
size: 5573196 bytes
bit_rate: 163542


==================================================
File: A Perfect Circle-Starless-Starless.opus
Size: 5.05 MB
==================================================

codec_name: opus
codec_long_name: Opus (Opus Interactive Audio Codec)
profile: unknown
sample_rate: 48000 Hz
channels: 2
channel_layout: stereo
bit_rate: N/A

filename:
E:\IDM\test\A Perfect Circle-Starless-Starless.opus

duration: 272.620396 seconds
size: 5297331 bytes
bit_rate: 155449    

نکته جالب دیگر این است که هر سه فایل تقریباً مدت زمان یکسانی دارند و اختلاف آن‌ها تنها چند هزارم ثانیه است. این موضوع نشان می‌دهد عملیات Encode باعث کوتاه یا بلند شدن محسوس فایل نشده و همه نسخه‌ها از نظر طول پخش تقریباً معادل فایل اصلی هستند. همین مشاهده ساده اولین نشانه موفقیت مرحله تبدیل محسوب می‌شود، هرچند هنوز برای نتیجه‌گیری نهایی زود است و باید مشخصات هر کدک را جداگانه بررسی کنیم.

جمع‌بندی مرحله

تا اینجا هیچ قضاوتی درباره بهترین کدک انجام نشده است. تنها کاری که انجام دادیم انتخاب یک فایل نماینده، استخراج مشخصات واقعی آن و بررسی اولیه نتایج تبدیل بود. در مرحله بعد، هر بخش از خروجی FFprobe را به اندازه‌ای که برای این پروژه لازم است تحلیل می‌کنیم و بر اساس همان اطلاعات تصمیم می‌گیریم که آیا فایل‌ها برای مقایسه عملی آماده هستند یا خیر.

تحلیل خروجی

اکنون زمان آن رسیده است که خروجی FFprobe را با دقت بیشتری بررسی کنیم. هدف ما آموزش کامل FFprobe نیست، بلکه می‌خواهیم بدانیم هر کدام از اطلاعات نمایش داده‌شده چه نقشی در تصمیم نهایی این پروژه دارند. اگر هنگام بررسی خروجی به هر گزینه‌ای بدون دلیل توجه کنیم، تحلیل بیش از حد پیچیده خواهد شد. از طرف دیگر، اگر برخی اطلاعات مهم را نادیده بگیریم، ممکن است تصمیم اشتباهی برای کل آرشیو گرفته شود. بنابراین در این مرحله تنها روی فیلدهایی تمرکز می‌کنیم که مستقیماً بر کیفیت، حجم یا سازگاری فایل‌ها اثر می‌گذارند. سایر بخش‌های خروجی مانند ساختار کامل Streamها یا اطلاعات پیشرفته Container را در مقالات تخصصی آینده بررسی خواهیم کرد.

در خروجی این پروژه چند ویژگی تقریباً در تمام فایل‌ها مشترک هستند. همه فایل‌ها دو کاناله (Stereo) هستند، نرخ نمونه‌برداری آن‌ها برای MP3 و AAC برابر ۴۴۱۰۰ هرتز است و تنها نسخه Opus با نرخ نمونه‌برداری ۴۸۰۰۰ هرتز گزارش می‌شود. همچنین در سه فایل نخست یک Stream دیگر با کدک MJPEG مشاهده می‌شود که در واقع تصویر جلد آلبوم است. همین چند مشاهده ساده، قبل از آنکه حتی به کیفیت صدا گوش کنیم، اطلاعات ارزشمندی درباره فایل‌ها در اختیار ما قرار می‌دهد.

کدک صوتی

اولین فیلدی که بررسی می‌کنیم codec_name است. این فیلد مشخص می‌کند داده صوتی واقعاً با چه کدکی ذخیره شده است. در فایل اصلی مقدار MP3 نمایش داده می‌شود، نسخه AAC مقدار AAC و نسخه سوم Opus را گزارش می‌کند. شاید این موضوع بدیهی به نظر برسد، اما در پروژه‌های واقعی همیشه نباید به پسوند فایل اعتماد کرد. گاهی فایل‌ها تغییر نام داده می‌شوند یا پسوند آن‌ها با محتوای واقعی مطابقت ندارد. بررسی کدک واقعی قبل از Encode باعث می‌شود بدانیم نقطه شروع پروژه دقیقاً چیست و از تبدیل اشتباه فایل‌ها جلوگیری شود.

در همین بخش نام کامل کدک نیز نمایش داده می‌شود. این اطلاعات بیشتر برای خوانایی خروجی مفید هستند و در تصمیم داریوش تأثیر مستقیمی ندارند. چیزی که برای این پروژه اهمیت دارد، این است که مطمئن شویم فایل مبدا همان MP3 مورد انتظار است و فایل‌های خروجی نیز واقعاً با کدک مقصد تولید شده‌اند. در ادامه مقاله تمرکز اصلی روی رفتار همین سه کدک خواهد بود، نه روی نام یا تاریخچه آن‌ها.

نرخ نمونه‌برداری

یکی دیگر از اطلاعات مهم خروجی، نرخ نمونه‌برداری یا sample_rate است. فایل اصلی MP3 و نسخه AAC هر دو با نرخ ۴۴۱۰۰ هرتز ثبت شده‌اند، در حالی که نسخه Opus مقدار ۴۸۰۰۰ هرتز را نمایش می‌دهد. اگر برای اولین بار با این تفاوت روبه‌رو شوید، ممکن است تصور کنید Opus کیفیت بالاتری تولید کرده است، اما در واقع چنین نتیجه‌ای از روی این عدد قابل برداشت نیست. این تفاوت به نحوه طراحی کدک Opus مربوط می‌شود و به معنی افزایش کیفیت فایل نسبت به منبع اصلی نیست.

در این پروژه همین مقدار دانستن کافی است، زیرا هدف ما مقایسه حجم و کیفیت شنیداری است، نه بررسی کامل مفاهیم پردازش سیگنال دیجیتال. بنابراین از اینجا نتیجه می‌گیریم که مشاهده نرخ ۴۸ کیلوهرتز در فایل Opus رفتار طبیعی این کدک است و به‌تنهایی نه یک مزیت محسوب می‌شود و نه یک ایراد. جزئیات بیشتر درباره نرخ نمونه‌برداری و تأثیر آن بر کیفیت صدا را در مقاله‌ای جداگانه بررسی خواهیم کرد.

کانال‌های صوتی

در هر چهار فایل مقدار channels=2 و channel_layout=stereo مشاهده می‌شود. این موضوع نشان می‌دهد ساختار کانال‌های صوتی پس از تبدیل تغییر نکرده است. اگر هنگام Encode تعداد کانال‌ها به Mono کاهش پیدا می‌کرد، حجم فایل کمتر می‌شد، اما چنین مقایسه‌ای دیگر منصفانه نبود، زیرا بخشی از اطلاعات صوتی حذف شده بود. هدف این پروژه مقایسه کدک‌ها در شرایط یکسان است و به همین دلیل تعداد کانال‌ها در همه نسخه‌ها ثابت نگه داشته شده است.

حفظ ساختار Stereo یک نکته مهم دیگر نیز دارد. بسیاری از قطعات موسیقی از جداسازی کانال چپ و راست برای ایجاد فضای صوتی استفاده می‌کنند. اگر این ویژگی هنگام تبدیل تغییر کند، شنونده ممکن است تفاوت را حتی بدون تجهیزات حرفه‌ای احساس کند. بنابراین مشاهده یکسان بودن تعداد کانال‌ها، یکی از اولین مواردی است که اطمینان می‌دهد شرایط مقایسه همچنان عادلانه باقی مانده است.

نرخ بیت

شاید مهم‌ترین عددی که بیشتر کاربران به آن نگاه می‌کنند، مقدار bit_rate باشد. فایل اصلی دارای نرخ بیت ثابت ۳۲۰۰۰۰ بیت بر ثانیه است که همان MP3 320kbps شناخته‌شده محسوب می‌شود. نسخه AAC حدود ۱۵۵ کیلوبیت بر ثانیه گزارش شده و فایل Opus نیز در مجموع حدود ۱۵۵ کیلوبیت بر ثانیه حجم داده تولید کرده است. نسخه MP3 تبدیل‌شده نیز میانگینی در حدود ۱۴۶ کیلوبیت بر ثانیه دارد. همین اعداد نشان می‌دهند که هر سه فایل تقریباً با نصف حجم فایل اصلی تولید شده‌اند.

البته باید دقت داشت که این اعداد همیشه کل داستان را تعریف نمی‌کنند. کیفیت شنیداری تنها به نرخ بیت وابسته نیست و الگوریتم فشرده‌سازی هر کدک نیز نقش مهمی در نتیجه نهایی دارد. به همین دلیل در ادامه مقاله تنها به مشاهده این اعداد اکتفا نمی‌کنیم و فایل‌ها را از نظر حجم، کیفیت و تجربه شنیداری نیز با یکدیگر مقایسه خواهیم کرد. تصمیم نهایی زمانی گرفته می‌شود که همه این عوامل کنار هم بررسی شوند.

کاور آلبوم

یکی از نکات جالب خروجی این پروژه، مشاهده یک Stream دیگر با کدک mjpeg در فایل‌های MP3 و AAC است. این Stream در واقع داده صوتی نیست، بلکه تصویر جلد آلبوم یا Album Art را نگهداری می‌کند. وجود این اطلاعات نشان می‌دهد فایل اصلی تنها شامل موسیقی نبوده و اطلاعات جانبی نیز در آن ذخیره شده است. اگر هنگام تبدیل این داده‌ها حفظ نشوند، ممکن است فایل جدید در نرم‌افزارهای پخش موسیقی بدون تصویر جلد نمایش داده شود.

در این مقاله وارد جزئیات کامل Metadata و Album Art نمی‌شویم، زیرا هر دو موضوع ارزش یک مقاله مستقل را دارند. تنها نکته‌ای که برای این پروژه اهمیت دارد این است که هنگام طراحی فرمان‌های FFmpeg باید به حفظ این اطلاعات نیز توجه کنیم. کاهش حجم آرشیو نباید به قیمت از دست رفتن اطلاعات مفیدی باشد که سال‌ها همراه فایل‌ها نگهداری شده‌اند.

تصمیم این مرحله

بررسی فایل نمونه نشان داد که منبع آزمایش یک MP3 استاندارد ۳۲۰kbps با نرخ نمونه‌برداری ۴۴٫۱ کیلوهرتز، صدای Stereo و تصویر جلد آلبوم است. همچنین نسخه‌های تبدیل‌شده بدون تغییر در مدت زمان فایل تولید شده‌اند و حجم آن‌ها تقریباً به نصف کاهش یافته است. بنابراین اکنون می‌توانیم وارد مرحله اصلی پروژه شویم و اولین عملیات Encode را با AAC انجام دهیم تا مشخص شود این کاهش حجم در عمل چه نتیجه‌ای ایجاد می‌کند.

اولین تبدیل

تا اینجا هنوز هیچ نتیجه‌ای درباره برتری یک کدک نسبت به دیگری نگرفته‌ایم. تنها مطمئن شدیم که فایل مبدا برای آزمایش مناسب است و اطلاعات لازم را در اختیار داریم. اکنون زمان آن رسیده است که اولین Encode واقعی را انجام دهیم. برای شروع، تصمیم گرفتم AAC را انتخاب کنم. دلیل این انتخاب ساده بود؛ AAC سال‌هاست به عنوان جانشین MP3 شناخته می‌شود، تقریباً روی تمام سیستم‌عامل‌های مدرن و دستگاه‌های همراه پشتیبانی می‌شود و در بسیاری از سرویس‌های موسیقی نیز مورد استفاده قرار می‌گیرد. بنابراین اگر قرار باشد آرشیو چند ترابایتی به یک فرمت جدید منتقل شود، AAC یکی از اولین گزینه‌هایی است که باید عملکرد آن بررسی شود.

در این مرحله هدف پیدا کردن بهترین تنظیمات ممکن برای AAC نیست. بسیاری از Encoderها ده‌ها گزینه مختلف در اختیار کاربر قرار می‌دهند و می‌توان ساعت‌ها درباره تفاوت آن‌ها بحث کرد. اما چنین کاری از محدوده این مقاله خارج است. هدف ما بررسی یک تنظیم عملی و قابل استفاده برای پروژه‌ای واقعی است؛ تنظیمی که بتوان آن را بعداً بدون تغییر اساسی روی هزاران فایل اجرا کرد. بنابراین تنها گزینه‌هایی بررسی می‌شوند که مستقیماً در این پروژه استفاده شده‌اند.

انتخاب Encoder

برای تولید فایل AAC می‌توان از Encoderهای مختلفی استفاده کرد. برخی از آن‌ها به صورت داخلی در FFmpeg وجود دارند و برخی دیگر مانند QAAC از کتابخانه‌های اختصاصی استفاده می‌کنند. در این پروژه تصمیم گرفتم از QAAC استفاده کنم، زیرا کیفیت آن در نرخ‌های بیت متوسط و پایین سال‌هاست توسط کاربران و آزمایش‌های مختلف تأیید شده است و برای آرشیوی که قرار است یک بار برای همیشه تبدیل شود، انتخاب منطقی‌تری به نظر می‌رسد.

البته این مقاله قصد ندارد کیفیت همه Encoderهای AAC را با یکدیگر مقایسه کند. تمرکز پروژه روی تصمیم نهایی برای آرشیو است، نه رقابت میان Encoderها. به همین دلیل تنها همان ابزاری بررسی می‌شود که در پروژه واقعی استفاده شده است. مقایسه کامل QAAC با Encoder داخلی FFmpeg یا سایر گزینه‌ها را می‌توان در مقاله‌ای جداگانه بررسی کرد.

دستور تبدیل

برای تولید نسخه AAC از فایل نمونه، فرمان زیر اجرا شد. این دستور علاوه بر Encode فایل صوتی، اطلاعات جانبی مانند Metadata و تصویر جلد آلبوم را نیز حفظ می‌کند تا فایل خروجی از نظر اطلاعات همراه تا حد امکان مشابه فایل اصلی باقی بماند.

qaac64.exe ^
-V 91 ^
--no-delay ^
--threading ^
--copy-artwork ^
--copy-metadata ^
-o "A Perfect Circle-Starless-Starless.m4a" ^
"A Perfect Circle-Starless-Starless-320.mp3"

در این فرمان تنها گزینه‌هایی استفاده شده‌اند که برای پروژه اهمیت دارند. مقدار -V 91 کیفیت هدف را مشخص می‌کند و نتیجه آن در آزمایش ما فایل‌هایی با میانگین نرخ بیت حدود ۱۵۵ کیلوبیت بر ثانیه بود. گزینه‌های مربوط به کپی Metadata و Album Art نیز باعث شدند اطلاعات همراه فایل اصلی حفظ شوند. در این مقاله وارد بررسی کامل تمام پارامترهای QAAC نمی‌شویم، زیرا هدف تنها مستندسازی روند واقعی این پروژه است.

بررسی نتیجه

پس از پایان Encode، دوباره از FFprobe برای بررسی فایل جدید استفاده شد. خروجی نشان داد فایل AAC با پروفایل LC تولید شده است، نرخ نمونه‌برداری همچنان ۴۴۱۰۰ هرتز باقی مانده، فایل همچنان Stereo است و تصویر جلد آلبوم نیز در خروجی وجود دارد. این دقیقاً همان چیزی بود که در ابتدای پروژه انتظار داشتیم؛ یعنی کاهش حجم بدون تغییر در ساختار کلی فایل.

یکی از مهم‌ترین اعداد این مرحله، نرخ بیت میانگین حدود ۱۵۵ کیلوبیت بر ثانیه بود. همچنین حجم فایل از حدود ۱۰٫۶۳ مگابایت به حدود ۵٫۳۲ مگابایت کاهش پیدا کرد. این یعنی تقریباً نیمی از فضای ذخیره‌سازی آزاد شده است. اگر همین نسبت را برای کل آرشیو ۴ تا ۵ ترابایتی در نظر بگیریم، صرفه‌جویی نهایی می‌تواند به چندین ترابایت برسد. البته این تنها یک برآورد اولیه است و تصمیم نهایی پس از بررسی سایر کدک‌ها گرفته خواهد شد.

شنیدن فایل

هیچ پروژه فشرده‌سازی صوتی تنها با نگاه کردن به اعداد کامل نمی‌شود. بنابراین بعد از پایان Encode، نسخه AAC در کنار فایل اصلی چندین بار با هدفون و اسپیکر مقایسه شد. تمرکز شنیدن روی بخش‌هایی بود که معمولاً بیشترین فشار را به Encoder وارد می‌کنند؛ مانند شروع و پایان نت‌ها، صدای سنج، وکال، تغییرات ناگهانی شدت صدا و قسمت‌هایی که چند ساز به طور هم‌زمان اجرا می‌شوند. این روش نسبت به گوش دادن تصادفی، تفاوت‌های احتمالی را بهتر آشکار می‌کند.

در این آزمایش، تفاوت محسوسی که بتوان در شنیدن عادی به راحتی تشخیص داد مشاهده نشد. البته این نتیجه تنها مربوط به همین فایل نمونه، همین تنظیمات Encode و همین شرایط شنیدن است و نباید به همه سبک‌های موسیقی تعمیم داده شود. به همین دلیل در ادامه پروژه هنوز دو کدک دیگر نیز دقیقاً با همین روش بررسی خواهند شد تا تصمیم نهایی بر اساس مقایسه کامل گرفته شود، نه بر پایه یک آزمایش منفرد.

یادداشت داریوش

اگر هدف نهایی تبدیل چند هزار فایل باشد، هر تنظیمی که روی فایل نمونه انتخاب می‌شود باید قابل تکرار، پایدار و قابل اسکریپت‌نویسی باشد. تنظیماتی که تنها چند کیلوبایت صرفه‌جویی بیشتری ایجاد می‌کنند اما فرایند تبدیل را پیچیده یا غیرقابل اتوماسیون می‌کنند، معمولاً برای پروژه‌های بزرگ انتخاب مناسبی نیستند.

جمع‌بندی مرحله

اولین آزمایش نشان داد AAC توانست حجم فایل را تقریباً به نصف کاهش دهد، در حالی که ساختار فایل، اطلاعات جانبی و تجربه شنیداری این نمونه همچنان رضایت‌بخش باقی ماند. این نتیجه AAC را به یک گزینه جدی برای کاهش حجم آرشیو تبدیل می‌کند، اما هنوز برای تصمیم نهایی زود است. در مرحله بعد همین آزمایش با Opus تکرار خواهد شد تا مشخص شود آیا کدک جدیدتر می‌تواند در همین شرایط عملکرد بهتری ارائه دهد یا خیر.

آزمایش Opus

پس از پایان بررسی AAC، نوبت به کدکی رسید که در سال‌های اخیر توجه بسیاری از علاقه‌مندان به کیفیت صدا و توسعه‌دهندگان نرم‌افزار را به خود جلب کرده است؛ Opus. برخلاف MP3 که بیش از دو دهه قدمت دارد و AAC که سال‌هاست به عنوان جایگزین آن شناخته می‌شود، Opus با هدف دستیابی به کیفیت بالاتر در نرخ‌های بیت پایین‌تر طراحی شده است. به همین دلیل بسیاری از کاربران هنگام برنامه‌ریزی برای کاهش حجم آرشیو، قبل از هر گزینه دیگری نام Opus را مطرح می‌کنند. اما سؤال این پروژه تنها این نیست که Opus از نظر تئوری چه قابلیت‌هایی دارد؛ سؤال اصلی این است که آیا در یک آرشیو واقعی چند ترابایتی نیز انتخاب مناسبی خواهد بود یا خیر.

برای اینکه مقایسه منصفانه باقی بماند، دقیقاً همان فایل نمونه‌ای که در مراحل قبل بررسی شد دوباره مورد استفاده قرار گرفت. تغییر فایل آزمایشی می‌توانست نتیجه را تحت تأثیر قرار دهد و مقایسه را بی‌اعتبار کند. همچنین تلاش شد تنظیمات Encode به گونه‌ای انتخاب شوند که نرخ بیت نهایی تقریباً در همان محدوده AAC قرار گیرد. به این ترتیب هر دو کدک با شرایط تقریباً یکسان ارزیابی می‌شوند و اختلاف حجم یا کیفیت بیشتر به تفاوت خود کدک مربوط خواهد بود تا تفاوت تنظیمات.

دستور تبدیل

برای تولید فایل Opus از کتابخانه libopus در FFmpeg استفاده شد. این کتابخانه مرجع رسمی این کدک محسوب می‌شود و در اکثر توزیع‌های استاندارد FFmpeg نیز در دسترس است. همانند مرحله قبل، تنها گزینه‌هایی در فرمان قرار گرفته‌اند که برای این پروژه اهمیت دارند و از اضافه کردن پارامترهای غیرضروری خودداری شده است.

ffmpeg ^
-i "A Perfect Circle-Starless-Starless-320.mp3" ^
-c:a libopus ^
-b:a 160k ^
-map_metadata 0 ^
-map 0 ^
-c:v copy ^
"A Perfect Circle-Starless-Starless.opus"

در این فرمان نرخ بیت هدف حدود ۱۶۰ کیلوبیت بر ثانیه در نظر گرفته شده است تا شرایط مقایسه با AAC تا حد امکان یکسان باشد. همچنین Metadata و تصویر جلد آلبوم از فایل اصلی کپی می‌شوند تا خروجی تنها از نظر کدک تغییر کرده باشد. هدف این پروژه مقایسه عملکرد کدک‌ها است، نه بررسی تأثیر حذف اطلاعات جانبی یا تغییر ساختار فایل.

نتایج اولیه

پس از پایان عملیات Encode، دوباره FFprobe روی فایل جدید اجرا شد. همان‌طور که در خروجی مشاهده شد، کدک فایل به Opus تغییر کرده است و نرخ نمونه‌برداری ۴۸۰۰۰ هرتز گزارش می‌شود. این رفتار کاملاً طبیعی است و به نحوه طراحی Opus مربوط می‌شود. همچنین فایل همچنان Stereo باقی مانده و مدت زمان آن نیز تقریباً با فایل اصلی یکسان است. بنابراین از نظر ساختار کلی، عملیات Encode بدون مشکل انجام شده است.

حجم فایل Opus حدود ۵٫۰۵ مگابایت به دست آمد؛ کمی کمتر از نسخه AAC که حدود ۵٫۳۲ مگابایت بود. اختلاف آن‌قدر زیاد نیست که به تنهایی معیار انتخاب باشد، اما همین تفاوت کوچک اگر روی چندین ترابایت فایل اعمال شود، می‌تواند به ده‌ها یا حتی صدها گیگابایت صرفه‌جویی بیشتر منجر شود. البته این تنها یکی از معیارهای تصمیم‌گیری است و هنوز کیفیت شنیداری و سازگاری نیز باید بررسی شوند.

تجربه شنیداری

پس از پایان Encode، فایل Opus نیز دقیقاً مانند AAC در کنار فایل اصلی چندین بار گوش داده شد. تلاش شد همان بخش‌های موسیقی که در مرحله قبل بررسی شده بودند دوباره مورد ارزیابی قرار گیرند تا شرایط مقایسه یکسان باقی بماند. این کار باعث می‌شود نتیجه بیشتر به تفاوت کدک مربوط باشد تا تفاوت محل شنیدن یا نوع موسیقی. در پروژه‌های واقعی، یک روش ثابت برای شنیدن اهمیت بیشتری از تعداد دفعات آزمایش دارد.

در این فایل نمونه، کیفیت شنیداری Opus نیز بسیار رضایت‌بخش بود و تفاوت آشکاری نسبت به نسخه اصلی در شنیدن معمولی مشاهده نشد. با این حال، نتیجه این آزمایش را نباید به عنوان یک قانون کلی در نظر گرفت. ممکن است سبک‌های مختلف موسیقی یا نرخ‌های بیت متفاوت رفتار دیگری نشان دهند. به همین دلیل تصمیم نهایی این پروژه بر پایه مجموعه‌ای از معیارها شامل حجم، کیفیت، سازگاری و سهولت استفاده گرفته خواهد شد، نه صرفاً تجربه شنیداری یک قطعه موسیقی.

AAC یا Opus؟

در پایان دو مرحله نخست، هر دو کدک عملکرد بسیار خوبی از خود نشان دادند. AAC مزیت سازگاری بسیار گسترده با دستگاه‌ها و نرم‌افزارها را دارد و سال‌هاست به عنوان یک استاندارد شناخته می‌شود. در مقابل، Opus با وجود جدیدتر بودن، توانست با حجمی کمی کمتر کیفیت بسیار خوبی ارائه دهد. اگر تنها به حجم فایل نگاه کنیم، Opus اندکی برتری دارد، اما اختلاف آن به اندازه‌ای نیست که بدون بررسی سایر عوامل بتوان تصمیم نهایی را اعلام کرد.

بررسی تفاوت‌های AAC و Opus در FFmpeg با تمرکز بر فشرده‌سازی، کیفیت، سازگاری دستگاه‌ها و انتخاب مناسب برای آرشیو موسیقی و استریم.
مقایسه AAC و Opus برای کاهش حجم آرشیو موسیقی با FFmpeg، بررسی کیفیت صدا، حجم فایل، بیت‌ریت، سازگاری و انتخاب بهترین کدک صوتی.

در پروژه‌ای مانند این، انتخاب کدک تنها بر اساس چند صد کیلوبایت اختلاف منطقی نیست. اگر قرار باشد آرشیو روی دستگاه‌های قدیمی، خودرو، تلویزیون یا پخش‌کننده‌های سخت‌افزاری نیز استفاده شود، میزان پشتیبانی از فرمت اهمیت پیدا می‌کند. از طرف دیگر، اگر آرشیو تنها روی رایانه‌های جدید یا نرم‌افزارهای مدرن استفاده شود، این محدودیت تا حد زیادی از بین می‌رود. بنابراین تا این مرحله می‌توان گفت AAC و Opus هر دو گزینه‌های قدرتمندی هستند، اما هنوز یک مقایسه دیگر باقی مانده است.

یادداشت داریوش

انتخاب بهترین کدک همیشه به معنای انتخاب پیشرفته‌ترین کدک نیست. در پروژه‌های واقعی عواملی مانند سازگاری، قابلیت نگهداری آرشیو، سرعت پردازش، ابزارهای موجود و نیازهای آینده معمولاً به همان اندازه کیفیت فشرده‌سازی اهمیت دارند.

تصمیم این مرحله

نتایج اولیه نشان می‌دهند Opus نیز مانند AAC توانسته است حجم فایل را تقریباً به نصف کاهش دهد، بدون آنکه در این آزمایش تفاوت شنیداری محسوسی ایجاد شود. اکنون تنها یک مرحله دیگر باقی مانده است؛ مقایسه با MP3 VBR تا مشخص شود آیا ماندن در خانواده MP3 نیز می‌تواند گزینه‌ای منطقی برای کاهش حجم آرشیو باشد یا اینکه مهاجرت به کدک‌های جدید ارزش بیشتری خواهد داشت.

بازگشت به MP3

پس از بررسی دو کدک جدید، شاید این سؤال مطرح شود که آیا اصلاً لازم است فرمت آرشیو تغییر کند؟ اگر هدف فقط کاهش حجم فایل‌ها باشد، شاید بتوان همچنان از MP3 استفاده کرد و تنها نرخ بیت را کاهش داد. این سؤال کاملاً منطقی است، زیرا MP3 هنوز هم سازگارترین فرمت صوتی رایج محسوب می‌شود و تقریباً روی هر دستگاهی بدون نیاز به Codec اضافی قابل پخش است. اگر بتوان با حفظ همین سازگاری، حجم فایل‌ها را به میزان قابل توجهی کاهش داد، بسیاری از کاربران ترجیح می‌دهند به جای مهاجرت به AAC یا Opus، همچنان در اکوسیستم MP3 باقی بمانند.

به همین دلیل پروژه بدون بررسی MP3 VBR کامل نخواهد بود. هدف این مرحله اثبات برتری یا ضعف MP3 نیست، بلکه می‌خواهیم بدانیم اگر هیچ تغییری در فرمت آرشیو ایجاد نکنیم و تنها فایل‌ها را دوباره Encode کنیم، نتیجه تا چه اندازه به AAC و Opus نزدیک خواهد بود. این مقایسه در تصمیم نهایی پروژه نقش مهمی دارد، زیرا گاهی سازگاری بیشتر می‌تواند از چند درصد صرفه‌جویی در حجم ارزشمندتر باشد.

چرا VBR؟

در این پروژه به جای استفاده از نرخ بیت ثابت یا CBR، از MP3 با نرخ بیت متغیر یا VBR استفاده شد. دلیل این انتخاب ساده است؛ در فایل‌های موسیقی همه لحظه‌ها به یک مقدار داده نیاز ندارند. برخی بخش‌ها بسیار ساده هستند و با داده کمتری نیز به خوبی ذخیره می‌شوند، در حالی که قسمت‌های پیچیده‌تر به نرخ بیت بیشتری احتیاج دارند. استفاده از VBR به Encoder اجازه می‌دهد بیت‌های موجود را هوشمندانه‌تر توزیع کند و در نتیجه حجم فایل بدون کاهش محسوس کیفیت کمتر شود.

این مقاله وارد جزئیات الگوریتم VBR یا تفاوت کامل آن با CBR نمی‌شود، زیرا آن موضوع در یکی از مقالات آینده مجموعه FFmpeg به طور مفصل بررسی خواهد شد. در این پروژه تنها همین نکته اهمیت دارد که VBR برای آرشیوی با هزاران فایل معمولاً انتخاب منطقی‌تری نسبت به CBR محسوب می‌شود، زیرا تعادل بهتری میان کیفیت و حجم ایجاد می‌کند.

دستور تبدیل

برای تولید نسخه جدید MP3 از کتابخانه libmp3lame استفاده شد. این Encoder سال‌هاست یکی از شناخته‌شده‌ترین گزینه‌ها برای تولید فایل‌های MP3 است و کیفیت بسیار خوبی ارائه می‌دهد. همانند دو مرحله قبل، تلاش شد تنها گزینه‌های ضروری در فرمان قرار گیرند تا بعداً همین دستور بدون تغییر اساسی برای تبدیل انبوه نیز قابل استفاده باشد.

ffmpeg ^
-i "A Perfect Circle-Starless-Starless-320.mp3" ^
-c:a libmp3lame ^
-q:a 0 ^
-map_metadata 0 ^
-map 0 ^
-c:v copy ^
"A Perfect Circle-Starless-Starless.mp3"

در این فرمان از حالت VBR استفاده شده است و Metadata و تصویر جلد آلبوم نیز از فایل اصلی کپی می‌شوند. استفاده از تنظیمات ساده و قابل تکرار باعث می‌شود همین فرمان بعداً در اسکریپت‌های PowerShell یا Batch نیز قابل استفاده باشد و برای پردازش هزاران فایل نیاز به تغییرات متعدد نداشته باشد.

نتیجه Encode

پس از پایان عملیات Encode، دوباره FFprobe روی فایل جدید اجرا شد. خروجی نشان داد میانگین نرخ بیت فایل حدود ۱۴۶ کیلوبیت بر ثانیه است و حجم نهایی به حدود ۴٫۹۸ مگابایت رسیده است. این یعنی نسخه MP3 VBR حتی اندکی از فایل Opus نیز کوچک‌تر شده است. البته باید توجه داشت که این مقدار میانگین نرخ بیت است و در فایل‌های VBR ممکن است بخش‌های مختلف موسیقی نرخ بیت متفاوتی داشته باشند.

در کنار کاهش حجم، سایر مشخصات فایل نیز مطابق انتظار باقی ماندند. نرخ نمونه‌برداری همچنان ۴۴۱۰۰ هرتز است، فایل Stereo باقی مانده و تصویر جلد آلبوم نیز حفظ شده است. بنابراین از نظر ساختار فایل، هیچ تفاوت غیرمنتظره‌ای نسبت به فایل اصلی مشاهده نمی‌شود و این موضوع نشان می‌دهد فرآیند تبدیل به درستی انجام شده است.

تجربه شنیدن

نسخه MP3 VBR نیز دقیقاً مانند دو فایل قبلی در کنار فایل اصلی و نسخه‌های AAC و Opus مورد بررسی قرار گرفت. هدف این نبود که با یک یا دو بار گوش دادن نتیجه قطعی اعلام شود، بلکه تلاش شد همان بخش‌های حساس موسیقی چندین بار با فاصله زمانی مختلف شنیده شوند. این روش احتمال تأثیر ذهنی یا خستگی شنونده را کاهش می‌دهد و مقایسه را قابل اعتمادتر می‌کند.

در این آزمایش، کیفیت فایل MP3 VBR نیز برای شنیدن روزمره کاملاً رضایت‌بخش بود. اگر بدون اطلاع از فایل در حال پخش، نسخه‌ها به صورت تصادفی اجرا می‌شدند، تشخیص تفاوت آن‌ها در بسیاری از بخش‌ها آسان نبود. البته این نتیجه تنها مربوط به فایل نمونه این پروژه است و نباید آن را به تمام سبک‌های موسیقی یا همه تنظیمات VBR تعمیم داد. با این حال، نتیجه نشان می‌دهد که کاهش حجم آرشیو حتی بدون تغییر فرمت نیز می‌تواند گزینه‌ای قابل بررسی باشد.

جمع‌بندی مرحله

اکنون هر سه گزینه اصلی پروژه آماده مقایسه هستند. AAC، Opus و MP3 VBR همگی توانسته‌اند حجم فایل را تقریباً به نصف کاهش دهند و در این فایل نمونه کیفیت شنیداری رضایت‌بخشی ارائه دهند. در مرحله بعد، همه نتایج کنار یکدیگر قرار می‌گیرند تا مشخص شود برای یک آرشیو واقعی ۴ تا ۵ ترابایتی، کدام گزینه بهترین تعادل میان حجم، کیفیت، سازگاری و آینده‌نگری را فراهم می‌کند.

مقایسه نهایی

اکنون هر چهار فایل با شرایط یکسان تولید و بررسی شده‌اند. همه تبدیل‌ها از یک فایل MP3 320kbps انجام شده‌اند، تنظیمات هر Encoder با هدف دستیابی به کیفیت بالا و حجم کمتر انتخاب شده‌اند و اطلاعات فایل‌ها نیز با FFprobe بررسی شده‌اند. به همین دلیل می‌توان نتایج را در کنار یکدیگر قرار داد و بدون تغییر شرایط آزمایش، آن‌ها را مقایسه کرد. نکته مهم این است که این جدول تنها نتایج همین پروژه را نشان می‌دهد و نباید به عنوان یک Benchmark عمومی برای تمام فایل‌های صوتی در نظر گرفته شود. نوع موسیقی، تنظیمات Encoder و حتی نسخه FFmpeg می‌توانند روی نتیجه نهایی تأثیر بگذارند.

جدول مقایسه نتایج تبدیل فایل صوتی با FFmpeg، نمایش تفاوت MP3 VBR، AAC LC و Opus از نظر حجم، بیت‌ریت و مدیریت آرشیو موسیقی.
مقایسه نهایی فرمت‌های صوتی MP3 320، MP3 VBR، AAC LC و Opus در FFmpeg با بررسی حجم فایل، بیت‌ریت و کاهش حجم آرشیو موسیقی.
فرمت حجم فایل میانگین Bitrate
MP3 320 (منبع) 10.63 MB 320 kbps
MP3 VBR 4.98 MB 146 kbps
AAC LC 5.32 MB 155 kbps
Opus 5.05 MB 155 kbps

اولین نتیجه کاملاً واضح است؛ هر سه روش توانسته‌اند حجم فایل را تقریباً به نصف کاهش دهند. اختلاف حجم میان سه فایل خروجی بسیار کمتر از اختلاف آن‌ها با فایل اصلی است. بنابراین اگر تنها هدف آزاد کردن فضای ذخیره‌سازی باشد، هر سه گزینه می‌توانند بخش بزرگی از این هدف را محقق کنند. از اینجا به بعد، تصمیم نهایی بیشتر به معیارهایی مانند سازگاری، آینده‌نگری و سادگی مدیریت آرشیو وابسته خواهد بود.

مقایسه مزایا

هر سه گزینه نقاط قوت مشخصی دارند و هیچ‌کدام را نمی‌توان در تمام شرایط بهترین انتخاب دانست. MP3 VBR بیشترین سازگاری را ارائه می‌دهد و تقریباً روی هر دستگاهی بدون مشکل پخش می‌شود. اگر آرشیو قرار است روی خودرو، تلویزیون، پخش‌کننده‌های قدیمی یا تجهیزات حرفه‌ای مختلف استفاده شود، این مزیت اهمیت زیادی پیدا می‌کند. از طرف دیگر، AAC نیز سازگاری بسیار خوبی با سیستم‌عامل‌های مدرن، گوشی‌های هوشمند و اکوسیستم Apple دارد و در بسیاری از سرویس‌های موسیقی به عنوان یک فرمت استاندارد شناخته می‌شود.

Opus در مقابل، مدرن‌ترین گزینه این مقایسه است. این کدک برای دستیابی به کیفیت بالا در نرخ‌های بیت پایین طراحی شده و در آزمایش ما نیز عملکرد بسیار خوبی از خود نشان داد. با این حال، هنوز همه دستگاه‌های قدیمی از آن پشتیبانی کامل نمی‌کنند. بنابراین اگر آرشیو تنها روی رایانه، نرم‌افزارهای جدید یا دستگاه‌هایی با پشتیبانی مناسب استفاده شود، Opus می‌تواند انتخاب جذابی باشد، اما برای آرشیوهای عمومی باید موضوع سازگاری نیز در نظر گرفته شود.

اگر ۵ ترابایت باشد

مهم‌ترین سؤال این پروژه از ابتدا همین بود؛ اگر آرشیو چند ترابایت حجم داشته باشد، آیا این تبدیل ارزش انجام دادن دارد؟ با توجه به نتایج فایل نمونه، کاهش حجم تقریباً ۵۰ درصدی دور از انتظار نیست. البته این مقدار برای تمام فایل‌ها دقیقاً یکسان نخواهد بود، اما حتی اگر میانگین صرفه‌جویی کمی کمتر نیز باشد، همچنان می‌توان انتظار داشت چندین ترابایت فضای ذخیره‌سازی آزاد شود. چنین مقداری تنها به معنای کاهش مصرف هارددیسک نیست، بلکه زمان تهیه نسخه پشتیبان، انتقال فایل‌ها و همگام‌سازی نیز کاهش پیدا خواهد کرد.

البته در مقابل باید هزینه اجرای پروژه نیز در نظر گرفته شود. Encode دوباره هزاران فایل ممکن است ساعت‌ها یا حتی چند روز زمان ببرد و در این مدت پردازنده و فضای ذخیره‌سازی درگیر خواهند بود. همچنین همیشه توصیه می‌شود تا پایان آزمایش‌ها فایل‌های اصلی حذف نشوند. بنابراین پروژه‌ای در این ابعاد تنها زمانی منطقی است که مزایای بلندمدت آن از زمان و منابع مصرف‌شده بیشتر باشد.

یادداشت داریوش

بزرگ‌ترین اشتباه در پروژه‌های تبدیل انبوه این است که پس از موفقیت روی یک فایل، بلافاصله کل آرشیو پردازش شود. بهتر است ابتدا چند آلبوم از سبک‌های مختلف موسیقی انتخاب شوند و همان آزمایش روی آن‌ها نیز تکرار شود. اگر نتایج همچنان رضایت‌بخش بودند، آنگاه می‌توان با اطمینان بیشتری پردازش کل آرشیو را آغاز کرد.

تصمیم نهایی

نتیجه این پروژه برای من روشن بود. هر سه روش بررسی‌شده توانستند حجم فایل را تقریباً به نصف کاهش دهند، بدون اینکه در این نمونه کاهش کیفیت محسوسی در شنیدن معمولی مشاهده شود. بنابراین اصل ایده کاهش حجم آرشیو کاملاً عملی است و ارزش بررسی بیشتر را دارد. با این حال، انتخاب نهایی تنها به کیفیت وابسته نیست و باید بر اساس نیاز واقعی آرشیو انجام شود.

اگر حداکثر سازگاری مهم‌ترین معیار باشد، MP3 VBR همچنان گزینه بسیار قدرتمندی است. اگر تعادل میان کیفیت، حجم و پشتیبانی گسترده مدنظر باشد، AAC انتخاب مطمئنی محسوب می‌شود. اما اگر آرشیو قرار است روی سیستم‌های مدرن نگهداری شود و بیشترین بهره‌وری از فضای ذخیره‌سازی اهمیت داشته باشد، Opus نیز شایسته بررسی جدی است. مهم‌تر از انتخاب هر کدام از این کدک‌ها، روشی است که در این پروژه دنبال شد؛ یعنی تصمیم‌گیری بر اساس آزمایش واقعی، اندازه‌گیری و مقایسه، نه صرفاً بر اساس توصیه‌های اینترنتی.

ادامه این مسیر

این مقاله تنها نخستین بخش از مجموعه مقالات مربوط به بهینه‌سازی آرشیو صوتی با FFmpeg بود. در طول پروژه با موضوعات متعددی روبه‌رو شدیم که هر کدام ارزش بررسی عمیق‌تری دارند، اما برای حفظ تمرکز این مقاله تنها به اندازه نیاز پروژه درباره آن‌ها صحبت شد. در مقالات آینده به صورت تخصصی به بررسی FFprobe، Metadata، Album Art، تفاوت VBR و CBR، Encoderهای مختلف AAC، کتابخانه libopus، کتابخانه libmp3lame و همچنین طراحی اسکریپت‌های Batch برای تبدیل انبوه آرشیوهای بزرگ خواهیم پرداخت.

مقایسه MP3، AAC و Opus در پروژه کاهش حجم آرشیو موسیقی با FFmpeg، بررسی فشرده‌سازی، نرخ بیت، صرفه‌جویی در فضای ذخیره‌سازی و انتخاب فرمت مناسب.
کاهش حجم آرشیو موسیقی با FFmpeg، مقایسه MP3، AAC و Opus، نمایش فشرده‌سازی فایل‌های صوتی با پرس صنعتی، بهینه‌سازی فضای ذخیره‌سازی و مدیریت آرشیو.

در نهایت، مهم‌ترین دستاورد این پروژه تنها آزاد شدن چند ترابایت فضای ذخیره‌سازی نبود. ارزش واقعی این فرایند در داشتن یک روش داریوش قابل تکرار است؛ روشی که می‌تواند قبل از هر پروژه بزرگ، ریسک تصمیم‌گیری را کاهش دهد و از صرف زمان و منابع برای انتخاب‌های اشتباه جلوگیری کند.

سؤالات متداول

آیا تبدیل MP3 320kbps به AAC همیشه ارزش دارد؟
خیر. پاسخ به نوع استفاده شما بستگی دارد. اگر هدف تنها کاهش حجم آرشیو باشد و بیشتر از دستگاه‌های جدید استفاده می‌کنید، AAC می‌تواند انتخاب مناسبی باشد. اما اگر سازگاری با تجهیزات قدیمی برای شما اهمیت بیشتری دارد، ممکن است ماندن در MP3 تصمیم منطقی‌تری باشد.

آیا تبدیل دوباره فایل‌های Lossy باعث افت کیفیت می‌شود؟
بله. هر بار که یک فایل Lossy دوباره Encode می‌شود، بخشی از اطلاعات از دست می‌رود. به همین دلیل این پروژه ابتدا روی یک فایل نمونه انجام شد تا قبل از تبدیل کل آرشیو، کیفیت خروجی به دقت بررسی شود.

چرا در این پروژه فقط یک فایل بررسی شد؟
هدف این مقاله طراحی روش کار بود، نه اعلام یک Benchmark جهانی. استفاده از یک فایل نمونه باعث می‌شود روند بررسی، تحلیل و تصمیم‌گیری به‌صورت کنترل‌شده انجام شود. قبل از تبدیل کل آرشیو بهتر است همین آزمایش روی چند سبک مختلف موسیقی نیز تکرار شود.

آیا نتایج این مقاله برای همه آهنگ‌ها یکسان خواهد بود؟
خیر. سبک موسیقی، کیفیت فایل اصلی، تنظیمات Encoder و حتی نسخه نرم‌افزار می‌توانند روی نتیجه نهایی تأثیر بگذارند. اعداد و مشاهدات این مقاله مربوط به همین پروژه هستند و نباید به عنوان نتیجه قطعی برای تمام فایل‌های صوتی در نظر گرفته شوند.

چرا فایل Opus با نرخ نمونه‌برداری 48000Hz نمایش داده شد؟
این رفتار طبیعی کدک Opus است و به معنای افزایش کیفیت نسبت به فایل اصلی نیست. در این پروژه این موضوع تنها برای اطمینان از صحت فایل خروجی بررسی شد و جزئیات آن در مقاله‌ای جداگانه توضیح داده خواهد شد.

چرا حجم AAC و Opus تقریباً برابر بود؟
زیرا هر دو فایل با هدف دستیابی به کیفیتی نزدیک و نرخ بیت مشابه تولید شدند. اگر تنظیمات Encode تغییر کنند، ممکن است اختلاف حجم نیز بیشتر یا کمتر شود.

آیا MP3 VBR هنوز گزینه مناسبی است؟
بله. نتایج این پروژه نشان داد MP3 VBR همچنان می‌تواند حجم فایل را به میزان قابل توجهی کاهش دهد و در عین حال بیشترین سازگاری را با دستگاه‌ها و نرم‌افزارهای مختلف حفظ کند.

آیا Opus بهترین انتخاب برای آرشیو است؟
نه همیشه. Opus از نظر فنی کدک بسیار قدرتمندی است، اما اگر آرشیو شما روی دستگاه‌های قدیمی یا تجهیزات با پشتیبانی محدود استفاده می‌شود، این موضوع باید در تصمیم نهایی در نظر گرفته شود.

آیا بعد از تبدیل باید فایل‌های اصلی حذف شوند؟
خیر. تا زمانی که چندین فایل از سبک‌های مختلف بررسی و کیفیت خروجی کاملاً تأیید نشده است، بهتر است فایل‌های اصلی نگهداری شوند. حذف زودهنگام نسخه‌های اصلی یکی از رایج‌ترین اشتباهات در پروژه‌های تبدیل انبوه است.

آیا می‌توان کل آرشیو را مستقیماً Batch Convert کرد؟
از نظر فنی بله، اما از نظر داریوش توصیه نمی‌شود. بهتر است ابتدا مجموعه کوچکی از فایل‌ها یا چند آلبوم آزمایشی تبدیل شوند و پس از اطمینان از نتایج، پردازش کل آرشیو آغاز شود.

چرا Metadata و Album Art در این پروژه اهمیت داشتند؟
زیرا هدف تنها کاهش حجم فایل نبود. یک آرشیو موسیقی علاوه بر داده صوتی، شامل اطلاعات ارزشمندی مانند عنوان، هنرمند، آلبوم، شماره ترک و تصویر جلد نیز هست. حفظ این اطلاعات باعث می‌شود آرشیو پس از تبدیل همچنان مرتب و قابل استفاده باقی بماند.

مهم‌ترین نتیجه این پروژه چه بود؟
مهم‌ترین نتیجه این نبود که کدام کدک بهترین است؛ بلکه این بود که تصمیم‌گیری درباره یک آرشیو چندترابایتی باید بر پایه آزمایش واقعی، اندازه‌گیری و مقایسه انجام شود. این رویکرد ریسک پروژه را کاهش می‌دهد و از صرف زمان و منابع برای انتخاب‌های نادرست جلوگیری می‌کند.

مطالعه بیشتر

اگر این مقاله برای شما مفید بود، احتمالاً موضوعات زیر نیز برایتان کاربردی خواهند بود. در این مقاله تنها به اندازه نیاز پروژه درباره این مفاهیم صحبت شد تا تمرکز روی روند تصمیم‌گیری داریوش باقی بماند. در مقالات بعدی هر یک از این موضوعات به صورت مستقل، همراه با مثال‌های عملی و بررسی عمیق‌تر، پوشش داده خواهند شد.

  • آشنایی کامل با FFprobe و تحلیل فایل‌های صوتی
  • تفاوت Metadata و Container در فایل‌های چندرسانه‌ای
  • نحوه حفظ Album Art هنگام تبدیل فایل‌های صوتی
  • مقایسه VBR و CBR در پروژه‌های واقعی
  • بررسی کامل Encoderهای AAC شامل QAAC و Native FFmpeg
  • آشنایی با libopus و تنظیمات مهم آن
  • بررسی libmp3lame و تنظیمات VBR
  • طراحی اسکریپت‌های Batch برای تبدیل هزاران فایل با FFmpeg
  • روش‌های ارزیابی کیفیت صوتی پس از Encode
  • بهینه‌سازی آرشیوهای بزرگ موسیقی با استفاده از FFmpeg

خلاصه پروژه

این پروژه با یک سؤال ساده آغاز شد؛ آیا می‌توان حجم یک آرشیو ۴ تا ۵ ترابایتی از فایل‌های MP3 320kbps را بدون افت محسوس کیفیت کاهش داد؟ برای پاسخ به این سؤال، به جای تبدیل مستقیم کل آرشیو، ابتدا یک فایل نمونه انتخاب شد، مشخصات آن با FFprobe بررسی شد و سپس نسخه‌های AAC، Opus و MP3 VBR با تنظیمات یکسان تولید شدند. نتایج نشان داد هر سه روش توانستند حجم فایل را تقریباً به نصف کاهش دهند، در حالی که در این آزمایش تفاوت شنیداری محسوسی مشاهده نشد. مهم‌تر از انتخاب یک کدک خاص، روشی بود که در این پروژه دنبال شد؛ یعنی تصمیم‌گیری بر اساس اندازه‌گیری، آزمایش و تحلیل واقعی، نه صرفاً بر اساس توصیه‌های اینترنتی. همین رویکرد می‌تواند ریسک پروژه‌های بزرگ تبدیل آرشیو را به میزان قابل توجهی کاهش دهد و به انتخابی آگاهانه‌تر منجر شود.

داریوش حقیقی
نویسنده و توسعه‌دهنده

داریوش حقیقی

بیش از 20 سال تجربه در حوزه فناوری اطلاعات، طراحی سایت، سئو تکنیکال، مدیریت سرورهای لینوکس و ویندوز، توسعه وردپرس، برنامه‌نویسی، اتوماسیون و هوش مصنوعی. در djh.ir تلاش می‌کنم تجربیات واقعی پروژه‌های اجرایی، آموزش‌های کاربردی و راهکارهای عملی را با زبانی ساده و قابل استفاده منتشر کنم.

20+ سال تجربه
100+ پروژه اجرایی
1000+ ساعت آموزش

نظر و سوالتون رو اینجا بنویسید...

تماس در تلگرام