끝이 시작보다 빠른 자막
또는 자막 텍스트를 붙여넣으세요
옵션
타이밍을 어떤 프레임 레이트 기준으로 세는지 정합니다. 형식 안내 페이지에서는 MicroDVD가 이 값을 필요로 합니다. 시간을 프레임 번호로 저장하기 때문입니다. 프레임 레이트 페이지에서는 이 파일이 어느 프레임 레이트를 기준으로 만들어졌는지, 즉 자막을 만든 판본의 값을 뜻하며, 페이지의 두 번째 상자에는 이 자막을 사용할 영상의 프레임 레이트를 넣습니다. 흔히 쓰는 값은 23.976, 24, 25, 29.97, 30, 50, 59.94, 60입니다. 잘못 넣으면 시간축 전체가 어긋나고, 프레임 레이트 페이지에서는 고정된 양이 아니라 비율로 어긋납니다.
끝이 시작보다 빠른 블록은 참일 수 없는 타임코드입니다. 00:00:03,000에서 00:00:03,000처럼 끝과 시작이 같거나, 더 나쁘게는 끝이 시작보다 이른 경우입니다. 이 페이지는 그런 블록이 있던 파일을 보고하며, 블록 자체가 아니라 리더가 해야 했던 복구에서 수를 셉니다. 그런 모양의 타임코드는 메모리에 담을 수 없어 다른 어떤 처리보다 먼저 실제 값으로 바뀌기 때문입니다. 돌아오는 것은 보고서이고, 수정된 파일은 아닙니다.
그래서 보고서는 읽는 동안 잃은 것을 먼저 보여 주고 그다음에 검출을 보여 줍니다. 끝이 시작보다 뒤가 아닌 블록에는 1ms를 주어야 나머지 파일을 읽고 미리보기하고 내보낼 수 있습니다. 그 복구 수는 보고서 머리말에 놓이고, 아래 검출은 블록 번호 없이 오류 하나를 말합니다. 복구는 읽으면서 집계될 뿐 목록으로 보관되지 않기 때문입니다. 두 줄은 같은 깨진 타임코드를 양쪽에서 설명하며, 그래서 두 보고서가 아니라 한 보고서에 있어야 합니다.
이 페이지를 쓸 때 피해야 했던 함정은 정당한 1ms 블록이 복구된 블록과 똑같이 보인다는 점입니다. 그래서 검사는 표시 시간을 전혀 보지 않고 복구 기록을 봅니다. 실제로 1ms 동안 지속되는 블록은 건드리지 않습니다. 음수 표시 시간과 0길이는 같은 결함으로 함께 셉니다. 받지 않는 형식이 두 가지인데, 이번에는 이유가 양쪽 모두 같습니다. 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
끝이 시작과 같습니다. 리더는 파일을 담기 위해 블록에 1ms를 주고 그 복구를 기록하며, 보고서는 머리말의 손실 줄과 아래의 오류 하나를 함께 인쇄합니다. 복구가 증거이고 1ms는 증거가 취하는 모양일 뿐입니다.
실제로 1ms 동안 지속되는 블록
자막
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
손으로 적은 1ms 블록이며 보고되지 않습니다. 이 판단이 검사의 모양을 정합니다. 복구된 0길이 블록도 1ms로 나오므로, 여기서 짧은 표시 시간을 잡는 규칙은 깨진 타임코드가 있는 모든 파일을 불가능하게 짧은 블록투성이로 만들 것입니다.
끝이 시작보다 이르다
자막
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
5초에서 2초로 끝납니다. 0길이 사례와 같은 결함이고 같은 규칙으로 세며 똑같이 보고됩니다. 파일의 어느 부분도 다시 쓰이지 않습니다. 복구된 시각은 나머지 파일을 처리할 수 있도록 리더의 사본에만 존재하고, 이 페이지가 제공하는 수정은 아닙니다.
자주 묻는 질문
끝이 시작보다 빠른 블록으로 무엇을 세나요?
끝 시각이 시작 시각보다 뒤가 아닌 모든 경우입니다. 00:00:03,000에서 00:00:03,000처럼 같거나, 00:00:05,000에서 00:00:02,000처럼 이른 경우입니다. 둘은 같은 결함으로 함께 세어지고, 그 모양의 타임코드는 메모리에 담을 수 없으므로 블록이 아니라 리더가 하는 복구에서 셉니다.
보고서에 관련 블록이 왜 나오지 않나요?
이 복구는 파일을 읽는 동안 집계될 뿐 목록으로 모이지 않기 때문입니다. 보고서는 개수를 줍니다. 오류 하나, 머리말 손실 줄의 항목 하나이며, 두 절반은 머리말과 검출에서 본 같은 사실입니다. 정확한 블록이 필요하면 블록 번호 대신 타임코드의 개수를 파일에서 찾아보는 편이 낫습니다.
1ms 동안 지속되는 블록은 문제인가요?
여기서는 아니며, 의도된 판단입니다. 손으로 쓴 1ms 블록은 합법이고 보고되지 않습니다. 보고되는 것은 복구해야 했던 타임코드이고, 그것이 결과적으로 1ms로 저장될 뿐입니다. 표시 시간을 보면 0길이 블록이 있는 모든 파일을 불가능하게 짧은 블록투성이로 판정하게 되는데, 그것은 두 번 틀린 검출입니다.
이 페이지가 찾은 타임코드를 고치나요?
아니요. 복구된 시각은 나머지 파일을 읽고 보고할 수 있도록 브라우저 안에만 존재합니다. 내려받았거나 끌어다 놓은 파일은 바뀌지 않고, 이 페이지에서 복구판을 저장할 방법도 없습니다. 깨진 타임코드를 교체하는 것은 검사가 아니라 자막 파일을 산출물로 내는 작업입니다.
어떤 자막 형식에서 끝이 시작보다 빠른 블록을 검사할 수 있나요?
열두 가지 중 열 가지입니다: SRT, WebVTT, ASS, SSA, SBV, SMI, MicroDVD, TTML, JSON, CSV. 빠진 둘은 실수가 아닙니다. LRC는 줄마다 시각이 하나이고 리더가 다음 타임스탬프에서 각 끝을 만들므로 쌍이 거꾸로 될 수 없습니다. 일반 텍스트에는 블록 시각이 없습니다. 그 두 형식이라면 먼저 변환하세요.
이런 깨진 타임코드는 어디서 생기나요?
거의 항상 입력이 아니라 생성됩니다. 반올림 방향이 틀린 프레임 레이트 변환, 같은 블록에 두 번 적용된 밀기, 끝 열이 비어 있어 0으로 읽힌 스프레드시트 내보내기, 처음부터 표시 시간이 없던 마커를 가진 시간 지정 텍스트에서 추출한 자막이 대표적입니다.
끝이 시작보다 빠른 자막도 여러 파일을 한 번에 검사할 수 있나요?
네. 원하는 만큼 넣으면 차례로 읽어 각각 보고서를 만들고, 보고서들은 하나의 zip으로 함께 내려옵니다. 대기열이 파일별 진행률을 보여 주고 중간에 취소할 수 있으며, 어느 시점에도 파일이 업로드되지 않습니다.