타임코드의 세미콜론은 실제로 무엇을 말하는가

타임코드의 끝 구간이 콜론에서 세미콜론으로 바뀌는 것은, 보통 “이 타임코드 문자열이 드롭 프레임 표기로 표시된다”는 힌트입니다. 이것이 푸는 문제는 어떤 분수 프레임 속도에서 프레임 카운팅과 사람 시각이 장기간 어긋나는 일입니다. 그러나 전달 파일을 받을 때, 세미콜론은 힌트로만 취급할 수 있고, 그것만으로 프레임 위치가 드롭 프레임 규칙으로 환산되었음을 증명하지는 않습니다. 표시 표기와 계산 알고리즘은 나눠서 대조해야 합니다.

세미콜론은 “이 문자열이 드롭 프레임 표기를 표현하려는 뜻이다”라고 알려 주고, “이 문자열의 프레임 위치가 이미 드롭 프레임 규칙으로 계산되었다”를 자동으로 알려 주지 않습니다.

드롭 프레임 카운팅 표기가 왜 생기는가

29.97 같은 분수 프레임 속도는 초마다 실제로 나아가는 프레임 수가 정수 30으로 타임코드 번호를 매길 때의 박자와 완전히 같지 않습니다. 계속 연속 정수 프레임 번호로 표시하고 보상을 하지 않으면, 타임코드 읽기는 벽시계에 점점 뒤처집니다.

공식으로 환산하면 29.97 같은 연속 카운팅은 하루에 약 1분 반 규모까지 누적됩니다. 따라서 드롭 프레임 카운팅의방식은 비디오 프레임을 실제로 버리는 것이 아니라, 타임코드 번호 매기기에서 규칙에 따라 몇 번호를 건너뛰어, 표시 시계와 실제로 경과한 시간을 다시 가까이하리는 것입니다.

흔한 텍스트 관례는 끝 구간 구분자를 세미콜론으로 적는 것이고, 예를 들어 01:00:00;00처럼 씁니다. 이 기호는 유용합니다. 수신자가 한눈에 파일이 드롭 프레임 표기를 표현하고 있음을 알 수 있기 때문입니다. 그러나 기호는 여전히 문자열의 일부입니다.

표시 표기와 프레임 위치 환산은 두 개의 일임

진짜 드롭 프레임 계산은 프레임 번호와 시·분·초·프레임 사이를 오가며 건너뛰기 규칙을 실행해야 합니다. 마지막 : 하나를 단순히 ;로 바꾸는 것은, 겉모양만 바꾼 것이고 원래 그 숫자 열이 나타내는 프레임 위치를 바꾸지 않습니다.

SlateX의 전달 파일에서는 이 두 표기가 서로 다른 칸에 들어갑니다. 이미 기록된 인 포인트나 아웃 포인트 문자열은 두 갈래 중 하나를 따릅니다 — 녹음 체인이 중지를 부르는 그 순간에 화면에서 거둔 읽기 값은 유효한 드롭 프레임 주소로 다시 써서 넣습니다. 끝 구간 구분자만 세미콜론으로 바꾸면 SMPTE가 정의하지 않은 ;00, ;01 같은 값이 되기 때문입니다. 기기 화면이나 패널에서 스크립터가 옮겨 적은 읽기 값은 글자 그대로 둔 채, 끝 구간 구분자만 세미콜론으로 바꿉니다. 출처가 선언되지 않았으면 추측하지 않습니다 — 숫자는 그대로 두고, 빠진 선언은 마감 대조표가 TC_SOURCE_UNDECLARED로 지목합니다. Duration은 시작과 끝의 두 읽기 값 사이의 프레임 정확한 구간(끝 프레임은 포함하지 않음)이고, DF를 선언한 행에서는 그 칸이 세미콜론 형태로 적힙니다.

이것이 이 글의 하드 경계입니다. ;를 본다면, 전달 층이 이 문자열을 드롭 프레임 표기로 표시해 두었다는 것을 알 수 있습니다. 그러나 이 기호만으로는, 그 숫자 열이 이전에 드롭 프레임 규칙으로 얻어졌는지를 판단할 수 없습니다.

29.97에 가까운 값은 드롭 프레임을 선언하지 않는다

