Видео и субтитры · Инструментарий субтитров
Почему случайные теги в файле субтитров могут нарушить загрузку титров платформы
· Почему это важно
субтитры обработка текста вебвтт
Платформы анализируют подписи, которые загружаются строго и часто молча. В этом посте объясняются распространенные причины, по которым файл субтитров отклоняется или отображается странно, почему теги и коды форматирования являются обычными виновниками и как чистый стандартный файл позволяет избежать этой проблемы.
Загрузка была принята, и в заголовках отображаются буквальные теги — тихий сбой нечистого файла.
Самый худший исход – это не отказ. Отклоненная загрузка говорит о том, что что-то не так, пока вы все еще смотрите на форму. Обычным результатом является принятие, за которым следуют подписи, которые отображают для зрителей свою собственную разметку, поскольку проверка загрузки и путь рендеринга — это разные части программного обеспечения, задающие разные вопросы.
Проверка загрузки обычно спрашивает, анализируется ли вообще файл на реплики. Рендеринг спрашивает, что делать с содержимым каждого сигнала, и анализатор, игнорирующий незнакомый тег, рисует его как текст. Оба шага сделали то, для чего были предназначены.
Какие платформы на самом деле поддерживают — простой SRT и WebVTT с предсказуемой структурой и небольшой терпимостью к дополнительным возможностям.
То, что принимают платформы, уже, чем то, что выдают инструменты. На практике это означает обычный SRT или WebVTT с предсказуемой формой: блоки, разделенные пустыми строками, строка тайм-кода, текстовые строки и многое другое. Толерантность к дополнительным элементам низкая и, что более важно, недокументированная, поэтому можно с уверенностью предположить, что все, что выходит за рамки этой формы, является скорее риском, чем особенностью.
Это не консерватизм сам по себе. Платформе, которая принимает произвольную разметку, придется решать, как последовательно отображать ее в веб-клиентах, мобильных и телевизионных клиентах, а это гораздо более серьезное обязательство, чем принятие файла субтитров.
Обычные виновники — теги типа HTML, коды в стиле ASS, спецификации, смешанные окончания строк и пустые сигналы.
Повторяющихся виновников немного. Теги угловых скобок для курсива, голосов говорящих и классов реплик сохраняются при преобразовании из поддерживающих их форматов. Коды переопределения, разделенные скобками, поступают из форматов SubStation и ничего не значат за их пределами. Метка порядка байтов в начале файла прикрепляется к первому индексному номеру. Смешанные окончания строк из-за разделения блоков разрывов кросс-платформенного редактирования. Сигналы, текст которых стал пустым после удаления разметки, остаются пустыми с отметкой времени.
Ничто из этого не является экзотикой. Они являются обычным результатом цепочки преобразований, где каждый шаг был индивидуально обоснован, поэтому они появляются в файлах, которые хорошо выглядят в редакторе.
Почему одна платформа терпит то, что отвергает другая — разные парсеры, стоящие за одинаковыми формами загрузки
Разные платформы допускают разные подмножества, и именно это затрудняет диагностику неисправности. Один и тот же файл может загрузиться без ошибок и правильно отобразиться в одном сервисе, загрузить и отобразить разметку во втором и быть отклонен третьим без сообщения об ошибке, указывающего фактическую причину. Файл не менялся между попытками; три парсера не согласились.
Поэтому рассматривать одну платформу как эталон — неправильный инстинкт. Файл, который работает в наиболее разрешающем сервисе, ничего не сообщает вам о других, а самый строгий анализатор — это тот, который определяет, является ли файл переносимым.
Рабочий пример: один файл, три загрузки — как один и тот же мусор проявляется по-разному и исчезает после очистки
Возьмите один экспорт, содержащий код переопределения начала кадра для шестидесяти сигналов, теги выделения для сорока и метку порядка байтов. Загруженный на три сервиса, он может быть принят везде. В первом случае теги учитываются, и код переопределения рисуется буквально. На втором оба отображаются в виде текста. На третьем знак стоит первую реплику, которая просто никогда не появляется, и никто не замечает, потому что первая строка обычно является заголовком.
Однократная очистка удаляет все три класса в источнике. Теги угловых скобок и коды фигурных скобок заменяются, оставшиеся пробелы сворачиваются, реплики, очищенные в результате удаления, отбрасываются, а не выдаются как пробелы с отметкой времени, а файл перезаписывается с перенумерацией реплик, непрерывных от одной. Затем один и тот же вывод поступает во все три службы.
Что здесь не распространяется — руководства по стилю для конкретных платформ, ограничения на количество символов в строке и встроенные подписи.
Это касается структурной переносимости, а не редакционного соответствия. Руководства по стилю платформы по длине строки, максимальному количеству символов, расположению меток говорящих и обработке звуковых эффектов — это отдельные требования, которым чистый файл не удовлетворяет автоматически. Структурно идеальный файл подписей все равно может нарушить руководство по стилю.
Встроенные подписи — это совершенно другой механизм. Текст, отображаемый в видеокадрах, не является файлом титров, его нельзя отключить, и на него не влияет ничего, описанное здесь.
Вывод: очистите один раз, загрузите куда угодно — как функции очистки и преобразования Subtitle Toolkit создают файл, удобный для платформы.
Почистите один раз и загрузите везде один и тот же файл. Альтернатива, поддерживающая отдельный экспорт для каждой платформы, увеличивает количество файлов, которые могут не синхронизироваться с основным файлом, и не удаляет основной беспорядок ни из одного из них.
Запустите очистку и преобразование одновременно, а затем прочитайте сообщения о проблемах перед загрузкой, а не после нее. Имя проблемы соответствует номеру, который определяет разницу между знанием того, что в файле есть проблема, и знанием, на какую строку смотреть.