نقشه فرمتهای زیرنویس
قبل از مقایسه پسوندها باید چند مفهوم از هم جدا شوند. «فرمت فایل»، «نوع محتوای زیرنویس» و «روش قرار گرفتن زیرنویس کنار ویدئو» سه موضوع متفاوتاند. اگر این مرزها روشن نباشد، اصطلاحاتی مثل SRT، Hardsub، Caption، LRC و PGS بهاشتباه هممعنی تصور میشوند.
Subtitle، Caption و Lyrics
Subtitle معمولاً متن گفتار را برای مخاطبی نمایش میدهد که زبان صدا را نمیداند یا ترجیح میدهد متن را هم ببیند. Caption علاوه بر گفتار میتواند اطلاعات شنیداری مهم مثل نام گوینده، موسیقی، صدای زنگ یا صدای محیط را هم منتقل کند و برای دسترسپذیری اهمیت بیشتری دارد. Lyrics نیز متن ترانه است و در قالبهایی مثل LRC معمولاً با زمان پخش موسیقی هماهنگ میشود.
این سه مفهوم همپوشانی دارند، اما یکسان نیستند. به همین دلیل LRC را نباید صرفاً یک جایگزین دیگر برای SRT دانست و SCC یا TTML نیز دقیقاً همان نقش یک فایل ساده فیلم را ندارند.
متنی و تصویری
فرمتهای Text-based مانند SRT، WebVTT، ASS و TTML متن واقعی را همراه اطلاعات زمانبندی نگه میدارند. این فایلها قابل جستوجو، ترجمه و ویرایش هستند و تبدیل آنها به یکدیگر معمولاً سادهتر است، هرچند ممکن است اطلاعات پیشرفته هنگام تبدیل از بین برود.
در مقابل، فرمتهای Bitmap-based مانند VobSub و PGS زیرنویس را به شکل تصویر ذخیره میکنند. در این حالت حروف بهصورت کاراکتر متنی در فایل وجود ندارند؛ بنابراین برای تبدیل به SRT معمولاً باید از OCR استفاده شود. این تفاوت در آرشیو DVD و Blu-ray بسیار مهم است.
External، Embedded و Hardsub
فایل زیرنویس میتواند بهصورت External یا Sidecar کنار ویدئو باشد، مانند فایل فیلم و یک فایل SRT جدا. میتواند بهصورت Embedded داخل Containerهایی مثل MKV قرار گیرد و همچنان روشن و خاموش شود. یا ممکن است به شکل Hardsub / Burned-in مستقیماً روی تصویر ویدئو رندر شود که دیگر یک Track جداگانه قابل خاموش کردن نیست.
Hardsub یک «فرمت زیرنویس» نیست؛ یک روش تحویل و رندر است. همینطور MKV یا MP4 نیز فرمت زیرنویس نیستند، بلکه Container هستند که میتوانند بعضی Subtitle Streamها را در خود نگه دارند.
جدول زیر خانوادههای اصلی را خلاصه میکند:
| خانواده | نمونهها | کاربرد اصلی |
|---|---|---|
| متنی ساده | SRT، SBV | سازگاری و ویرایش آسان |
| متنی پیشرفته | ASS، WebVTT، TTML | استایل، موقعیت یا ساختار بیشتر |
| Lyrics | LRC | متن آهنگ زمانبندیشده |
| Broadcast | SCC، EBU-STL | Caption حرفهای و تلویزیونی |
| تصویری | VobSub، PGS | حفظ ظاهر زیرنویس DVD/Blu-ray |
منتخب داریوش از یوتیوب
در این قسمت منابع ویدئویی منتخب درباره فرمتهای زیرنویس را بهصورت یک ویدئوی نهایی ارائه میکنم. این منابع با موتور و هوش مصنوعی اختصاصی سایت داریوش حقیقی دانلود، زیرنویس فارسی و ترجمه میشوند و سپس برای نمایش یکپارچهتر در یک فایل نهایی ادغام خواهند شد. هدف این بخش تکرار متن مقاله نیست؛ ویدئو باید تفاوت عملی فرمتها را ملموستر کند و بعد از آن توضیح فنی و مقایسه دقیقتر در خود مقاله ادامه پیدا میکند.
با دیدن ویدئوی نهایی بهتر میتوانید تفاوت بین یک فایل ساده زمانبندیشده و یک Subtitle Format پیشرفته را در عمل درک کنید. هنگام ادامه مقاله، به سه سؤال توجه کنید: فایل چه اطلاعاتی را ذخیره میکند، مقصد پخش چه چیزهایی را پشتیبانی میکند و هنگام تبدیل چه قابلیتهایی ممکن است از دست بروند. همین سه سؤال پایه انتخاب درست بین SRT، WebVTT، ASS و سایر گزینهها هستند.
فرمت SRT
SubRip Subtitle یا SRT شناختهشدهترین فرمت متنی زیرنویس است. محبوبیت آن بیشتر از پیچیدگی فنی نمیآید؛ برعکس، نقطه قوت اصلی SRT ساختار بسیار ساده، خوانا و قابل ویرایش آن است. یک فایل SRT معمولاً از شماره Cue، زمان شروع و پایان و متن تشکیل میشود و تقریباً با هر ویرایشگر متن قابل مشاهده است.
پیدایش و ساختار
نام SRT از نرمافزار SubRip آمده است؛ ابزاری که برای استخراج زیرنویس از منابع ویدئویی و ذخیره متن زمانبندیشده استفاده میشد. برخلاف WebVTT یا TTML، SRT بهعنوان یک استاندارد رسمی تحت مدیریت یک نهاد استانداردسازی شکل نگرفت. همین موضوع باعث شده جزئیات رفتاری آن در Playerهای مختلف همیشه کاملاً یکسان نباشد، با این حال ساختار اصلی آن آنقدر ساده و رایج است که عملاً به یک فرمت تبادل عمومی تبدیل شده است.
یک نمونه ساده SRT به این شکل است:
1
00:00:01,200 --> 00:00:04,500
سلام، این یک نمونه زیرنویس SRT است.
2
00:00:05,000 --> 00:00:08,200
هر بخش زمان شروع و پایان خودش را دارد.در این ساختار، SRT برای هر Cue زمان شروع و پایان دارد. این ویژگی آن را از LRC ساده متمایز میکند؛ LRC معمولاً روی زمان شروع هر خط تمرکز دارد و پایان خط بعدی از Timestamp بعدی یا رفتار Player استنباط میشود.
مزایا و محدودیتها
بزرگترین مزیت SRT سازگاری وسیع و قابلیت حمل بالاست. برای آرشیو ساده، ترجمه، اشتراکگذاری، آپلود در بسیاری از سرویسها و نگهداری متن خام، انتخاب بسیار مطمئنی است. YouTube نیز نسخه ساده SRT با Encoding از نوع UTF-8 را میپذیرد.
محدودیت اصلی SRT این است که برای طراحی پیچیده ساخته نشده است. بعضی Playerها بخشی از Markupهای ساده را میفهمند، اما نباید برای رنگ، فونت، محل دقیق نمایش، Karaoke یا Typesetting پیچیده روی SRT حساب کرد؛ چون نتیجه ممکن است بین Rendererها متفاوت باشد یا Styling کاملاً حذف شود.
اگر نیاز شما فقط «متن + زمان» است، همین محدودیت در واقع یک مزیت محسوب میشود. فایل سبک و ساده میماند، وابستگی کمتری به Renderer و Font دارد و احتمال اینکه مقصد آن را بخواند بیشتر است. برای همین SRT هنوز بهترین Default عمومی است، نه لزوماً بهترین انتخاب برای همه سناریوها.
فرمت WebVTT
Web Video Text Tracks یا WebVTT فرمت متنی طراحیشده برای Timed Text در محیط وب است. اگر مقصد اصلی شما HTML5، مرورگر یا Player وب باشد، VTT معمولاً انتخاب منطقیتری از SRT است؛ چون فقط یک Syntax مشابه SRT نیست و امکاناتی برای Cue Setting، Positioning، Region، Chapter و Metadata زمانبندیشده دارد.
از WebSRT تا WebVTT
WebVTT در آغاز با ایده یک فرمت مبتنی بر SRT برای Web شکل گرفت و در مراحل اولیه WebSRT نامیده میشد. با تکامل نیازهای HTML5، فرمت مستقل WebVTT شکل گرفت و با پسوند .vtt شناخته شد. W3C همچنان این فرمت را توسعه میدهد و در ۲۰ مه ۲۰۲۶ Candidate Recommendation Draft جدید WebVTT منتشر شده است؛ بنابراین VTT یک فرمت متوقفشده یا صرفاً تاریخی نیست.
ساختار ابتدایی آن خواناست:
WEBVTT
00:00:01.200 --> 00:00:04.500 line:90%
سلام، این یک Cue در WebVTT است.
00:00:05.000 --> 00:00:08.200
WebVTT برای محیط وب طراحی شده است.تفاوت مهم در Header، نحوه نمایش Timestamp و امکان افزودن Cue Settings است. WebVTT همچنین میتواند برای Chapter، Description یا Metadata هم استفاده شود، نه فقط Subtitle معمولی.
امکانات وب و HTML5
در HTML5، عنصر track میتواند یک فایل WebVTT را به Video یا Audio متصل کند. این طراحی باعث شده VTT با ساختار وب همخوانتر باشد و در سناریوهایی مثل Caption، Chapter Navigation و Metadata زمانبندیشده کاربرد داشته باشد. Positioning و Styling نیز نسبت به SRT ساختاریافتهترند، هرچند سطح پشتیبانی نهایی به Browser و Player وابسته است.
اگر قرار است زیرنویس را فقط در یک Player دسکتاپ یا آرشیو شخصی نگه دارید، استفاده از VTT لزوماً مزیت بزرگی نسبت به SRT ایجاد نمیکند. اما برای پروژه وب، انتخاب VTT معمولاً از همان ابتدا از تبدیلهای اضافه جلوگیری میکند. برای درک تفاوت Format زیرنویس با Codec و Container ویدئو نیز میتوانید راهنمای بررسی فرمتهای ویدئویی را ببینید.
فرمت ASS و SSA
SubStation Alpha یا SSA و نسل توسعهیافته آن Advanced SubStation Alpha یا ASS برای زمانی ساخته شدهاند که «فقط نمایش متن در پایین تصویر» کافی نیست. ASS میتواند Style، Font، اندازه، رنگ، Margin، Alignment، Positioning، افکتهای زمانی، Karaoke و Override Tagهای متنوع را داخل فایل نگه دارد.
تاریخچه SSA تا ASS
SSA در اکوسیستم زیرنویسسازی دهه ۱۹۹۰ مطرح شد و ASS بهعنوان نسخه پیشرفتهتر خانواده SSA، امکانات ساختاری و استایل بیشتری را تثبیت کرد. برخلاف W3C formats، این خانواده تاریخچهای Community-driven دارد و جزئیات منشأ آن به اندازه WebVTT یا TTML در اسناد استاندارد رسمی یکپارچه نیست؛ بنابراین بهتر است ASS را نه یک استاندارد وب، بلکه یک فرمت تخصصی بسیار توانمند برای Authoring و Rendering زیرنویس بدانیم.
ابزارهایی مانند Aegisub و Rendererهایی مانند libass نقش بزرگی در زنده ماندن این اکوسیستم داشتهاند. libass همچنان فعال است و برای رندر ASS/SSA توسعه داده میشود؛ بنابراین ASS فقط یک Format قدیمی مخصوص Fansub نیست و هنوز در Workflowهای حرفهای و نیمهحرفهای استفاده میشود.
استایل و Karaoke
ساختار ASS از بخشهایی مانند Script Info، Styles و Events تشکیل میشود. بهجای اینکه مشخصات ظاهری را برای هر خط تکرار کنید، میتوانید Styleهای قابل استفاده مجدد تعریف کنید و هر Dialogue را به یکی از آنها نسبت دهید.
[Script Info]
ScriptType: v4.00+
[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, Alignment
Style: Persian,Vazirmatn,48,&H00FFFFFF,2
[Events]
Format: Layer, Start, End, Style, Text
Dialogue: 0,0:00:01.20,0:00:04.50,Persian,سلام، این یک نمونه ASS است.این نمونه فقط بخش کوچکی از توان ASS را نشان میدهد. Override Tagها میتوانند بخشی از یک Dialogue را Bold یا رنگی کنند، محل دقیق نمایش را تغییر دهند، حرکت یا Fade بسازند و برای Karaoke زمانبندی دقیقتری روی سیلابها یا بخشهای متن اعمال کنند.
هزینه این انعطاف، وابستگی بیشتر به Renderer است. اگر Player همه قابلیتهای ASS را به شکل سازگار پیاده نکرده باشد، نتیجه ممکن است با آنچه در محیط Authoring دیدهاید فرق کند. همچنین Font انتخابشده باید در مقصد موجود باشد یا در Workflow مناسب همراه فایل/Container مدیریت شود.
فرمت LRC
LRC بیش از آنکه یک Subtitle Format عمومی برای فیلم باشد، فرمت متن آهنگ زمانبندیشده یا Synchronized Lyrics است. همین تفاوت کاربردی مهم است: اگر هدف شما همگامکردن Lyrics با موسیقی است، LRC ساده و مؤثر است؛ اما اگر Caption کامل، محل نمایش دقیق یا بازه شروع و پایان مستقل برای هر Cue لازم دارید، گزینههای دیگری مناسبترند.
تاریخچه و ساختار Lyrics
تاریخچه LRC مانند W3C formats یک سند رسمی واحد ندارد و معمولاً منشأ آن به ابزارهای نمایش Lyrics در اواخر دهه ۱۹۹۰ نسبت داده میشود. این فرمت در پخشکنندههای موسیقی، نرمافزارهای Lyrics و آرشیوهای موسیقی محبوب شد چون ساختارش بسیار ساده بود: Timestamp و متن همان خط.
[00:01.20]شروع آهنگ
[00:05.40]خط بعدی متن
[00:09.80]ادامه ترانهبرخلاف SRT که برای هر Cue شروع و پایان مستقل دارد، LRC ساده بیشتر روی زمان شروع هر خط تکیه میکند. این طراحی برای Lyrics طبیعی است، اما برای Subtitle ویدئویی که کنترل مدت نمایش هر جمله مهم است انعطاف کمتری دارد.
LRC ساده و Enhanced
Enhanced LRC میتواند Timing دقیقتری در سطح کلمه یا بخشهای کوچکتر متن ارائه دهد و برای Karaoke یا Highlight همگام با موسیقی مفید باشد. با این حال امکانات Layout و Styling آن قابل مقایسه با ASS نیست.
نکته جالب این است که YouTube نیز فایل LRC و Enhanced LRC را در فهرست فرمتهای Caption پذیرفتهشده دارد، اما این پشتیبانی باعث نمیشود LRC برای همه ویدئوها بهترین انتخاب باشد. فلسفه اصلی آن همچنان Lyrics است. برای شناخت بهتر رابطه LRC با فرمتهای موسیقی، راهنمای بررسی فرمتهای صوتی نیز مکمل خوبی است.
فرمتهای حرفهای
در Workflowهای Broadcast، OTT، استودیو و تبادل حرفهای محتوا، SRT همیشه اطلاعات کافی را منتقل نمیکند. نیاز به Styling استاندارد، Caption Metadata، Positioning، پروفایلهای تحویل و سازگاری با زنجیرههای پخش باعث شکلگیری یا استفاده گسترده از خانوادههایی مانند TTML، IMSC، SCC و EBU-STL شده است.
TTML، DFXP و IMSC
Timed Text Markup Language یا TTML یک خانواده XML-based برای Timed Text است که میتواند Timing، Styling، Layout و Metadata را با ساختار بسیار غنیتری نسبت به SRT نگه دارد. خواندن دستی آن سختتر است، اما در Workflowهای استاندارد و حرفهای قدرت بیشتری دارد.
<tt xmlns="http://www.w3.org/ns/ttml">
<body>
<div>
<p begin="00:00:01.200" end="00:00:04.500">
سلام، این یک نمونه TTML است.
</p>
</div>
</body>
</tt>DFXP را بهتر است در بستر تاریخی TTML ببینیم، نه یک اکوسیستم کاملاً جدا. نام Distribution Format Exchange Profile در مراحل قدیمیتر خانواده TTML دیده میشود و بسیاری از سیستمها فایلهای DFXP را بهعنوان TTML تفسیر میکنند.
IMSC نیز Profileای از TTML برای تحویل Subtitle و Caption در رسانههای اینترنتی و حرفهای است. در ۲۱ مه ۲۰۲۶، W3C نسخه IMSC Text Profile 1.3 را بهعنوان Recommendation منتشر کرد؛ نشانهای روشن از اینکه خانواده TTML/IMSC همچنان در حال نگهداری و توسعه استانداردی است.
SCC و CEA-608
Scenarist Closed Caption یا SCC بیشتر در زنجیرههای Caption مبتنی بر CEA-608 دیده میشود. هدف آن حفظ اطلاعات Caption به شکلی نزدیک به Workflowهای تلویزیونی است. برای کسی که فقط فایل زیرنویس فیلم میخواهد، SCC انتخاب روزمرهای نیست؛ اما در Broadcast و تحویل حرفهای هنوز نام مهمی است.
YouTube نیز برای Captionهایی که بر قابلیتهای CEA-608 تکیه دارند SCC را فرمت ترجیحی معرفی میکند. این مثال نشان میدهد «بهترین فرمت» همیشه به مقصد و استاندارد مورد انتظار آن مقصد وابسته است.
EBU-STL
EBU-STL یک فرمت قدیمیتر اما مهم در صنعت پخش اروپاست. استاندارد EBU Tech 3264 در سال ۱۹۹۱ برای تبادل Subtitle Data در محیط Broadcast منتشر شد. امروزه TTML و Profileهای جدیدتر در بسیاری از Workflowها اهمیت بیشتری پیدا کردهاند، اما STL همچنان در آرشیوها و زنجیرههای قدیمیتر دیده میشود.
فرمتهای قدیمی و خاص
علاوه بر فرمتهای اصلی، هنگام کار با آرشیوهای قدیمی، Playerها، Ripهای DVD/Blu-ray یا ابزارهای تبدیل ممکن است با پسوندهایی روبهرو شوید که امروز کمتر برای پروژه جدید انتخاب میشوند. شناخت آنها کمک میکند بهاشتباه همه فایلهای زیرنویس را یکسان فرض نکنید.
SBV، SubViewer و SAMI
SubViewer و قالبهای نزدیک به آن از فرمتهای متنی سادهاند. YouTube هنوز SubViewer با پسوندهای SBV یا SUB را در میان گزینههای پایه خود میپذیرد. این فایلها برای Caption ساده قابل استفادهاند، اما از نظر اکوسیستم و کاربرد عمومی امروز معمولاً زیر سایه SRT قرار میگیرند.
SAMI یا Synchronized Accessible Media Interchange از اکوسیستم قدیمیتر Microsoft میآید و برای Caption/Accessibility طراحی شده بود. فایلهای SMI یا SAMI میتوانند Timecode و Markup ساده داشته باشند، ولی برای یک پروژه جدید معمولاً دلیلی برای انتخاب آن بهجای SRT، VTT یا TTML وجود ندارد مگر اینکه مقصد خاصی آن را بخواهد.
MicroDVD و MPL2
MicroDVD نمونه مهمی از فرمتهای Frame-based است. بهجای زمان واقعی، Cue میتواند با شماره Frame شروع و پایان مشخص شود. نتیجه این است که اگر Frame Rate منبع اشتباه تفسیر شود، Timing کل زیرنویس بههم میریزد. این وابستگی یکی از دلایلی است که Time-based formats برای تبادل عمومی سادهترند.
MPL2 نیز از قالبهای متنی قدیمیتر است که ممکن است در آرشیوها دیده شود. اگر چنین فایلهایی در اختیار دارید، تبدیل آنها به فرمت جدیدتر معمولاً منطقی است؛ اما قبل از تبدیل باید Timing و Encoding بررسی شود.
MPEG-4 Timed Text یا فرمهایی که در ابزارهای Media Processing با نامهایی مثل mov_text دیده میشوند، بیشتر زمانی مطرحاند که Subtitle Track داخل MP4 نگهداری میشود. اینجا باید بین «فرمت فایل Sidecar» و «Codec/Representation زیرنویس داخل Container» تفاوت بگذارید. ممکن است Source شما SRT باشد اما هنگام Mux داخل MP4 به representation دیگری تبدیل شود. به همین دلیل بررسی فقط پسوند فایل ورودی برای پیشبینی قابلیتهای Track نهایی کافی نیست.
در آرشیوهای قدیمی ممکن است نام یکسان Extension نیز گمراهکننده باشد. برای نمونه .sub میتواند به یک فایل متنی قدیمی یا بخشی از VobSub اشاره کند. ابزار تشخیص باید محتوای واقعی فایل، Header و Context فایلهای همراه را بررسی کند. این موضوع هنگام ساخت اسکریپتهای Batch اهمیت زیادی دارد؛ چون تبدیل اشتباه صدها فایل فقط بر اساس Extension میتواند Timing یا داده اصلی را خراب کند.
VobSub و PGS
VobSub معمولاً با جفت فایلهای IDX/SUB شناخته میشود. IDX اطلاعات Index، Timing و مشخصات Track را نگه میدارد و SUB داده تصویری Subtitle را حمل میکند. این زیرنویس متن سادهای مثل SRT نیست؛ خود حروف بهصورت Bitmap ذخیره میشوند.
PGS یا Presentation Graphic Stream نیز در Blu-ray رایج است و زیرنویس را به شکل تصاویر گرافیکی زمانبندیشده نگه میدارد. مزیت این روش حفظ دقیق ظاهر است؛ Font، Symbol و Layout به سیستم مقصد وابسته نیستند چون همهچیز از قبل به تصویر تبدیل شده است. نقطه ضعف هم روشن است: جستوجو، ویرایش و ترجمه مستقیم متن بسیار سختتر میشود و تبدیل به SRT نیازمند OCR است.
همچنین باید به ابهام پسوند .sub توجه کرد. یک فایل با پسوند SUB میتواند به خانوادههای متفاوتی تعلق داشته باشد؛ بنابراین فقط از روی Extension درباره ساختار فایل قضاوت نکنید.
برای عملیات استخراج، تبدیل یا Mux این فرمتها میتوانید به آموزش FFmpeg مراجعه کنید؛ این مقاله عمداً روی انتخاب و ماهیت Format تمرکز دارد و دستورات کامل FFmpeg را تکرار نمیکند.
تبدیل بین فرمتها
وجود یک Converter به این معنی نیست که تبدیل بدون افت اطلاعات انجام میشود. در Subtitle Conversion، مسئله اصلی فقط تبدیل Extension نیست؛ باید مشخص کنید فرمت مقصد اصلاً توان نگهداری قابلیتهای فرمت مبدأ را دارد یا نه. به این نوع افت میتوان Semantic Loss گفت: متن شاید سالم بماند، اما معنا یا رفتار نمایشی بخشی از فایل از بین برود.
چه چیزی از دست میرود؟
تبدیل SRT به WebVTT معمولاً برای متن و Timing ساده کمریسک است، اما امکانات WebVTT بعداً فقط زمانی قابل استفادهاند که به فایل مقصد اضافه شوند. در جهت عکس، VTT به SRT ممکن است Cue Settings، Region یا Metadata را حذف کند.
تبدیل ASS به SRT مثال واضحتری است. متن و زمانبندی اصلی معمولاً قابل استخراجاند، اما Style، Position، Font، Karaoke، Drawing، Layer و Override Tagهای پیشرفته مقصدی در SRT ندارند. اگر این اطلاعات برای پروژه مهم باشند، خروجی SRT از نظر معنایی معادل فایل ASS نیست.
در TTML نیز تبدیل به یک فرمت ساده ممکن است Styling، Layout، Metadata و ساختار حرفهای را کاهش دهد. بنابراین قبل از Batch Conversion باید یک فایل نمونه را تبدیل و در مقصد واقعی بررسی کنید.
Text و Bitmap
تبدیل بین دو Text Format معمولاً Parse و Serialize است: نرمافزار اطلاعات را میخواند و در Syntax مقصد مینویسد. اما Bitmap Subtitle مثل PGS یا VobSub متن قابل Parse ندارد. برای رسیدن به SRT باید تصویر هر Caption تشخیص داده شود، OCR انجام شود، متن اصلاح شود و Timing حفظ گردد.
OCR نیز بدون خطا نیست. فونتهای خاص، Outline، تصویر کمکیفیت، نویز، زبان فارسی، اعداد و ترکیب متن راستبهچپ و چپبهراست میتوانند نرخ خطا را افزایش دهند. برای آرشیو مهم بهتر است Source تصویری اصلی را نگه دارید و فایل OCRشده را بهعنوان نسخه قابل ویرایش ثانویه بسازید.
یک قاعده عملی خوب این است: قبل از تبدیل، مشخص کنید چه دادهای باید حفظ شود؛ بعد مقصد را انتخاب کنید. اگر فقط متن مهم است، SRT میتواند مقصد خوبی باشد. اگر Style و Layout بخشی از محتوا هستند، ASS یا TTML را بیدلیل به فرمت سادهتر تقلیل ندهید.
زیرنویس فارسی
برای زیرنویس فارسی، انتخاب Extension تنها بخشی از مسئله است. Encoding، جهت متن، شکلدهی حروف، فونت، علامتگذاری، ترکیب فارسی و انگلیسی و Renderer همگی در نتیجه نهایی اثر دارند. ممکن است یک فایل از نظر Syntax کاملاً درست باشد اما روی Player مقصد حروف جدا، علامتها جابهجا یا ترکیب فارسی/English نامرتب دیده شود.
UTF-8 و RTL
برای فایلهای متنی جدید، UTF-8 انتخاب امن و استانداردی است. استفاده از Encodingهای قدیمی محلی میتواند باعث متن ناخوانا یا Mojibake شود، مخصوصاً وقتی فایل بین Windows، Linux، Web و سرویسهای آنلاین جابهجا میشود. YouTube نیز برای SRT ساده، UTF-8 را صریحاً میخواهد.
RTL فقط راستچین کردن متن نیست. موتور نمایش باید Unicode Bidirectional Algorithm و شکلدهی درست حروف فارسی/عربی را مدیریت کند، مخصوصاً زمانی که در یک خط فارسی، عدد، URL، Command یا واژه انگلیسی هم وجود دارد. Rendererهای مبتنی بر libass از ابزارهایی مانند FriBidi و HarfBuzz برای پردازش متن دوطرفه و شکلدهی فونت استفاده میکنند، اما نتیجه نهایی همچنان باید روی Player واقعی تست شود.
نشانهگذاری فارسی نیز مهم است. پرانتز، دونقطه، علامت سؤال، درصد، عدد و واژههای انگلیسی در خطوط Mixed-direction میتوانند در Rendererهای ضعیف رفتار متفاوتی داشته باشند. اگر پروژه حساس است، چند نمونه پیچیده را از همان ابتدا در Test Corpus قرار دهید.
چرا ASS برای فارسی؟
برای Subtitle ساده فارسی، SRT کاملاً مناسب است؛ بهخصوص وقتی بیشترین Compatibility و کمترین وابستگی به Renderer مهم باشد. اما زمانی که Font فارسی، اندازه دقیق، Outline، Shadow، Alignment، Position و کنترل ظاهر اهمیت پیدا میکند، ASS مزیت بزرگی دارد.
من خودم در پروژههای زیرنویس فارسی از ASS استفاده میکنم، چون کنترل بسیار بیشتری روی فونت، استایل و چیدمان میدهد و در Workflowهایی که Renderer مناسب دارند، مدیریت متن RTL و ترکیب فارسی و انگلیسی قابل اتکاتر است. این مزیت برای پروژههایی که زیرنویس در بالای تصویر، پایین تصویر یا چند ناحیه مختلف قرار میگیرد، بیشتر خودش را نشان میدهد.
با این حال نباید جمله «ASS همیشه RTL را بهتر نمایش میدهد» را بهصورت مطلق در نظر گرفت. ASS اطلاعات بیشتری در اختیار Renderer میگذارد، اما شکلدهی و BiDi در نهایت به موتور رندر هم وابسته است. بنابراین بهترین Workflow این است که Font مشخص و قابلاعتماد انتخاب شود، فایل با UTF-8 ذخیره شود و خروجی روی همان Player یا فرایند Burn نهایی تست شود.
اگر Subtitle قرار است به Video Burn شود، کنترل ASS روی Font و Layout یک مزیت عملی جدی است. اگر قرار است فایل خام برای طیف بسیار گستردهای از دستگاهها توزیع شود و Styling اهمیت ندارد، SRT ممکن است کمدردسرتر باشد.
بهترین فرمت زیرنویس 2026
در سال ۲۰۲۶ انتخاب فرمت زیرنویس هنوز باید سناریومحور باشد. WebVTT همچنان تحت توسعه W3C است، IMSC Text Profile 1.3 در همین سال به Recommendation رسیده و پلتفرمهایی مانند YouTube چند خانواده مختلف از فرمتهای ساده، پیشرفته و Broadcast را میپذیرند. بنابراین تصمیم درست این نیست که بپرسیم «کدام پسوند مشهورتر است؟»؛ باید بپرسیم «مقصد من چه چیزی لازم دارد؟»
قاعده اصلی این مقاله این است: بهترین فرمت، سادهترین فرمتی است که قابلیتهای موردنیاز مقصد را بدون از دست دادن اطلاعات ضروری حفظ کند.
برای تصمیم سریع، جدول زیر مناسبترین Default را برای چند سناریوی رایج نشان میدهد:
| سناریو | انتخاب پیشنهادی | دلیل |
|---|---|---|
| سازگاری عمومی | SRT | ساده، خوانا و گسترده |
| وب و HTML5 | WebVTT | طراحیشده برای Timed Text وب |
| استایل و Typesetting | ASS | Font، Position، Style و Karaoke |
| زیرنویس فارسی حرفهای | ASS | کنترل بهتر روی Font و Layout |
| Lyrics موسیقی | LRC | ساختار ساده برای متن آهنگ زمانبندیشده |
| OTT و Workflow حرفهای | TTML / IMSC | ساختار استاندارد و غنی |
| Caption مبتنی بر CEA-608 | SCC | حفظ داده Caption Broadcast |
| حفظ ظاهر DVD/Blu-ray | VobSub / PGS | زیرنویس Bitmap بدون وابستگی به Font مقصد |
SRT را انتخاب کنید وقتی متن و Timing کافی است و میخواهید فایل تقریباً همهجا قابل استفاده باشد. این گزینه برای ترجمه، آرشیو متنی و تحویل ساده عالی است.
WebVTT را انتخاب کنید وقتی مقصد اصلی Browser، HTML5 یا سیستم مبتنی بر Web است. اگر از ابتدا میدانید خروجی روی Web مصرف میشود، تبدیل SRT به VTT در انتهای Workflow فقط یک مرحله اضافی است.
ASS را انتخاب کنید وقتی ظاهر Subtitle بخشی از طراحی محتواست. برای Anime، Karaoke، آموزشهای ویدئویی، Positioning دقیق و پروژههای فارسی که Font و RTL اهمیت بالایی دارند، ASS میتواند بهترین انتخاب باشد. این همان Formatی است که من نیز در پروژههای زیرنویس خودم ترجیح میدهم، البته با تست Renderer مقصد.
LRC را انتخاب کنید وقتی محتوای شما Lyrics است. استفاده از LRC برای فیلم معمولی فقط به این دلیل که Text-based است منطقی نیست.
TTML یا IMSC را زمانی انتخاب کنید که مقصد حرفهای، استاندارد تحویل یا زنجیره OTT/Broadcast آن را میطلبد. پیچیدگی بیشتر در اینجا یک هزینه بیدلیل نیست؛ اطلاعات ساختاری بیشتری برای Workflow حرفهای حفظ میشود.
PGS یا VobSub را وقتی نگه دارید که هدف حفظ دقیق Subtitle تصویری منبع است. برای ویرایش و ترجمه، نسخه Text-based ثانویه بسازید اما Source Bitmap را دور نریزید.
برای آرشیو فیلم و سریال بهتر است بین «نسخه نگهداری» و «نسخه مصرف» تفاوت بگذارید. ممکن است ASS یا PGS را بهعنوان Source اصلی حفظ کنید، چون اطلاعات ظاهری بیشتری دارد، و در کنار آن یک SRT ساده برای جستوجو، ترجمه یا استفاده روی دستگاههای محدود بسازید. این رویکرد از مجبور شدن به انتخاب یک Format واحد برای تمام هدفها جلوگیری میکند.
برای تولید محتوای آموزشی نیز اگر Subtitle فقط برای Accessibility یا ترجمه ساده است، SRT کفایت میکند. اما اگر لازم است متن بالا و پایین تصویر جابهجا شود، اصطلاحات با Style متفاوت مشخص شوند یا متن فارسی و انگلیسی در نواحی کنترلشده نمایش داده شوند، ASS انعطاف بیشتری میدهد. در خروجی Burned-in نیز این کنترل قبل از Encode نهایی اعمال میشود و بیننده دیگر به پشتیبانی Player از Subtitle Track وابسته نیست.
در YouTube انتخاب SRT برای Upload معمولاً کمدردسر است، چون فایل ساده UTF-8 بهراحتی ساخته و ویرایش میشود. با این حال پشتیبانی YouTube به SRT محدود نیست و فرمتهای دیگری را نیز میپذیرد. این نکته مهم است چون «پشتیبانی شدن» یک Format با «بهترین بودن آن برای Workflow شما» تفاوت دارد؛ برای اکثر کاربران Upload ساده، قابلیتهای پیچیدهتر لزوماً مزیت عملی ایجاد نمیکنند.
مقایسه سریع فرمتها
اگر بخواهیم فرمتهای اصلی را بدون جزئیات تاریخی کنار هم ببینیم، سه معیار از همه مهمترند: مقدار اطلاعاتی که فایل حفظ میکند، میزان وابستگی به Renderer و مقصد اصلی استفاده.
| فرمت | مزیت اصلی | محدودیت اصلی |
|---|---|---|
| SRT | سازگاری و سادگی | استایل و Layout محدود |
| WebVTT | یکپارچگی با Web/HTML5 | پشتیبانی ویژگیها وابسته به Player |
| ASS | استایل، فونت و Positioning پیشرفته | وابستگی بیشتر به Renderer |
| LRC | Lyrics زمانبندیشده ساده | مناسب نبودن برای Caption پیچیده |
| TTML/IMSC | ساختار حرفهای و استاندارد | پیچیدگی بیشتر |
| PGS/VobSub | حفظ ظاهر دقیق | متن واقعی ندارد و نیازمند OCR است |
این جدول نشان میدهد چرا تبدیل همه فایلها به SRT همیشه «بهینهسازی» نیست. اگر Source شما ASS یا TTML باشد، ممکن است تبدیل به SRT بخشی از داده واقعی را دور بریزد. برعکس، اگر پروژه فقط متن و Timing لازم دارد، نگهداری Format بسیار پیچیده هم الزاماً ارزش اضافهای ایجاد نمیکند.
سوالات متداول
در این بخش به چند سؤال رایج درباره انتخاب، تبدیل و استفاده از فرمتهای زیرنویس پاسخ میدهم.
بهترین فرمت زیرنویس در سال 2026 چیست؟
یک برنده مطلق وجود ندارد. SRT بهترین Default عمومی، WebVTT مناسب Web، ASS مناسب Styling و فارسی حرفهای، LRC مناسب Lyrics و TTML/IMSC مناسب Workflowهای حرفهای است.
SRT بهتر است یا WebVTT؟
برای سازگاری عمومی SRT سادهتر است؛ برای HTML5 و Timed Text وب، WebVTT انتخاب طبیعیتری محسوب میشود چون امکانات Web-specific بیشتری دارد.
ASS چه تفاوتی با SRT دارد؟
SRT عمدتاً متن و زمان را نگه میدارد، در حالی که ASS میتواند Font، Style، Position، Layer، Karaoke و Override Tagهای پیشرفته را ذخیره کند.
ASS و SSA چه تفاوتی دارند؟
SSA خانواده قدیمیتر SubStation Alpha است و ASS یا Advanced SubStation Alpha نسخه توسعهیافتهتر این خانواده با امکانات Styling و ساختار پیشرفتهتر محسوب میشود.
آیا LRC یک فرمت زیرنویس است؟
LRC یک Timed Text Format است، اما کاربرد اصلی آن Synchronized Lyrics است. برای Subtitle معمول فیلم، SRT، VTT یا ASS معمولاً مناسبترند.
برای YouTube کدام فرمت زیرنویس بهتر است؟
برای Caption ساده، SRT UTF-8 انتخاب راحت و رایجی است. YouTube علاوه بر SRT فرمتهایی مانند WebVTT، LRC، TTML/DFXP، SCC و EBU-STL را هم در شرایط مربوط پشتیبانی میکند.
برای ویدئوی HTML5 از SRT استفاده کنیم یا VTT؟
برای HTML5 معمولاً WebVTT بهتر است، چون مشخصاً برای Text Trackهای وب طراحی شده و Cue Setting، Positioning و کاربردهای دیگری مثل Chapter و Metadata را پشتیبانی میکند.
آیا تبدیل ASS به SRT استایلها را حذف میکند؟
بله، معمولاً متن و Timing قابل حفظاند اما Styling، Positioning، Karaoke و بسیاری از Override Tagهای ASS در SRT مقصدی ندارند و حذف میشوند.
برای زیرنویس فارسی چه فرمتی مناسبتر است؟
برای متن ساده و سازگاری گسترده SRT مناسب است؛ برای کنترل حرفهای Font، Style، Position و Workflowهای RTL، ASS با Renderer مناسب انتخاب قویتری است.
چرا VobSub و PGS مثل SRT قابل ویرایش نیستند؟
چون این فرمتها Subtitle را به شکل Bitmap یا تصویر ذخیره میکنند و متن واقعی در آنها وجود ندارد. برای تبدیل به متن معمولاً باید OCR انجام شود.
نتیجهگیری
انتخاب فرمت زیرنویس باید از مقصد و نیاز واقعی شروع شود، نه از محبوبیت یک Extension. اگر فقط متن و زمانبندی میخواهید، SRT هنوز سادهترین انتخاب عمومی است. اگر ویدئو در Web و HTML5 مصرف میشود، WebVTT ساختار مناسبتری دارد. اگر استایل، فونت، موقعیت، Karaoke یا کنترل ظاهری اهمیت دارد، ASS قابلیتهایی ارائه میدهد که SRT برای آنها طراحی نشده است.
برای فارسی، من ASS را در پروژههای خودم ترجیح میدهم؛ مخصوصاً جایی که فونت، RTL و Layout خروجی مهم هستند. در عین حال باید Renderer مقصد را جدی گرفت و فایل را روی همان محیط نهایی تست کرد. برای Lyrics، LRC انتخاب طبیعیتری است و در زنجیرههای حرفهای OTT/Broadcast نیز TTML/IMSC، SCC یا فرمتهای تخصصی دیگر ممکن است Requirement اصلی باشند.
مهمترین نکته هنگام تبدیل نیز این است که «قابل تبدیل بودن» را با «بدون افت بودن» یکی ندانید. قبل از هر Conversion مشخص کنید کدام اطلاعات باید حفظ شوند. اگر Style، Metadata یا Bitmap Source برای پروژه ارزش دارد، نسخه اصلی را نگه دارید و خروجی سادهتر را بهعنوان نسخه ثانویه تولید کنید. برای ادامه عملی مسیر، پروژه ساخت زیرنویس از ویدیو Media2Ass نمونه مناسبی از اتصال تولید Subtitle به یک Workflow واقعی است.
