하나의 프레임 속도 항목에 왜 카운팅 비율과 표시 기준값 두 개가 다 있는가

하나의 프레임 속도 항목이 여기에서는 두 개의 수를 동시에 갖고 있지만, 두 수가 담당하는 일은 다릅니다. 하나는 벽시계 시간을 프레임 수로 진행할 때 쓰는 카운팅 비율이고 소수를 허용하며, 다른 하나는 타임코드 문자열과 프레임 수를 서로 환산할 때 쓰는 정수 표시 기준값입니다.

29.97을 보면서 타임코드를 30을 기준으로 잘라 적는 것은 두 프레임 속도를 뒤섞는 일이 아니라, 카운팅 비율과 표시 기준값이 서로 다른 두 일을 하고 있기 때문입니다.

하나의 프레임 속도 설정이 두 벌의 수를 남겨 두는 이유

29.97 같은 설정을 예로 들면, 카운팅 비율은 「벽시계 시간이 이만큼 지나가는 동안 프레임을 몇 개 진행해야 하는가」에 답하고, 표시 기준값은 「이 프레임들을 시·분·초·프레임 문자열로 어떻게 나눌 것인가」에 답합니다. 앞쪽은 소수를 허용하는 진행 속도의 척도이고, 뒤쪽은 반드시 정수여야 하는 타임코드 프레임 자리의 분류 기준값입니다. 두 수를 하나 합치듯 취급하면 진행 속도와 문자열 번호 매기기 규칙을 같은 일로 잘못 여깁니다.

23.976도 같은 구조입니다. 진행에서는 소수를 담은 카운팅 비율을 쓰고, 문자열 환산에서는 정수 표시 기준값을 씁니다. 24, 25, 30 같은 정수 설정에는 이 층의 차이가 없습니다. 카운팅 비율과 표시 기준값이 같기 때문입니다. 여기서 다룰 초점은 어느 수가 더 「진짜」인가가 아니라, 두 벌의 수가 각각 서로 다른 계산에 쓰인다는 점입니다.

두 수가 어긋나면 시간 차이가 계속 쌓임

이 정수 아닌 설정들의 카운팅 비율은 표시 기준값보다 약 1000분의 1만큼 느립니다. 그래서 타임코드 번호 매기기 간격과 벽시계의 진행 속도가 같지 않습니다. 29.97에 30을, 23.976에 24를 짝 지우면, 문자열은 여전히 정수 표시 기준값으로 나누지만 실제 진행은 더 느린 카운팅 비율을 씁니다. 그래서 결과는 가끔 번호 하나가 빠지는 형태가 아니라, 같은 차이가 계속 쌓이는 형태입니다.

이 기준에서는 타임코드가 벽시계에 대해 갈수록 느려지고, 그 규모는 시간당 초 단위입니다. 이 속도로 환산하면 매시간 약 3.6초씩 느려집니다. 같은 속도를 24시간에 걸치면 86.4초이고, 그것이 바로 1분 반이라는 급입니다. 이 차이는 「보기에 가까우니」로 지울 수 없습니다. 두 벌의 수에서 역할을 나눈 데서 바로 그 차이가 나오기 때문입니다.

정수 아닌 설정의 핵심은 소수가 정수처럼 보인다는 것이 아닙니다. 카운팅 비율은 진행 속도를 결정하고, 표시 기준값은 번호 매기기 구조를 결정하며, 두 수의 차이는 시간이 지나면 쌓입니다.

카메라 기록의 프레임 속도는 기준 비율로 되돌려짐

어떤 카메라에 기록된 프레임 속도가 기준 위에 있는 오버크랭크 값이면, 환산 로직은 제수를 하나씩 시도하면서 결과를 사용할 수 있는 기준 비율들과 비교합니다. 아주 작은 허용 오차 안으로 들어오는 첫 후보를 기준 비율로 쓰고, 후보가 하나도 맞지 않으면 24로 돌아갑니다. 여기서 허용 오차를 작게 잡는 이유는, 가까운 오버크랭크 값은 대응하는 기준으로 내려올 수 있으면서 인접한 정상 설정까지 뒤섞지는 않게 하기 위한 것입니다.

예를 들어 24와 23.976의 차이는 0.024이므로, 24가 24로 남고 23.976으로 흡수되지 않으려면 허용 오차가 이 거리보다 작아야 합니다. 오버크랭크 소재를 기준 비율로 세는 것은 업계에서 흔한 처리이지만, 그것이 수신자가 반드시 따라야 하는 유일한 경로라는 뜻은 아닙니다. 수신자는 여전히 실제 결과물과 자신의 매체 기록을 놓고 프레임 속도 표기를 확인해야 합니다.

