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 % раньше, всё сильнее по ходу фильма. Текст и порядок реплик не меняются, в MicroDVD правится только объявление частоты, ничего не загружается на сервер, и целый сезон проходит через очередь за один запуск.
Примеры
Четверть целиком
Вход
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?
Потому что обе частоты — круглое число, делённое на 1 001: 29,97 — это 30 000/1001, а 23,976 — 24 000/1001, поэтому при делении одного на другое 1 001 сокращается и остаётся 30 000 на 24 000, то есть пять четвёртых. Ничего не округлено и ничего не приближено, поэтому реплика на сорока восьми секундах попадает ровно на минуту.
Мои субтитры появляются слишком рано и спешат всё сильнее — это та пара?
Проверьте, составляет ли спешка четверть прошедшего времени. Две минуты на восьмиминутной отметке, шесть на двадцатичетырёхминутной и двадцать четыре минуты в двухчасовом фильме — это ровно эта пара. Зеркальная страница разбирает противоположный симптом: субтитры, которые опаздывают и опаздывают всё сильнее, требуют 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 вторым.