Drop-frame в non-drop-frame
Или вставьте текст субтитров
Параметры
30 fps non-drop и 29,97 drop-frame пишут одни и те же часы по-разному, и это поле выбирает, как файл читается и как записывается обратно. Реплика через час читается как 01:00:00,000 в одном и 01:00:03,600 в другом — разница 3,6 секунды в час, а не ошибка округления. Заголовок страницы называет одно направление, и поле предлагает только его, поэтому полученный файл — тот, о котором страница. В тексте ничего не меняется: ни одна реплика не пересчитывается относительно видео, частота кадров не преобразуется, а реплика в пределах первой минуты часа возвращается точно такой, какой вошла, потому что там не отбрасывается ни одна метка кадра.
В какой частоте кадров считается тайминг. На страницах форматов это то, что нужно MicroDVD: он хранит время в номерах кадров. На страницах частоты кадров это частота, по которой файл был рассчитан, — версия, для которой делались субтитры, — а второе поле страницы принимает частоту видео, с которым вы будете их использовать. Обычные значения: 23,976, 24, 25, 29,97, 30, 50, 59,94 и 60. Ошибка сдвигает весь таймлайн, а на страницах частоты кадров — на коэффициент, а не на фиксированную величину.
Эта страница переписывает каждый таймкод субтитров из 29,97 fps drop-frame обратно в 30 fps non-drop, поэтому каждая отметка уменьшается на величину, которая растёт с длительностью программы: внутри первой минуты часа — ни на сколько, через час — на 3,6 секунды, через десять часов — на 36 секунд. Слова, номера реплик, порядок реплик и переносы строк остаются собственностью файла и выходят нетронутыми.
Drop-frame не имеет меток ;00 и ;01 в начале каждой минуты, кроме каждой десятой, поэтому входное 00:01:00,000 невозможно записать в этой конвенции и оно притягивается назад к 00:00:59,933 — на 67 мс раньше; за два часа таких значений 216. Реплика, которая после приведения к сетке оказывается короче одного кадра (33,37 мс), не может быть записана и попадает в отчёт о потерях, а файл читается и записывается в этом браузере без отправки.
Примеры
Файл на пятой минуте
Вход
1
00:05:00,000 --> 00:05:02,000
The room is dark.
2
00:10:00,000 --> 00:10:03,000
A cold night.
Выход
1
00:04:59,667 --> 00:05:01,667
The room is dark.
2
00:09:59,400 --> 00:10:02,400
A cold night.
Поправка не одна на весь файл: на пятой минуте часы уходят назад на 333 мс, а на десятой — на 600 мс, потому что drop-frame выбросил десять меток к первой реплике и восемнадцать ко второй. Каждая реплика сохраняет длину до миллисекунды, поскольку оба её края сдвигаются на одну и ту же величину: это перезапись, а не сдвиг.
Та же правка на часе
Вход
1
01:00:03,600 --> 01:00:06,600
An hour into the programme.
Выход
1
01:00:00,000 --> 01:00:03,000
An hour into the programme.
На часе drop-frame передаёт 01:00:03,600 там, где non-drop называет 01:00:00,000 — это 108 выброшенных меток, то есть 3600 мс. С этим числом и стоит сверять страницу: первая строка результата должна быть ровно на 3600 мс раньше первой строки входа, а файл, снятый с drop-frame-устройства, должен попасть на круглый час.
Реплика внутри первой минуты
Вход
1
00:00:04,000 --> 00:00:06,000
Still early in the file.
2
00:05:00,000 --> 00:05:02,000
This one does move.
Выход
1
00:00:04,000 --> 00:00:06,000
Still early in the file.
2
00:04:59,667 --> 00:05:01,667
This one does move.
В течение первой минуты часа ни одна метка не выбрасывается, поэтому обе конвенции пишут эти шестьдесят секунд одинаково и первая реплика остаётся нетронутой. Вторая реплика на пятой минуте сдвигается. Одна реплика без изменений рядом с другой, которая сдвинулась, — правильный результат для этого файла, а не зависший прогон: поправка равна нулю в начале часа и растёт начиная с первой границы минуты.
Частые вопросы
Почему субтитры выходят раньше, а не позже?
Потому что часы в файле были больше тех моментов, которые они называют. Non-drop-frame считает 30 меток в секунду так, будто 29,97 fps выдаёт 30 кадров в секунду, и постепенно убегает вперёд реального времени; drop-frame выбрасывает две метки в минуту, чтобы оставаться с ним. Таймкод, снятый с drop-frame-устройства и прочитанный как non-drop, поэтому указывает дальше, чем нужно, и исправление вычитает этот избыток: 333 мс на пятой минуте, 3600 мс на часе, 36 000 мс на десяти часах. Для любой отметки внутри первой минуты часа поправка равна нулю, а ниже 00:00:00 время не опускается.
Что происходит с drop-frame таймкодом, который невозможно записать?
Он притягивается назад к последней метке, которую эта конвенция умеет записать. В каждой минуте drop-frame, кроме каждой десятой, отсутствуют метки ;00 и ;01, поэтому 00:01:00,000 и 00:01:00,010 не являются временами, которые можно отобразить: они попадают на 00:00:59,933, то есть на 67 мс раньше. Это единственное место на странице, где результат не является точной перезаписью, и оно ограничено: две метки на каждую минуту с выбросом, 216 значений за два часа. Если исходные значения лежали на сетке 30 fps, обратный прогон вне этого класса возвращает файл байт в байт, то есть ошибка кругового перехода равна 0 мс.
Может ли реплика исчезнуть из файла?
Только реплика короче одного кадра — 33,37 мс. Привести реплику к одному кадру могут две вещи: описанное притягивание, когда десятимиллисекундная реплика от 00:01:00,000 до 00:01:00,010 стягивается в 00:00:59,933, и реплика, которая была короче кадра ещё до обработки. Реплику, у которой начало и конец совпали, записать нельзя, поэтому она отбрасывается, а её число появляется в отчёте о потерях над рабочей областью. Если таких реплик нет, отчёт об этом ничего не говорит — обычный случай.
Меняется ли в файле что-то кроме значений таймкода?
Нет. Номера реплик, их порядок, текст каждой строки, жёсткие переносы внутри реплики и общее число реплик остаются такими, какими были в файле; страница переписывает только два числа на реплику. Она также нигде не записывает, что часы теперь non-drop, потому что ни один из читаемых форматов — SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON и CSV — не имеет поля для этой информации, и файл, который вы перетащили, её тоже не содержал.
Какую частоту кадров вводить в поле?
Любую, которая действительно есть у материала: на это преобразование она не влияет. 30 и 29,97 в названии страницы — это соглашения счёта, записанные в строке таймкода, а не частота кадров видео, поэтому введённое число ничего не масштабирует. Поле обязательно только потому, что MicroDVD хранит тайминги как номера кадров, и прочитать такой файл, не зная его частоты кадров, невозможно.
Если прогнать обратную страницу по этому результату, вернётся ли исходный файл?
Да, байт в байт, если ни один таймкод не попал в класс, который drop-frame не умеет записывать, и если исходные значения лежали на сетке 30 fps. Две страницы — это одна и та же арифметика в противоположных направлениях: эта вычитает растущую величину, обратная прибавляет её назад, и величина определяется положением каждой реплики, а не фиксированным смещением. Исключение — притягивание: 00:01:00,000, вышедшее как 00:00:59,933, вернётся как 00:00:59,933, и это единственный класс отметок, для которого пара страниц не даёт кругового перехода с ошибкой 0 мс.