수신과 검수 / R2 · 전달

ALE를 받으면 이 필드들부터 확인하라

ALE 하나를 받았으면, 먼저 각 행이 누구인지 확인합니다: 어느 소재를 가리키는지, 어느 카드인지. 그다음 각 시간 값이 어디서 왔는지를 확인합니다. 현장에서 기록한 값인지, 애초에 그 행에 없었던 것인지. SlateX가 내놓는 이 파일은 카메라별로 한 행씩 생성됩니다: 카메라가 네 대면 행도 네 개이고, 카메라 정보를 하나도 기록하지 않아도 행은 하나 나옵니다. 빠진 값은 빈칸으로 둡니다. 파일 머리의 선언문 한 줄에는 이 약속들을 누가 정했는지가 글자 그대로 적혀 있으니, 그것을 경계로 읽고 합격 증명으로는 읽지 마십시오.

파일이 열린다는 것은 구문이 읽힌다는 것만 증명합니다. 형식이 합법이라는 것은 사실이 정확하다는 것과 같지 않습니다.

열 이름과 순서: 28개 열, 파일에 실제로 나타난 문자열로 확인한다

열 위치는 저희와 수신 측 사이의 계약입니다. 어떤 열이든 하나를 바꾸면 데이터 행도 함께 바꿔야 하며, 양쪽이 맞지 않으면 파일 전체가 어긋납니다. 현재 내놓는 28개 열의 순서는 다음과 같습니다: Name, Tracks, Start, End, Duration, Scene, Take, Reel #, Soundroll, FPS, SlateX Description, SlateX Comments, Tape, Camera, Camera Notes, VFX_Count, VFX_Type, Shoot Day, Director, Sound TC, Source File Name, Source File, Camroll, Shoot date, Unit, Rating, Circled take, TC Mode. 수신자는 이 글자 그대로를 기준으로 확인해야 하며, 하류 단계에서 비슷한 뜻의 열 이름을 같은 필드로 자동 대응시켜 줄 것이라고 먼저 가정해서는 안 됩니다. SlateX Description과 SlateX Comments에 제품명 접두사가 붙어 있는 것은 그 두 칸에 저희가 직접 쓴 내용이 들어가서, 남의 표준 열 의미를 사칭해서는 안 되기 때문입니다.

한 행이 누구인가: 카드 번호, 원문 그대로, 소프트웨어가 세어 준 번호는 세 가지 별개다

Tape이 실어 오는 것은 현장에서 옮겨 적은 카드 번호를 정규화한 형태입니다: 영문자와 숫자만 남기고, 대문자로 통일하고, 31자로 잘라냅니다. 정규화에는 이유가 있습니다. 같은 카드에서 대소문자가 갈라지면 하류에서는 세 장이 되어, 묶음 추출과 재추출, 편집 표가 줄줄이 맞지 않게 됩니다. Camroll은 원문 그대로를 실으려고 하지만, ALE의 이 칸은 ASCII만 받아들입니다 — 카드 이름에 비라틴 문자가 들어가면 이 칸은 비게 되고, 글자 그대로의 원문은 CSV 쪽에 남습니다. Reel #의 계약 문구는 이 열에 숫자를 넣는다는 것이므로, 카드 번호에 문자가 하나라도 들어 있으면 칸 전체를 비웁니다. 접두어를 벗겨 숫자처럼 보이는 번호를 만들어 내는 일은 하지 않습니다.

겉모양도 번호와 비슷한 것이 하나 더 있습니다. 소프트웨어가 스스로 세는 표시 번호로, 카메라 문자에 세 자리 증가 번호를 붙인 것입니다. 이것은 옮겨 적은 카드 번호와 CSV에서 Reel과 Camera Card 두 열로 나란히 놓이며, 따로 쓰는 것은 어느 쪽이 옮겨 적은 것이고 어느 쪽이 소프트웨어가 배치한 번호인지 독자가 알아볼 수 있게 하려는 것입니다. 파생 번호는 물리적 카드 어느 것과도 대응하지 않으므로, 원본 소재를 되찾는 데 쓸 수 없습니다.