이 실시간 계수가 그래도 NDF인 이유

정수 아닌 설정의 실시간 경로에서는 프레임 번호가 계속 올라가고, 몇몇 번호를 건너뛰어 벽시계를 되따라오는 일을 하지 않습니다. 그래서 여기는 드롭 프레임을 하지 않는 계수, 즉 NDF입니다. NDF가 말하는 것은 실시간 경로가 번호를 매기는 방식이고, 끝까지 이어지는 전달 경로가 같은 표시 규칙을 가진다는 선언이 아닙니다. 「번호를 건너뛰지 않는다」를 「타임코드가 벽시계를 따라잡는다」로 읽으면 정반대가 됩니다. 앞에서 누적된 차이는 그대로 남아 있기 때문입니다.

내보내기 쪽에는 드롭 프레임 표시에 관한 별도의 판정이 있고, 그 세미콜론 표기는 현재 ALE과 CSV의 타임코드 열에만 나타납니다(데일리 리포트 PDF의 표 본문에는 타임코드 열이 없습니다). 그래서 실시간 경로와 내보내기 쪽 기준은 일치하지 않습니다. 이 사정을 근거로 앱이 현장부터 전달까지 관통하는 드롭 프레임 타임코드 능력을 갖췄다고 쓸 수도 없고, 타임코드를 벽시계와 동기화되었다고 쓸 수도 없습니다. 결과물 속 세미콜론의 의미는 『타임코드의 세미콜론은 실제로 무엇을 말하는가』를 따로 확인해야 하고, 실시간 NDF에서 내보내기 결과를 바로 역추론해서는 안 됩니다.

전달할 때 표기와 구분자까지 봐야 하는 이유

프레임 속도 표기는 이 행의 결과물이 어떤 속도를 선언했는지를 수신자에게 전하고, 타임코드 구분자는 내보내기 쪽이 어떤 표시 표기법을 채택했는지를 반영합니다. 이 두 정보 모두 원본 기록에 대한 확인을 대신할 수 없습니다. 실시간 경로와 내보내기 쪽 판정이 통일되지 않은 상황에서는 더욱 그렇습니다. 한 열의 값이 어디서 오는지 추적해야 한다면, 타임코드 모양이 익숙한지만 볼 것이 아니라 『ALE 각 열의 값은 어디서 오는가』와 함께 열별로 대조해야 합니다.

그러므로 수신자는 결과물 속 프레임 속도 표기와 타임코드 구분자를 직접 확인하고, 그것을 현장 기록 및 매체 쪽 정보와 함께 판단해야 합니다. 카운팅 비율은 진행을, 표시 기준값은 문자열 환산을 담당하고, 내보내기 쪽이 거기서 표시 형식을 별도로 정합니다. 이 세 층이 서로를 대신하도록 해서는 안 됩니다. 층만 분리해 두면, 29.97과 30이 동시에 나타나는 일은 더 이상 서로 모순되는 두 개의 답이 아닙니다.

FAQ

29.97인데 왜 30이라는 숫자도 있습니까?

29.97은 카운팅 비율이고 30은 표시 기준값이며, 각각 프레임을 진행하는 일과 타임코드 문자열을 나누는 일에 쓰입니다. 두 수가 동시에 나타나는 것은 계산 역할의 분담이지, 한 설정을 다른 설정으로 임시로 바꾼 것이 아닙니다.

23.976도 같은 두 수 구조를 씁니까?

그렇습니다. 23.976은 소수를 담은 카운팅 비율로 진행하고, 타임코드 문자열 환산에는 정수 표시 기준값을 씁니다. 카운팅 비율이 표시 기준값보다 약 1000분의 1만큼 느리므로, 타임코드는 벽시계에 대해 점점 느려집니다.

실시간 경로의 NDF는 내보내기도 NDF로 쓴다는 뜻입니까?

그렇게 추론할 수 없습니다. 실시간 경로는 프레임 번호를 건너뛰지 않는 NDF 계수이고, 내보내기 쪽에는 드롭 프레임 표시에 관한 별도의 판정이 있습니다. 그래서 끝까지 같은 기준이 아닙니다.

수신자는 마지막으로 무엇을 확인해야 합니까?

수신자는 결과물 속 프레임 속도 표기와 타임코드 구분자를 직접 확인하고, 그것을 현장 기록과 매체 정보와 대조해야 합니다. 특정한 숫자 하나나 구분자 하나만으로는 전체 경로를 이미 검증된 것처럼 다룰 수 없습니다.

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