Знайти репліки, що кінчаються до початку
Або вставте текст субтитрів
Параметри
У якій частоті кадрів пораховано таймінги. На сторінках форматів це те, що потрібно MicroDVD, бо він зберігає час як номери кадрів. На сторінках частоти кадрів це частота, за якою файл синхронізували — версія, для якої робили субтитри, — а друге поле сторінки приймає частоту відео, з яким ви будете їх використовувати. 23,976, 24, 25, 29,97, 30, 50, 59,94 і 60 — найпоширеніші. Помилка зміщує весь таймлайн, а на сторінках частоти кадрів — на відношення, а не на фіксовану величину.
Репліка, що закінчується раніше, ніж починається, — це таймкод, якого не може бути: 00:00:03,000 --> 00:00:03,000 або, гірше, кінець раніше за початок. Ця сторінка повідомляє про файли, що містили такий таймкод, рахуючи за виправленнями, які довелося зробити читачеві, бо таймкод такої форми взагалі не можна втримати в пам’яті його замінюють справжнім, перш ніж щось інше відбудеться. Повертається звіт, ніколи не змінений файл.
Саме тому звіт починається з того, що втрачено під час читання, і лише потім показує висновок. Репліці, чий кінець не пізніший за початок, дають одну мілісекунду, щоб решту файлу взагалі можна було прочитати, переглянути й експортувати; кількість таких виправлень стоїть у заголовку звіту, а висновок під ним каже про одну помилку без номера репліки, бо виправлення рахують під час читання, а не зберігають списком. Обидва рядки описують один зламаний таймкод із двох боків, тому й належать одному звітові, а не двом.
Пастка, навколо якої довелося писати цю сторінку, у тому, що законна репліка на одну мілісекунду виглядає точно як виправлена. Тому перевірка взагалі не дивиться на тривалість — вона дивиться на запис про виправлення, і репліку, що справді триває одну мілісекунду, залишають осторонь. Від’ємна тривалість і нульова — та сама вада й рахуються разом. Два формати не приймаються взагалі, і цього разу причина однакова з обох боків: LRC виводить кожен час кінця з наступної позначки, тому пара там не може вийти перевернутою, а звичайний текст не має часів реплік. Перевірка будь-якого з них дала б чистий звіт про поле, якого формат не має, — єдиний вид відповіді, гірший за відсутність відповіді.
Приклади
Кінець дорівнює початку
Субтитри
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,000
I was working late.
Що знаходить звіт
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
Кінець дорівнює початку. Читач дає репліці одну мілісекунду, щоб файл можна було втримати, записує виправлення, і звіт друкує обидві половини: рядок втрат у заголовку й одну помилку під ним. Виправлення є доказом; мілісекунда — лише форма, якої доказ набуває.
Справжня мілісекундна репліка
Субтитри
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,001
I was working late.
Що знаходить звіт
Cues ending before they start — Nothing found
Cues 2
Checks run 1
Lost while reading Nothing
Написана вручну репліка на одну мілісекунду й не показана. Це рішення й формує перевірку: виправлена репліка нульової довжини теж виходить на одну мілісекунду, тому правило, яке позначало б короткі тривалості, назвало б кожен файл зі зламаним таймкодом повним неможливо коротких реплік.
Кінець раніше за початок
Субтитри
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:05,000 --> 00:00:02,000
I was working late.
Що знаходить звіт
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
Від п’яти секунд до двох: та сама вада, що й нульова тривалість, порахована тим самим правилом і показана однаково. У файлі нічого не переписується: виправлені часи існують у копії читача, щоб решту файлу можна було обробити, і не є виправленням, яке сторінка пропонує.
Часті запитання
Що вважається реплікою з кінцем до початку?
Репліка, у якій час кінця не пізніший за час початку: нульова тривалість або кінець раніше за початок. Обидва випадки — та сама вада й рахуються одним правилом. Перевірка не дивиться на короткі тривалості взагалі, тому справжня репліка на одну мілісекунду не потрапляє у висновки.
Чому звіт не називає репліки, яких це стосується?
Бо виправлення рахують під час читання файлу, а не зберігають списком із номерами. Після виправлення у пам’яті вже немає початкового зламаного таймкоду, на який можна вказати, тому звіт показує кількість виправлень у заголовку й один висновок без номера.
Чи є проблемою репліка, що триває одну мілісекунду?
Ні. Саме це рішення формує перевірку: виправлена репліка нульової довжини теж виходить на одну мілісекунду, тому правило, яке позначало б короткі тривалості, назвало б кожен файл зі зламаним таймкодом файлом із неможливо короткими репліками. Справжня мілісекундна репліка залишається осторонь.
Чи виправляє сторінка знайдені таймкоди?
Ні. Виправлені часи існують лише в копії читача, щоб решту файлу можна було обробити, і не пропонуються як виправлення. Оригінал не переписується й нікуди не завантажується, а звіт лише описує, скільки виправлень довелося зробити.
Які формати субтитрів можна перевірити на кінець до початку?
Десять форматів, що зберігають і початок, і кінець: SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON і CSV. LRC і звичайний текст не приймаються: LRC виводить кінець із наступної позначки, а звичайний текст не має часів реплік.
Звідки беруться такі зламані таймкоди?
Зазвичай з інструментів, що зсувають або об’єднують репліки без перевірки межі: зсув назад може зробити кінець ранішим за початок, а об’єднання — залишити нульову пару. Руками таке трапляється рідше, але після кількох проходів автоматики файл накопичує кілька таких місць.
Чи можна перевірити кілька файлів за один запуск?
Так. Кожен файл проходить перевірку окремо й отримує власний звіт, а кількість виправлень рахується для кожного файлу. Пакетна обробка не змішує висновки й не змінює жодного оригіналу.