Name은 같은 두 자에 매입니다. 31자와 ASCII입니다. 쇼트 이름을 기록하지 않았을 때는, 그 행이 스스로 가진 신 번호·쇼트 번호·테이크 번호로 확정적인 이름 하나를 조립하는 쪽으로 물러납니다. 같은 테이크라면 내놓을 때마다 같고, 다른 테이크와 겹치지 않습니다. 그것은 생성된 식별자이지, 현장에서 종이에 적던 그 이름이 아닙니다.

시간 위치: 진입 지점은 출처가 있지만, 퇴장 지점은 현재 값을 내지 않는다

Start는 그 테이크에 기록된 타임코드를 씁니다: 진입 지점이 있으면 진입 지점을 쓰고, 없으면 테이크 자체의 값을 씁니다. End 이 열은 현재 비어 있습니다 — 데이터베이스 쪽에 퇴장 지점의 입력 경로가 없고, 진입 지점에 길이를 더해 끌어내는 일도 하지 않습니다. 그것은 벽시계로 계산한 번호를 카메라 화면의 원본 읽은 값인 것처럼 내거는 짓입니다. CSV의 퇴장 지점 칸도 같은 이유로 빈칸입니다. 퇴장 지점이 필요하면 카메라 보고서로 돌아가거나 카메라 화면에서 옮겨 적습니다. 이 칸은 마감 대조표에서 TC_OUT_MISSING으로 드러납니다.

Duration은 테이크에 기록된 길이를 타임코드로 적어 만듭니다. FPS는 그 행 자체가 프레임 속도 선언을 담고 있을 때에만 값이 있고, 선언이 없으면 숫자도 없습니다. 내부 연산에는 별도로 예비 계산 기준이 있지만, 그 숫자는 이 열에 적지 않습니다. 그 카메라가 보고한 프레임 속도가 아니기 때문입니다.

세미콜론은 선언을 따를 때에만 붙습니다. TC Mode 이 열에는 DF 하나만 나타날 수 있으며, 빈칸은 드롭 프레임 선언이 없다는 뜻이지 비드롭 프레임을 뜻하지는 않습니다. DF를 선언한 행만 Start, End, Duration을 세미콜론 형태로 적습니다. 이것은 SlateX 자신의 표시 약속으로, 파일 머리에 글자 그대로 적혀 있으며, 어떤 표준의 요구도 아니므로, 세미콜론을 「이 행은 드롭 프레임」이라는 공통 암호로 다루지 마십시오. 사운드 타임코드는 글자 그대로 넘기고, 모양만 판단할 뿐 프레임 자리를 잘라내지 않습니다.

빠진 값은 이제 한 가지 모양뿐: 빈칸

타임코드를 기록하지 않았거나, 문자열 모양과 범위 검사를 통과하지 못한 칸은 모두 빈 문자열로 나옵니다. 이 파일에서는 00:00:00:00을 다시 볼 수 없습니다. 저 영들의 문제는 틀린 것이 아니라 합법적으로 보였던 것입니다: 수신자가 현장에서 진짜 영점과 채워 넣은 영점을 구별할 수 없게 만들기 때문에, 그 길 자체를 통째로 없앴습니다. 빠진 값은 곧 빈칸이고, 빈칸에서는 두 가지를 나눠야 합니다 — 기록하지 않은 것인지, 기록한 것이 ASCII가 아닌 것인지. 자유 텍스트 저 몇 개 열은 바로 후자가 떨어지는 자리입니다.

