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

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

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

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

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

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

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

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

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

SlateX의 현재 전달 경로에는 이 두 동작이 모두 존재합니다. 끝 위치가 없어서 소프트웨어가 인 포인트와 길이로 아웃 포인트를 계산해야 하는 경우에는, 실제 드롭 프레임 산술을 탑니다. 이미 존재하는 인 포인트나 아웃 포인트 문자열은, 끝 구간 구분자만 세미콜론으로 바꾸고 프레임 위치 환산은 하지 않습니다.

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

「29.97에 가깝다」를 판정하는 두 곳의 허용 오차가 같지 않음

실시간 쪽이 카메라 명목률을 기준률로 내릴 때 쓰는 허용 오차는 0.013이고, 내보내기 쪽이 수치로 드롭 프레임 여부를 판정할 때 쓰는 허용 오차는 0.02입니다. 두 판정이 대상이 다르고, 허용 오차도 같은 수가 아닙니다. 이것은 경계에 있는 프레임 속도 값이 두 로직에서 서로 다른 분류를 받을 수 있음을 뜻합니다.

이런 차이는 수신자가관심하지 않아도 되는 구현 세부 사항으로 포장하면 안 됩니다. 타임코드가 어떤 표시 또는 계산 경로를 따르는지를 바꿀 수 있다면, 검수 때 파일 안의 실제 FPS, 타임코드 문자열과 소재를 한자리에 놓고 대조해야 합니다.

같은 이유로, 「수치가 흔한 프레임 속도 하나에 가깝다」를 곧바로 전체 경로가 이미 같은 카운팅 규칙을 채택했다는 말과 등치시킬 수 없습니다. 판단 입구가 다르면 결론도 다를 수 있습니다.

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

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

SlateX의 실시간 경로는 현재 전부 콜론인 타임코드를 출력하고, 세미콜론 표기를 만들지 않습니다. 다시 말해 앱 화면에서 현장에서 보는 실시간 문자열과, 전달 파일에 나타날 수 있는 세미콜론은 서로 다른 두 단계의 표현 규칙입니다.

실시간 경로는 분수 프레임 속도에서 분수 값으로 카운팅을 진행한 뒤, 정수 프레임 속도로 프레임 수를 문자열로 바꿉니다. 그것 자체에는 드롭 프레임 건너뛰기 표기가 없습니다. 따라서 전달 파일에 나중에 세미콜론이 나타났다고 해서, 현장에서 실시간 표시가 이미 같은 규칙으로 동작했다고 역추론할 수 없습니다.

받을 때는 이 두 층을 나눠야 합니다. 현장 기록의 원시 문자열이 어디서 왔는가, 전달 때 다시 계산되었는가, 구분자가 단순히 교체되었는가, 최종 소재와 점 대조가 성립하는가. 하나라도 빠지면, 세미콜론을 검수 결론으로 취급하면 안 됩니다.

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

먼저 그 행의 FPS가 소재와 현장 기록과 일치하는지 보고, 다음에 위치 특정 가능한 소재 하나를 골라 실제 인 포인트와 경과 시간과 대조합니다. 파일 안의 끝 위치가 소프트웨어 계산으로 나온 것이라면, 그 계산이 대응하는 카운팅 규칙을 탔는지도 따로 확인해야 합니다.

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

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

FAQ

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

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

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

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

왜 같은 프레임 속도 값이 두 로직에서 다르게 판정될 수 있습니까?

현재 「29.97에 가깝다」를 판정하는 두 곳의 허용 오차가 각각 0.013과 0.02이기 때문입니다. 경계에 있는 수치는 서로 다른 분기로 들어갈 수 있으므로, 수신자는 실제 파일과 소재를 대조해야 합니다.

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

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

Axiom One LLC — SlateX. 위 숫자는 2026-09-24 기준입니다.