Виправити 29,97 fps на 23,976 fps
Або вставте текст субтитрів
Параметри
У якій частоті кадрів пораховано таймінги. На сторінках форматів це те, що потрібно MicroDVD, бо він зберігає час як номери кадрів. На сторінках частоти кадрів це частота, за якою файл синхронізували — версія, для якої робили субтитри, — а друге поле сторінки приймає частоту відео, з яким ви будете їх використовувати. 23,976, 24, 25, 29,97, 30, 50, 59,94 і 60 — найпоширеніші. Помилка зміщує весь таймлайн, а на сторінках частоти кадрів — на відношення, а не на фіксовану величину.
Частота кадрів версії, з якою ви будете використовувати субтитри, — відео, яке насправді відтворюватимете. Застосовується множник: перше поле, поділене на це, тож 24 у 25 дає 0,96: фільм на PAL іде на 4 % швидше, і 100-хвилинна стрічка вкладається в 96-хвилинну касету. Переплутайте поля місцями — і весь таймлайн зсунеться в неправильний бік на ту саму величину.
Ця сторінка бере файл субтитрів, чию шкалу порахували за 29,97 кадру на секунду, і переносить її на шкалу 23,976. Кожна позначка множиться на 1,25 — рівно п’ять четвертих, — тому файл виходить на чверть довшим: репліка на сорок восьмій секунді стає реплікою на першій хвилині, а репліка, що каже «двадцять чотири хвилини» в серії на тридцять хвилин, повертається до тридцяти. Обидва поля вже заповнені; змініть їх, якщо ваш файл пораховано за чимось іншим.
Помилка та сама, що й у дзеркальної пари, лише з іншого кінця. Номери кадрів, поділені на 29,97, коли вони належали шкалі 23,976, виходять на чверть замалими, бо 23,976, поділене на 29,97, — це 0,8; тому вся шкала стиснута до чотирьох п’ятих довжини, і кожен субтитр з’являється на 20 % раніше, дедалі сильніше випереджаючи в міру розгортання фільму. Множення на 1,25 — це та сама похибка, поділена назад.
Розпізнати, у який бік ви дивитеся, — і є вся робота, а симптом це підказує. Субтитри, що відстають і відстають дедалі більше, коли 24-хвилинна серія має останню репліку на тридцятій хвилині, потребують 0,8. Субтитри, що з’являються рано й випереджають дедалі більше, коли 24-хвилинна серія має останню репліку на двадцять четвертій хвилині при тридцятихвилинній серії, потребують цієї сторінки. Обидва файли збудовані з тих самих неправильно поділених номерів кадрів; різниться лише напрямок помилки.
1,25 точне з тієї самої причини, що й дзеркальне: 29,97 — це 30000/1001, а 23,976 — 24000/1001, тому спільне ділення на 1001 скорочується, і 29,97 на 23,976 — це просто 30000 на 24000: п’ять четвертих, без округлень і залишку. Кожна репліка отримує на чверть більше часу на екрані, тому швидкість читання кожного рядка падає на 20 % — це єдиний напрямок у групі, який зменшує навантаження, а не додає. Нічого не надсилається на сервер, і цілий сезон проходить через чергу за один прохід — SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON і CSV читаються як те, чим вони насправді є.
Приклади
Чверть повністю
Вхід
1
00:00:01,000 --> 00:00:03,000
Hello there.
2
00:01:00,000 --> 00:01:02,000
One minute in.
Результат
1
00:00:01,250 --> 00:00:03,750
Hello there.
2
00:01:15,000 --> 00:01:17,500
One minute in.
1,25 — це 29,97, поділене на 23,976. Репліка на першій секунді додає 250 мс, а на хвилині — 15 000 мс: у шістдесят разів далі від нуля, у шістдесят разів більше руху. Обидві межі кожної репліки множаться, тому дворядкова репліка на дві секунди отримує 2,5 секунди, і саме з цього запасу походить покращення швидкості читання.
Раніше на чверть минулого часу
Вхід
1
00:08:00,000 --> 00:08:02,000
Eight minutes in.
2
00:24:00,000 --> 00:24:02,000
Twenty-four minutes in.
Результат
1
00:10:00,000 --> 00:10:02,500
Eight minutes in.
2
00:30:00,000 --> 00:30:02,500
Twenty-four minutes in.
На восьмій хвилині репліка йде на дві хвилини раніше, на двадцять четвертій — на шість: в обох випадках чверть минулого часу, а так виглядає проблема відношення, а не зсуву. Після перерахунку перевіряють останню репліку: відкрийте файл на її новій позначці, і рядок має бути на місці; якщо він там, усе перед ним теж правильне.
Кадри стоять, оголошення рухається
Вхід
{1}{1}29.97
{300}{360}Hello
Результат
{1}{1}23.976
{300}{360}Hello
MicroDVD рахує кадрами, і з кадрами все було гаразд — винна частота, на яку їх ділили. Кадр 300, оголошений за 29,97, читається як десять секунд — саме це передчасність і викликає; оголошений за 23,976 він читається як дванадцять з половиною, і там ця репліка й має бути. Тому редагується перший рядок, а жоден номер кадру не чіпається: переписування застосувало б зайву чверть двічі.
Часті запитання
Чому множник для 29,97 на 23,976 дорівнює рівно 1,25?
Бо обидві частоти — це кругле число, поділене на 1001: 29,97 — 30000/1001, а 23,976 — 24000/1001, тож ділення одного на друге скорочує 1001 і залишає 30000 на 24000, тобто п’ять четвертих. Нічого не округлюється й не наближається, тому репліка на сорок восьмій секунді лягає рівно на першу хвилину.
Мої субтитри з’являються зарано й далі випереджають — це та пара?
Перевірте, чи передчасність становить чверть минулого часу. Дві хвилини на восьмій хвилині, шість на двадцять четвертій і двадцять чотири хвилини в двогодинному фільмі — це саме ця пара. Дзеркальна сторінка обробляє протилежний симптом: субтитри, що відстають і відстають дедалі більше, потребують 0,8, а не 1,25.
Чи можна цією парою піти з NTSC-відео одразу в PAL?
Ні, і шлях через цю сторінку навмисно довший. 29,97 на 25 — це 1,19880, і окремої сторінки для цього немає, бо 29,97 — частота сигналу, а не швидкість відтворення зображення; фільм усередині доповнений повтореними кадрами, які не змінюють часу перегляду. Чесний шлях від NTSC-шкали до PAL — спершу повернутися до частоти фільму, тобто цей перерахунок, а потім 23,976 на 25.
Відео 29,97, а субтитри виглядають правильно — чи зіпсує їх ця сторінка?
Зіпсує, і це дзеркало пастки з іншої сторінки. Фільм у NTSC-сигналі проходить pulldown, який повторює кадри, не змінюючи часу перегляду, тому файл, зроблений під таке відео, уже правильний. Перераховувати треба лише файл, чиї номери кадрів поділили на неправильну частоту; множення правильного файлу на 1,25 робить кожен субтитр на чверть пізнішим.
Що станеться з тривалістю реплік і швидкістю читання, коли шкала зросте на чверть?
Кожна репліка додає 25 % тривалості й рухається пізніше, тому дворядкова репліка на дві секунди отримує 2,5 секунди, а слова залишаються точно як були. Це знижує швидкість читання кожного рядка на 20 %, що робить цю пару однією з двох у групі, які зменшують тиск на файл, а не додають його; друга — половинення 50 на 25.
Який робочий процес залишає файл раніше, а не пізніше?
Той, що вважав частоту контейнера частотою зображення. NTSC несе 29,97, тому інструмент, який зчитує це число з відео й ділить на нього номери кадрів, недооцінить будь-який фільм усередині сигналу, бо сам фільм іде за 23,976, а pulldown був лише заповненням. Ліки — оголосити частоту, за якою зображення справді йде, і це робить ця сторінка: 29,97 першим, 23,976 другим.