Масштабировать тайминг субтитров
Или вставьте текст субтитров
Параметры
Процент: 100 оставляет файл как есть, 50 вдвое сокращает весь таймлайн. Для частоты кадров коэффициент — исходная частота, делённая на целевую: файлу, рассчитанному под кино, но нужному для PAL 25 fps (на 4% быстрее), нужно 96; файлу под PAL для возврата к мастеру 24 fps нужно 104,1667. Каждое начало и каждый конец умножаются на одно и то же отношение, поэтому длины реплик и промежутки между ними меняются вместе.
В какой частоте кадров считается тайминг. На страницах форматов это то, что нужно MicroDVD: он хранит время в номерах кадров. На страницах частоты кадров это частота, по которой файл был рассчитан, — версия, для которой делались субтитры, — а второе поле страницы принимает частоту видео, с которым вы будете их использовать. Обычные значения: 23,976, 24, 25, 29,97, 30, 50, 59,94 и 60. Ошибка сдвигает весь таймлайн, а на страницах частоты кадров — на коэффициент, а не на фиксированную величину.
Эта страница умножает каждый таймкод файла субтитров на процент: 104,1667 растягивает всю шкалу, 96 сжимает её, а 50 укорачивает файл вдвое. Начало и конец каждой реплики умножаются на одно и то же отношение, поэтому длины реплик и паузы между ними меняются вместе, а чем позже стоит субтитр, тем дальше он уезжает.
Именно поэтому пропорция лечит дрейф, а не смещение: файл, который опаздывает на две секунды в первую минуту и на две минуты в последнюю, ошибся не в начале, а в скорости, и постоянный сдвиг только испортит начало. Классический случай — разница частот кадров: плёнка на PAL идёт на 4% быстрее, поэтому фильм на 100 минут укладывается в 96 минут, и файл, рассчитанный по плёнке, сжимают на 96, а файл, рассчитанный по PAL, растягивают на 104,1667.
SRT, WebVTT, ASS, SSA, SBV, SMI, MicroDVD, TTML, JSON и CSV читаются по содержимому, обычный текст и LRC не принимаются, потому что в них нет времени окончания; всё считается в браузере, и файлы никуда не отправляются.
Примеры
Отмена 4-процентного ускорения PAL
Вход
1
00:00:01,000 --> 00:00:03,000
Hello there.
2
00:00:05,000 --> 00:00:08,000
Second line.
Выход
1
00:00:01,042 --> 00:00:03,125
Hello there.
2
00:00:05,208 --> 00:00:08,333
Second line.
Масштаб 104,1667 — это 25 делить на 24, множитель, который возвращает файл, рассчитанный по PAL 25 fps, на плёночный мастер 24 fps. Первая реплика открывается на секунде и едет на 42 мс, вторая на пятой секунде — на 208 мс: в пять раз дальше от нуля, в пять раз больше движение.
Почему именно пропорция исправляет накопленный дрейф
Вход
1
00:00:00,000 --> 00:00:02,000
Opening line.
2
00:01:00,000 --> 00:01:02,000
One minute in.
3
00:10:00,000 --> 00:10:02,000
Ten minutes in.
Выход
1
00:00:00,000 --> 00:00:02,083
Opening line.
2
00:01:02,500 --> 00:01:04,583
One minute in.
3
00:10:25,000 --> 00:10:27,084
Ten minutes in.
Снова 104,1667: первая строка почти не двигается, минутная отметка едет на две с половиной секунды, десятиминутная — на двадцать пять. Постоянный сдвиг выровнял бы любую одну из трёх и оставил бы две другие неверными, а пропорция выравнивает все сразу.
Сжатие файла, чтобы он уложился
Вход
1
00:00:10,000 --> 00:00:12,000
First.
2
00:01:00,000 --> 00:01:03,000
Second.
Выход
1
00:00:08,000 --> 00:00:09,600
First.
2
00:00:48,000 --> 00:00:50,400
Second.
Масштаб 80: каждая реплика сохраняет 80% длины и стоит на 80% своего расстояния от нуля, поэтому строка, висевшая две секунды, получает 1,6 секунды. При сжатии следите за скоростью чтения: слова короче не стали, времени на них стало меньше.
Частые вопросы
Какой процент нужен для пересчёта субтитров между 24 и 25 fps?
Множитель всегда равен исходной частоте кадров, делённой на целевую. Файл, рассчитанный по плёнке 24 fps и нужный для PAL 25 fps, умножают на 96; файл, рассчитанный по PAL и возвращаемый на плёночный мастер, — на 104,1667, то есть 25 делить на 24. Для 23,976 fps те же два направления дают 95,904 и 104,2708, потому что 23,976 — не ровно 24.
Почему поздние субтитры двигаются сильнее ранних?
Потому что отношение применяется к расстоянию от нуля, а не к длине реплики. Реплика на первой секунде при 104,1667 сдвигается примерно на 42 мс, а реплика на десятой минуте — на 25 секунд. Именно это позволяет исправлять дрейф, а не просто сдвигать всё на константу.
Меняет ли масштабирование длительность показа каждой реплики?
Да, пропорционально. Оба края умножаются на одно отношение, поэтому двухсекундная реплика при 80% становится 1,6 секунды, а при 150% — тремя секундами. Сжатие приближает каждую реплику к пределу скорости чтения, растяжение даёт больше времени.
Может ли масштабирование создать пересечение субтитров?
Нет. Умножение на положительное отношение монотонно, и округление до целых миллисекунд это сохраняет, поэтому две реплики, которые не пересекались, не начнут пересекаться. Сжатие уменьшает паузы и может свести их к касанию, что некоторые плееры показывают как мигание, но порядок реплик не меняется.
Что происходит с репликой, которая слишком коротка для выбранного масштаба?
Она удаляется, и число удалённых показывается отдельно. У реплики в 20 мс при масштабе 1% оба края округляются к одной и той же миллисекунде, и записывать уже нечего; дополнять её до минимальной длины значило бы оставить в файле невидимую реплику, а это хуже, чем удалить и сказать.
Остаётся ли первый субтитр файла на месте?
Только если он начинается с нуля. Всё отсчитывается от начала шкалы, поэтому у файла, первая реплика которого открывается на 00:01:00, вступление масштабируется вместе с остальным. Если начальная минута — фиксированная заставка, нужен постоянный сдвиг, а не пропорция.