Source File Name과 Source File 두 열은 열 목록에 들어 있고, 값은 현장에서 옮겨 적었는지에 달려 있으며, 적지 않았다면 비어 두고, 저희는 경로를 추측하지 않습니다. VFX_Count도 마찬가지로 열은 있지만 현재 입력 경로가 없어 빈칸으로 나옵니다. Soundroll은 녹음 보고서 대장에 있는 릴 번호를 실어 오고, 같은 방식으로 정규화하며, 없으면 비워 두고 소프트웨어가 세어 준 번호로 대신하지 않습니다. ALE 전체는 ASCII만 받아들입니다: 이름, 경로, 카드 번호, 조(班), 그리고 설명·테이크 비고·카메라 비고·감독의 저 몇 개 자유 텍스트 열까지, 예외 없이 같은 자 위에 있습니다 — 기록하기 전의 줄바꿈과 탭 문자를 먼저 공백으로 줄이고, 값 안에 비라틴 문자가 하나라도 끼어 있으면 칸 전체를 빈칸으로 내놓습니다. 그래서 중국어 비고 한 줄은 이 파일에서는 빈칸 하나가 되고, 글자 그대로의 원문은 CSV 쪽에 남습니다.

이 행이 어떤 상태였는지는, 파일에 적혀 있다

Rating은 현장 등급 텍스트를 실어 옵니다 — Circle, Keep, Hold, N/G 계열로, 어느 테이크도 등급을 받지 않았을 때 이 칸은 비고, Circled take은 TRUE 또는 FALSE를 실어 옵니다. 수신자는 그래서 ALE 자체에서 어느 테이크가 몇 등급으로 표시되었고 서클로 선택되었는지 읽어 낼 수 있으며, 스크립터에게 돌아가 물을 필요가 없습니다.

Tracks는 세 상태이지, 「MOS가 아니면 동기 사운드」가 아닙니다: V는 MOS 테이크, A1A2는 와일드 트랙, VA1A2는 동기 사운드이고, 한 행에 소리 사실이 전혀 없으면 이 칸을 비워 두며, 동기 사운드로 기본 잡지 않습니다.

마감 대조표는 무엇이고, 무엇 아닌 것인가

하루치 내보내기에는 Reconcile_*.csv 한 장을 함께 보낼 수 있습니다. 이 표는 저희 쪽 한 장만 판단합니다: 무엇이 빠져 있는지, 무엇이 스스로와 부딪히는지를. 열한 개 코드가 하나씩의 일을 말합니다 — CARD_MISSING, SOURCE_MISSING, SOURCE_DUP, SOUND_ROLL_MISSING, SOUND_TC_MISSING, MOS_VS_SOUND, TC_MODE_UNDECLARED, DURATION_MISMATCH, TC_IN_MISSING, TC_OUT_MISSING, DAY_MISSING. 그중 SOURCE_DUP, MOS_VS_SOUND, DURATION_MISMATCH는 행 전체를 「충돌」로 끌어올리고, 나머지는 「결손」에 떨어지며, 둘 다 없어야만 「일치」를 적습니다. 표는 표시만 할 뿐, 어떤 행의 값도 건드리지 않고, 누구의 숫자로 누구를 덮어쓰지도 않습니다.

표에 적힌 「일치」 한 문장은 읽는 방법이 하나뿐입니다: 저희 기준으로 문제를 찾지 못했다는 것. 두 부서가 일치를 확인했다는 말이 아닙니다.

그 경계는 못 박아야 합니다. 이 표는 카메라 보고서도 읽지 않고, 녹음 보고서도 읽지 않습니다. 표 머리에 「카메라 보고서 카드 번호」와 「녹음 보고서 사운드 릴」 두 열이 있지만, 저 두 칸의 값은 귀하가 저희 소프트웨어에 옮겨 적은 기록에서 온 것이지, 두 부서의 원시 보고서가 아닙니다. DAY_MISSING은 이 기록이 현시점 어느 촬영 일에도 속하지 않는다는 말입니다: 테이크를 잃은 것이 아니고 전체 묶음에 그대로 들어가지만, 일 번호·날짜·조·감독의 네 칸에 값이 없을 뿐이며, 이 코드로 그것을 드러냅니다. 대가는 그날의 마감 서류를 채울 수 없다는 것이지, 데이터가 사라진 것이 아닙니다. 빠진 것을 지목하지 못하는 경우가 하나 있습니다: 문자가 ASCII가 아니라서 비워진 칸 — 데이터베이스에는 값이 기록되어 있으므로 어떤 코드도 켜지지 않고, 저 몇 개 열은 귀하가 직접 옮겨 적은 내용과 대조할 수밖에 없습니다.

