Конвертувати SUP (PGS) у SRT
Перший запуск завантажує читач тексту — близько 4 МБ плюс мовну модель, віддається цим сайтом і після цього кешується браузером. Нічого не надсилається, а результат читає машина: вичитайте його, перш ніж покладатися на нього.
Параметри
Растровий субтитр — це зображення тексту, тож слова треба вичитати з нього назад. Скажіть читачеві, якою мовою написані субтитри — список охоплює всі мови, якими публікується цей сайт. Російські субтитри, прочитані англійською моделлю, виходять шумом, а не російською. Завантажується лише обрана модель (інші — ніколи), тож перемикання коштує одного завантаження на мову, яке потім кешується.
Файл .sup — це потік PGS, формат растрових субтитрів, який використовують диски Blu-ray. У ньому немає жодного символу: кожен субтитр зберігається як зображення разом із палітрою й моментом появи, а плеєр накладає його на відео. Тому витягти звідси текст означає прочитати літери на кожній картинці. Ця сторінка робить це у вкладці рушієм OCR, який сайт віддає сам, і записує результат у файл .srt.
Формат — це послідовність сегментів, кожен із тринадцятибайтовим заголовком, що несе час подання в одиницях 90 кГц, тип і довжину. Важливі чотири типи: визначення палітри (PDS), яке переводить індекси в повний RGB через YCbCr; визначення об’єкта (ODS), яке тримає одне зображення, стиснене кодуванням довжин серій; композиція подання (PCS), яка каже, які об’єкти де стоять на кадрі; і набір показу, який їх складає. Початок репліки — це час набору показу, який її показує. Потік PGS не має часу кінця взагалі: субтитр висить на екрані, доки його не замінить наступний набір, тому кінець кожної репліки тут — початок наступної, і саме так чинить плеєр. Остання репліка не має наступної, тому отримує дві секунди, і це рішення записане у списку втрат.
Оскільки кожну репліку читає машина, текст є прочитанням, а не транскрипцією: шрифт із засічками дрібного кегля, незвична гарнітура або товсте обведення можуть перетворити один символ на інший. Вичитайте файл, перш ніж на нього покладатися. Це не формальність: це єдине місце на сайті, де продукт не виведений із того, що сказав файл, і сторінка каже про це прямо, а не подає результат як точний.
Вибирайте мову, якою субтитри справді написані. Список охоплює всі мови, якими публікується цей сайт, і кожна модель читає свою письменність. Англійська модель на японських субтитрах дає шум, а не поганий переклад, бо розпізнавач шукає форми, яких там немає. Завантажується лише вибрана модель, і після цього її кешує браузер.
Репліки, чиї зображення не дають жодного тексту — кадр затемнення, логотип, чорна репліка, — вилучають і рахують у списку втрат, а не пишуть порожніми рядками. Усе, що було зображенням, лишається зображенням за суттю: шрифт, колір, обведення й позиція на екрані не існують у .srt, і список втрат каже про це один раз на весь файл.
Часті запитання
Що лежить усередині .sup, через що перетворення на SRT стає розпізнаванням?
Сегменти, а не символи. Кожен субтитр у потоці PGS — це об’єкт: зображення з індексів палітри, стиснене кодуванням довжин серій, плюс визначення палітри, яке перетворює ці індекси на RGB. Єдині схожі на текст значення у файлі — часи подання, цілі числа в одиницях 90 кГц, які людина не читає. Перетворити це на SRT означає покласти кожне зображення на полотно й розпізнати літери, тому результат потребує вичитування, а сторінка питає, якою мовою написані субтитри.
Чому останній субтитр у результаті закінчується на кілька секунд пізніше, ніж мав би?
Бо PGS ніколи не каже, коли субтитр закінчується. Плеєр показує композицію, доки не прийде наступна або доки потік не очистять, тому єдиний час кінця, який існує у файлі, — «початок наступного». Для останньої репліки наступної немає; сторінка дає їй дві секунди й записує цей вибір у список втрат. Якщо диск справді тримав останній рядок десять секунд, чесне виправлення — зсув або зміна тривалості, а не здогад, схований у конвертері.
Яку мовну модель вибрати, якщо в субтитрах є і японські, і англійські рядки?
Ту, якою написана більшість діалогу. Кадр PGS може змішувати письма в одному рядку — японське речення з англійським запозиченням латиницею трапляється часто, — але розпізнавач отримує одну модель на запуск, і модель, навчена на одному письмі, читає інше як сміття. Якщо файл справді чергує два письма, запустіть його двічі, по разу на мову, і збережіть рядки, які кожен прохід прочитав правильно: результат — звичайний .srt, тому злити два файли означає порівняти їх, а не експортувати заново.
Чи переносяться кольори субтитрів у SRT?
Ні, і не можуть. Файл .sup кодує колір тричі: у палітрі (YCbCr з альфа-каналом, для кожної репліки), у композиції (де зображення стоїть на кадрі 1920×1080) і в обведенні та тіні, намальованих у самому зображенні. У SRT немає жодного такого поля. Сторінка читає яскравість кожного пікселя, щоб вирішити, де фарба, а де тло, — цього достатньо для OCR, — а потім відкидає палітру й повідомляє про оформлення один раз на файл, а не вдає, що кольори вижили.
Деякі репліки вийшли порожніми або зникли. Що з ними сталося?
Зображення, яке не дало тексту, вилучили, а не записали порожнім субтитром. Так буває з кадрами появи й зникнення, з репліками, що містять лише логотип або символ, і з дуже дрібним текстом, меншим за роздільну здатність розпізнавача. Кожну таку репліку пораховано у списку втрат, тому отриманий файл не коротший за відданий мовчки. Якщо лічба велика, звичайна причина — неправильна мовна модель або потік із надзвичайно дрібними зображеннями.
Чи завантажується .sup або його зображення кудись?
Ні. Розпізнавач працює у вкладці, а його робочий потік, ядро WebAssembly і мовна модель віддаються з цього сайту й кешуються браузером. Єдині запити сторінки — за цими файлами. Тут це важливіше, ніж на текстовій сторінці: потік PGS, витягнутий з диска, часто є тим матеріалом, який студія або юрист найменше хочуть віддавати третій стороні, і вся суть сторінки в тому, що віддавати не потрібно.