29.97에 가까운 프레임 속도라고 해서 그것만으로 전체 체인이 같은 카운팅 규칙을 쓴다는 증거가 되지는 않습니다. 경계에 있는 값은 특히 주의해야 합니다. 화면에 표시되는 것과 전달 파일에 적히는 것이 서로 다른 분류로 갈 수 있기 때문입니다. 확인할 수 있는 것은 파일의 그 칸에 결국 무엇이 적혔는지, 그리고 그 행의 실제 FPS, 타임코드 문자열, 소재가 서로 맞는지입니다.

수신자가 검증해야 하는 것은 실제 소재가 어떻게 타임코드에 맞는가이지, 구분자의 생김새만 검증하는 것이 아닙니다.

앱 실시간 표시와 전달 파일은 같은 표현이 아님

화면에 표시되는 실시간 타임코드는 전부 콜론으로 구분된 문자열이고 세미콜론이 없습니다. 따라서 앱에서 실시간으로 보이는 것과 나중에 전달 파일에 나타날 수 있는 것은 서로 다른 표현 규칙에서 나옵니다.

나중에 전달 파일에 세미콜론이 나타난다고 해서 현장의 실시간 표시가 이미 같은 카운팅 규칙을 따랐다고 역추론할 수는 없습니다.

받을 때는 이 두 층을 분리해야 합니다. 화면에서 읽은 문자열은 무엇인지, 전달 파일이 쓰는 문자열은 무엇인지, 기존 문자열에서 구분자만 바뀌었는지, 최종 소재 위치가 실제로 맞는지. 이 확인 중 하나라도 빠지면 세미콜론을 검수 결론으로 삼기에 부족합니다.

세미콜론이 달린 타임코드 한 줄을 실제로 대조하는 방법

먼저 그 행의 FPS가 소재와 현장 기록과 일치하는지 보고, 다음에 위치 특정 가능한 소재 하나를 골라 실제 인 포인트와 경과 시간과 대조합니다. 아웃 포인트는 옮겨 적어 넣은 읽기 값이므로, 그 칸에서 확인할 것은 “실제로 옮겨 적혔는지의 여부”입니다. 계산으로 나온 구간은 Duration이고, 이를 대조하려면 시작과 끝의 두 읽기 값과 그것들을 읽을 때 쓰인 카운팅 규칙으로 돌아가야 합니다.

인 포인트나 아웃 포인트가 기존 문자열이라면, 세미콜론이 달렸는지만 봐서는 안 됩니다. 수신자는 프레임 위치 자체가 소재에 맞는지 검증해야 합니다. 기호만 바꾼 문자열은, 모양새로는 올바른 드롭 프레임 타임코드와 아주 비슷할 수 있지만, 그 숫자는 여전히 다른 카운팅 방식에서 왔을 수 있습니다.

그러므로 세미콜론은 “여기서 드롭 프레임 기준을 점검해야 한다”는 힌트로 삼기에 맞고, “이 항목은 검증이 끝났다”는 표찰로 삼기에 맞지 않습니다.

FAQ

타임코드의 끝 구간이 세미콜론이면 드롭 프레임 규칙으로 계산되었음을 확정할 수 있습니까?

확정할 수 없습니다. 세미콜론은 표시 층의 표기일 수 있습니다. 현재 전달 경로는 기존 타임코드 문자열에 대해 끝 구간 구분자만 대체하고 프레임 위치를 다시 계산하지 않을 수 있습니다.

드롭 프레임은 실제 비디오 프레임을 지우는 것입니까?

여기서 논의하는 뜻이 아닙니다. 드롭 프레임 카운팅이 조절하는 것은 타임코드 번호 매기기 규칙이고, 분수 프레임 속도에서 연속 번호 매기기와 벽시계의 장기간 어긋남을 보상하는 데 쓰입니다.

왜 같은 프레임 속도 값이 다르게 떨어질 수 있습니까?

화면 표시와 전달 파일은 서로 다른 단계에 속하므로 경계에 있는 값은 다르게 떨어질 수 있습니다. 실제 파일과 소재를 대조하고, 그 칸에 결국 무엇이 적혔는지 확인하십시오.

앱 화면의 실시간 타임코드도 세미콜론을 씁니까?

현재 실시간 경로는 전부 콜론인 문자열을 출력하고 세미콜론 표기를 만들지 않습니다. 전달 파일의 세미콜론은 다른 단계의 표기에 속하므로, 실시간 경로가 같은 드롭 프레임 카운팅을 채택했다고 역추론할 수 없습니다.

Axiom One LLC — SlateX