비디오 및 자막 · 자막 툴킷
자막 시간 코드 비교: SRT 쉼표, VTT 도트 및 SMPTE 프레임
· 배경
자막 타임코드 프레임 속도
캡션 작업에는 SRT의 HH:MM:SS,mmm, WebVTT의 HH:MM:SS.mmm 및 SMPTE의 HH:MM:SS:FF라는 세 가지 작성 시간 방식이 표시됩니다. 이 게시물에서는 각각의 의미, 변환 방법, 변환이 잘못된 위치를 설명합니다.
같은 순간을 세 가지 방식으로 기록 — 편집자가 한 프로젝트에서 만나는 타임코드를 빠르게 둘러보기
하나의 프로젝트는 세 가지 방식으로 작성된 동일한 인스턴트를 편집자에게 전달할 수 있습니다. 자막 파일은 밀리초 앞에 시간, 분, 초 및 쉼표를 사용합니다. 웹 캡션 파일은 동일한 위치에 점을 사용합니다. 편집 결정 목록은 분수 대신 프레임 번호를 사용합니다. 세 개 모두 같은 순간을 언급하고 있으며 그 중 하나만 읽을 수 있으며 자료에 대한 다른 정보는 없습니다.
마지막 사항이 중요합니다. 이러한 표기법 중 두 개는 절대적이고 하나는 그렇지 않습니다. 차이점을 간과하면 특정한 방식으로 두 표기법 간의 변환이 실패합니다.
쉼표가 있는 밀리초: SRT — 형식 규칙이 된 유럽의 소수 습관
SRT는 시, 분, 초, 쉼표 및 정확히 세 자리 밀리초를 씁니다. 쉼표는 유럽 규정의 소수 구분 기호로, SubRip에는 이를 수정할 표준 문서가 없었기 때문에 사양보다는 용도에 따른 형식 규칙이 되었습니다. 그 가치에 있어서 유럽적인 것은 없습니다. 마침표만 있습니다.
여기서 파서는 오른쪽에서 찾은 숫자를 3까지 채워서 밀리초를 읽습니다. 따라서 한 자리로 끝나는 타임스탬프는 단위가 아닌 수백 밀리초로 읽혀집니다. 손으로 또는 느슨한 변환기로 작성된 파일이 항상 세 자리 숫자를 제공하는 것은 아니며 뒤따르는 단일 숫자를 단위로 읽으면 큐가 거의 1초 일찍 배치되기 때문에 이것이 중요합니다.
점이 있는 밀리초: WebVTT — 동일한 값, 다른 구분 기호, 파서에 중요한 이유
WebVTT는 점으로 동일한 값을 쓰고 시간 필드를 완전히 생략할 수 있도록 허용하므로 SRT에서 3이 필요한 경우 2필드 형식이 유효합니다. 파서에게 이는 완전히 다른 문법이므로 파일의 모든 숫자가 정확함에도 불구하고 구두점만으로 파일이 거부될 수 있습니다.
실제 파일은 두 가지를 지속적으로 혼합하므로 파서는 파일이 주장하는 형식에 관계없이 구분 기호 중 하나를 허용합니다. 해당 공차는 입력에만 적용됩니다. 출력 시 구분 기호는 대상 형식, 즉 SRT의 경우 쉼표, WebVTT의 경우 점으로 선택되므로 변환된 파일은 도착한 불규칙성의 복사본이 아니라 표준입니다.
프레임: SMPTE 시간 코드 — HH:MM:SS:FF, 프레임 속도에 대한 의존성 및 드롭 프레임 합병증
SMPTE 시간 코드는 소수 부분을 프레임 번호로 대체하여 시간, 분, 초 및 프레임을 제공합니다. 다른 두 프레임과 달리 단독으로 해석할 수 없습니다. 프레임 12는 초당 25프레임과 30프레임의 순간이 다르기 때문에 선언된 속도가 없는 프레임 기반 타임코드는 단순히 모호한 것이 아니라 불완전합니다.
드롭 프레임은 두 번째 합병증을 추가합니다. 초당 29.97 프레임의 자료는 30프레임인 것처럼 계산되며, 시계와 일치하도록 카운트를 유지하기 위해 대부분의 분 시작 시 두 개의 프레임 번호를 건너뛰고 매 10분마다 제외됩니다. 프레임은 삭제되지 않습니다. 라벨만 있습니다. 드롭 프레임 시간 코드는 계산 규칙이며 이를 일반 프레임 수로 취급하면 프로그램 전체에서 오류가 증가합니다.
프레임을 밀리초로 변환 — 작지만 실제 오류를 생성하는 산술 및 반올림
프레임을 밀리초로 변환하는 것은 프레임 속도로 나누는 것이며, 반올림은 작은 오차가 들어가는 부분입니다. 프레임 인덱스를 속도로 나누고 1000을 곱한 값이 1밀리초에 도달하는 경우는 거의 없으며 결과를 반올림하여 저장해야 합니다. 내부적으로 큐는 0부터 계산되는 전체 밀리초로 유지되므로 해당 표현으로의 모든 변환은 한 번 반올림됩니다.
한 번의 반올림은 무해합니다. 주의해야 할 오류는 반복되는 변환입니다. 프레임에서 밀리초로 가져온 파일을 다른 속도로 프레임으로 다시 전달한 다음 다시 전달할 때마다 반올림이 누적되며 이러한 오류는 취소되지 않습니다. 여러 도구를 통해 파일을 전달하는 대신 신뢰할 수 있는 소스에서 한 번만 변환하세요.
작업된 예: 25 fps 및 29.97 드롭 프레임에서 하나의 큐 — 둘 다 밀리초로 변환하고 비교
1분 30초 12프레임에 1개의 신호를 받습니다. 초당 25프레임에서 12프레임은 12/25초입니다. 이는 정확히 480밀리초이므로 순간은 9만4백80밀리초입니다.
29.97 드롭 프레임에서는 동일한 라벨이 다른 순간입니다. 프레임 수를 계산합니다. 명목상 30초의 90초는 2,700에 12를 더한 값에서 첫 번째 분에 삭제된 두 개의 레이블을 뺀 2,710프레임이 됩니다. 실제 비율인 3만 분의 1천1분의 1로 나누면 그 순간은 약 9만424밀리초입니다. 두 타임코드는 거의 동일해 보이지만 대략 56밀리초 정도 차이가 납니다. 이는 검토할 수 있을 만큼 작고 타이트한 큐에서 볼 수 있을 만큼 큽니다.
여기에 포함되지 않는 내용 — 99 이후 시간, 컨테이너 메타데이터의 음수 시간 및 시간 코드
이는 자막 파일이 전달하는 타임코드 표기법을 다룹니다. 일부 시스템에서 경과 시간 대신 릴 식별을 위해 사용하는 99개 이상의 시간 필드는 포함하지 않으며, 자막 형식으로 표현할 수 없는 음수 시간도 포함하지 않습니다. 1을 생성하는 교대는 0으로 고정됩니다.
컨테이너 메타데이터에 저장된 타임코드도 범위를 벗어납니다. 비디오 파일에는 그 안에 있는 모든 것을 오프셋하는 시작 타임코드가 포함될 수 있으므로 프로그램에 대해 올바른 자막 파일이 파일에 대해 잘못된 것처럼 보일 수 있으며 자막 타임스탬프를 아무리 조사해도 그 사실이 드러날 수 없습니다.
요점: 읽고 있는 시계가 무엇인지 확인하세요. 자막 도구 키트가 SRT와 WebVTT 시간 코드를 정확하게 변환하는 방법을 알아보세요.
어떤 시계를 읽고 있는지 알아보세요. 쉼표와 점은 서로 다른 파서에 대해 작성된 동일한 값이며, 둘 사이를 변환하면 구두점만 변경되고 다른 것은 변경되지 않습니다. 프레임 수는 다른 종류의 숫자로, 속도가 없으면 의미가 없으며 속도가 드롭 프레임인 경우 오해의 소지가 있습니다.
툴킷을 사용하여 SRT과 WebVTT 간을 변환하고 전후의 타임스탬프를 비교합니다. 구분 기호는 변경되어야 하고 숫자는 변경되어서는 안 됩니다. 숫자가 이동했다면 파일은 어딘가에서 프레임 기반 단계를 거쳤으며, 이것이 바로 변환입니다.