저희는 어떤 편집 시스템과도 가져오기 검수를 하지 않았습니다

위는 실행 예시 하나이지 산업 표준이 아니고, 어떤 수신 시스템이 각 열을 어떻게 해석할지도 증명하지 않습니다. 그 목적은 하나뿐입니다: 확인할 수 있는 자리를 꺼내 놓아, 수신자가 어디서 출처로 돌아가야 하는지 알 수 있게 하는 것. 내놓기 전에, 저희가 기록한 것을 항목별로 훑습니다 — 확인할 권한은 독자 손에 있으며, 저희는 독자가 저희를 믿기를 요구하지 않습니다.

확인을 통과하지 못할 때, 세 가지 처리를 섞지 않는다

반려합니다. 신원이나 시간 필드가 소재나 현장 기록과 부딪히고, 원본 기록이 추적 가능한 경우, 생성 쪽에 되돌려 원문을 고쳐 다시 내놓게 합니다 — 수신 측에 손으로 고친 흔적은 있는데 출처 설명은 없는 버전이 남는 일을 그렇게 막습니다.

손으로 채웁니다. 부족함이 작고 출처가 분명하며, 모든 수정을 구체적인 소재나 기록으로 되돌려 지시할 수 있을 때에만 채워 넣고, 그 근거도 곁에 남겨 둡니다. 추측으로 빈칸을 채우지 말고, 비어 있는 End에 숫자를 만들어 내지도 마십시오.

참고로만 둡니다. 출처를 확인할 수 없거나, 하류가 이 파일을 어떻게 다루는지를 귀하가 아직 검증하지 않았다면, 이 파일을 참고 용도로만 한정하고 정확한 대조가 요구되는 결정을 담당하게 하지 않습니다.

FAQ

00:00:00:00을 진짜 영점으로 볼 수 있습니까?

다시는 저 영들을 보지 못합니다. 빠진 값은 모두 빈 문자열로 나옵니다: 칸이 비어 있으면 먼저 기록하지 않았다는 것으로 읽고 — 자유 텍스트 저 몇 개 열만 예외로, 값은 기록되어 있으나 ASCII가 아니어서 밖으로 내보내지 못한 것이며, 원문은 CSV에 있습니다.

같은 테이크가 왜 여러 행이 됩니까?

ALE은 카메라별로 한 행씩 생성합니다. 같은 Scene과 Take에 카메라가 네 대 걸려 있으면 행도 네 개이므로, Camera로 나눠서 확인하고 전체 행 수를 테이크 수로 잡지 마십시오. 카메라 정보를 하나도 기록하지 않았을 때도 행은 하나 나옵니다.

End를 편집 대조에 쓸 수 있습니까?

쓸 수 없습니다. 이 열은 현재 값을 내지 않습니다: 데이터베이스 쪽에 퇴장 지점의 입력 경로가 없고, 진입 지점에 길이를 더해 끌어내지도 않습니다. 퇴장 지점이 필요하면 카메라 보고서로 돌아가거나 카메라 화면에서 옮겨 적고, 대조표는 TC_OUT_MISSING으로 그것을 표시합니다.

세미콜론 타임코드는 드롭 프레임의 공통 기호입니까?

아닙니다. TC Mode에 DF가 적힌 행만 세미콜론 형태를 쓰고, 그것은 SlateX 자신의 표시 약속입니다. 빈칸은 드롭 프레임 선언이 없다는 뜻이지, 비드롭 프레임이라는 뜻이 아닙니다.

표에 「일치」라고 적혀 있으면, 양쪽 부서가 맞춘 것입니까?

아닙니다. 이 표는 저희 쪽 한 장만 읽고, 「일치」는 저희 기준으로 문제를 찾지 못했다는 말입니다. 카메라 보고서와 녹음 보고서는 그 읽기 범위에 들지 않습니다.

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