전달 파일의 빈 값은 네 가지 형태를 취함
전달 파일 속 「빔」은 그냥 칸 하나에 아무것도 없는 것만 가리키지 않습니다. 받을 때는 적어도 네 가지 형태를 나눠 봐야 합니다. 정말로 빈 문자열, 분명히 자리채움으로 찍은 짧은 가로, 정상 번호처럼 보이는 기본값, 합법적인 타임코드처럼 보이는 영값이 그것입니다. 넷 다 「여기에는 확인할 데이터가 없다」를 뜻할 수 있지만, 모양과 생겨난 사정은 서로 다르므로 검수 때 한 부류로 섞어서는 안 됩니다.
데이터가 없다고 반드시 공백처럼 보이는 것은 아닙니다. 어떤 결손치는 하필 정상 값과 아주 흡사하게 나타납니다.
빈 문자열은 눈에 보이는 부족함
표 형태의 전달물에서는 빠지는 필드가 많으면 그대로 빈 문자열로 적힙니다. 카메라가 없으면 해당 카메라 열은 비어 둘 수 있고, 진입 지점·촬영일이나 그 밖의 선택 정보가 없어도 빈 칸이 보일 수 있습니다.
빈 문자열의 장점은 수신자가 「여기 내용이 없다」를 알아보기 쉽다는 점입니다. 그래도 그것이 말해주는 것은 이 결과물에 값을 쓰지 않았다는 것뿐이고, 원본 기록에 애초에 그 데이터가 없었는지 아니면 생성 때 그 데이터를 가져오지 못했는지까지는 홀로 답하지 못합니다. 검수는 여전히 기록의 출처로 돌아가야 합니다.
서로 다른 전달 형식의 결손치 처리도 같지 않습니다. 어떤 표에서 빈 문자열이 자주 나온다고, 다른 목록이 같은 방식으로 부재를 표현하리라고 끌어낼 수는 없습니다.
짧은 가로는 분명한 자리채움이지 업무 값이 아닙니다
어떤 필드는 내용이 없을 때 -를 씁니다. 우리 자신의 일일 보고서 PDF가 바로 이 부류입니다. 감독·조·소집·마무리 칸은 적어 두지 않으면 짧은 가로가 찍혀 나옵니다. 여기의 짧은 가로는 진짜 이름이나 번호, 상태가 아니라 수신자에게 「현재 값이 없다」를 알려 주는 표시입니다. 반대로도 성립합니다. 기계가 읽는 두 파일에서는 이 부류를 읽을 수 없습니다. ALE과 CSV의 결손치는 빈 문자열이라, 「짧은 가로가 보여야 비로소 빠진 것」이라는 기준으로 검사하면 그것들의 빈 칸이 통째로 새어 나갑니다.
문제는 짧은 가로가 모든 열에 공통된 결손치 표기가 아니라는 점입니다. 같은 파일 안에서도 다른 필드는 빈 문자열이 되거나 기본 번호와 영 타임코드를 얻을 수 있습니다. 그래서 「결손치를 보면 -부터 찾는다」는 일반 규칙을 세울 수 없습니다.
수신자는 열별로 자리채움의 뜻을 이해해야 합니다. 한 열의 -는 분명히 자리채움이지만, 다른 열은 그 표기를 애초에 쓰지 않을 수 있습니다.
기본 번호는 특히 실제 기록처럼 보입니다
카메라 문맥이 부족하면 사람이 읽는 두 산출물에서 릴 번호와 사운드 릴 번호가 A001, S001 같은 모양으로 나타날 수 있습니다. 카메라 글자에 세 자리를 더해 소프트웨어가 센 번호입니다. 모양새는 화면에서 실제 카드 번호와 구별되지 않아서, 문자열이 형식에 맞는지만으로는 그것이 현장에서 확인한 값인지 알 수 없습니다.
같은 사실이라도 기계가 읽는 파일에서는 다른 길을 갑니다. ALE이 원본을 식별하는 데 쓰는 네 칸—— Tape, Reel #, Soundroll, Camroll ——은 당신이 옮겨 적은 카드 번호만 받고, 옮겨 적지 않으면 빈 상태로 두며, 파생 번호를 대신 넣지 않습니다. CSV는 두 칸을 나란히 넘깁니다. 한 칸은 소프트웨어가 센 표시 번호이고, 다른 한 칸은 당신이 옮겨 적은 실제 카드 번호이며, 갈라서 놓은 것은 사람으로 하여금 대조하게 하려는 것입니다.
이런 값은 파일 안에서 스스로 증명하지 못합니다. 수신자는 릴 번호, 클립 번호, 소재 파일 이름을 현장 기록이나 미디어 자체에 대조해서, 그것이 실제 기록인지 생성기의 마지노선 값인지 확인해야 합니다.
「형식이 진짜처럼 보인다」는 문자열이 규격에 맞다는 말만 하고, 출처가 확인을 마쳤다는 말은 하지 않습니다.
전부 영인 타임코드는 진짜 영일 수도 있고 빠진 값일 수도 있습니다
00:00:00:00은 출처로 돌아가야 할 필요가 더 큰 형태입니다. 그것 자체는 읽을 수 있는 타임코드 문자열이라서, 구문 검사는 그것을 빈 값으로 다루지 않습니다. 그런데 생성기는 쓸 만한 타임코드나 길이가 없을 때 역시 이 값을 씁니다. 바로 그것이 위험한 대목입니다. 우리 자신의 세 전달 파일은 이미 이것을 쓰지 않습니다. 타임코드를 적지 않았거나 모양과 범위가 통과하지 않으면 모두 빈 것으로 넘깁니다. 빠진 것은 빠진 그대로 두어, 그럴듯한 영으로 채워 넣지 않습니다.
그러므로 결과물만으로는 수신자가 「현장에서 정말 영점에서 시작했습니다」와 「쓸 만한 값이 없어서 영으로 채워졌습니다」를 나눌 수 없습니다. 두 경우를 가르려면 현장 기록, 소재 메타데이터 또는 그 밖의 추적 가능한 출처를 봐야 합니다.
이 경계는 결손치에서 이어 계산된 필드에도 적용됩니다. 파생 결과가 완비된 것처럼 보인다고, 그 입력이 반드시 실재했다는 말은 되지 않습니다.
네 형태는 형식을 넘어 그대로 쓸 수 없습니다
SlateX 쪽의 규칙은 이제 짧게 말할 수 있습니다. 기계가 읽는 두 파일(ALE과 CSV)에서 결손치는 겉모양이 하나뿐입니다. 빈 문자열입니다. 짧은 가로도 안 쓰고, 전부 영인 타임코드도 안 쓰며, 프레임 속도 칸은 카메라가 선언하지 않았으면 그대로 비고, 한 쪽은 25, 다른 쪽은 24가 되는 갈라짐은 존재하지 않습니다. 짧은 가로 항목은 사람이 읽는 일일 보고서 PDF에만 나타나고, A001 계열의 파생 번호는 CSV와 PDF의 사람이 읽는 열에만 나타나며, ALE이 원본을 식별하는 칸은 그것을 대신 넣지 않습니다. 알아 둘 칸이 하나 더 있습니다. ALE에서는 값이 분명히 적혀 있는데도 그 칸만 비어 있는 경우가 있습니다. 그 열은 그런 문자를 실을 수 없기 때문에, 비라틴 문자는 칸째 빈 것으로 넘기고, 글자 그대로의 원문은 CSV와 PDF에 남습니다.
그래서 「결손치는 어딘가의 기호로 통일해 채운다」로는 쓸 수 없습니다. 수신 규칙은 구체적인 형식과 구체적인 열을 두고 세워야 합니다. 어느 열은 비어 둘 수 있고, 어느 열은 자리채움을 쓰며, 어느 열은 합법적인 모양의 기본값을 만들어 내고, 어느 시간 필드는 영값으로 떨어지는지를 가려 정합니다.
현재의 전달 파일은 「이 값은 생성기가 만들었다」를 따로 표시하지도 않습니다. 기본 번호와 영값이 실제 값과 똑같이 생겼을 때, 대조할 책임은 여전히 수신자 쪽에 남아 있습니다. 가장 안전한 방법은 추측이 아니라 원본 기록을 찾는 것입니다.
FAQ
빈 칸과 -를 같은 결손치로 취급해도 됩니까?
그렇게 하지 않아야 합니다. 둘 다 부재를 뜻할 수는 있지만 서로 다른 출력 형태이고, 모든 열이 같은 규칙을 쓰지는 않습니다. 받을 때는 구체적인 필드를 두고 해석해야 합니다.
파일에 A001이 나오면 그것이 현장 릴 번호입니까?
그렇게 판단할 수 없습니다. CSV와 PDF의 그 열은 본래 소프트웨어가 카메라 글자에 번호를 이어 붙여 센 표시 번호로, 릴 번호처럼 적혀 있습니다. 현장에서 실제로 옮겨 적은 카드 번호는 다른 칸에 있습니다. ALE이 원본을 식별하는 칸은 파생 번호를 받지 않고, 옮겨 적지 못하면 비워 둡니다. 대조할 때는 이 두 칸을 갈라서 보십시오.
00:00:00:00을 그대로 진짜 영점으로 봐도 됩니까?
문자열 하나만으로는 결론지을 수 없습니다. 어느 전달 파일에 넣어도 마찬가지여서, 그것은 합법적인 영점일 수도 있고, 빠진 끝에 채워진 형태일 수도 있으므로 출처로 돌아가 확인해야 합니다. 우리 자신의 세 전달 파일은 이미 이 문자열을 쓰지 않고, 결손치는 모두 빈 상태로 둡니다.
결손치 규칙 하나로 모든 전달 형식을 검사할 수 없는 이유는 무엇입니까?
같은 데이터 묶음도 실리는 매체에 따라 표기가 다르기 때문입니다. 사람이 읽는 것은 자리채움을 쓰고, 기계가 읽는 두 개는 모두 빈 상태로 남기며, A001 같은 파생 번호도 사람이 읽는 열에만 나타납니다. 수신 규칙은 매체별, 열별로 하나씩 세워야 합니다.
Axiom One LLC — SlateX. 위 숫자는 2026-09-24 기준입니다.