같은 테이크 기록이 몇 장의 전달물에서 행 번호가 서로 맞지 않는 이유

같은 한 묶음의 테이크 기록이 몇 장의 전달물에서 행 번호가 서로 맞지 않는 것은, 서로 다른 프로젝트에서 데이터를 가져오서가 아닙니다. 각 결과물이 자기만의 정렬 규칙대로 출력하기 때문입니다. 표 형태 결과물은 생성 시간순을 보존하고, 구조화 목록은 씬·컷·테이크로 다시 정렬하며, 사람이 읽는 일일 리포트는 또 다른 컷 키를 씁니다. 세 개 모두 이제 카메라별로 전개되므로, 한 번의 내보내기에서 나오는 행 수는 같은 규격입니다. 맞지 않는 것은 행 순서뿐입니다.

파일 간 대조에서 일관된 공통 키는 씬·컷·테이크 신원이지 “몇 번째 행”이 아닙니다.

시작점은 같지만 뒤의 정렬 규격이 다릅니다

표 형태 결과물은 기록이 만들어진 순서를 기본적으로 따릅니다. 구조화 목록은 같은 기록을 씬 번호와 컷 번호, 테이크 번호로 다시 정렬하는데, 이때 씬과 컷은 자연순 비교를 씁니다. 테이크 기록은 같지만 행의 위치는 더 이상 공유되지 않습니다.

사람이 읽는 일일 리포트는 정렬을 한 겹 더 밉니다. 씬 다음에 컷의 한정자 이름을 두 번째 키로 쓰고, 그다음 테이크 번호로 배열합니다. 이 한정자 이름은 구조화 목록이 쓰는 원시 컷 번호와 같지 않아, 두 파일이 같은 한 묶음의 테이크를 담고 있어도 “두 번째 행은 두 번째 행과 맞아야 한다”는 관계가 성립하지 않습니다.

화면 로그에는 또 다른 순서가 있습니다. 이것은 컷 번호 문자열 오름차순으로 먼저 서고, 그다음 테이크 번호 오름차순으로 섭니다. 문자열 정렬에서는 10이 2 앞에 옵니다. 이것은 화면 층 자신의 표시 순서이므로, 내보내기 파일 속 위치를 거꾸로 끌어내는 데 쓸 수도 없습니다.

행 번호가 맞지 않는 핵심은 각자 다른 정렬 키를 쓴다는 데 있습니다

세 개 모두 카메라별로 전개됩니다. 한 테이크에 여러 카메라가 들어가면 각각 여러 행을 만들고, 카메라가 없어도 행 하나는 그대로 남습니다. 그래서 한 번의 내보내기에서 나온 세 파일의 행 수는 사실 같은 규격입니다. 차이는 그 똑같은 행들이 각자의 키로 서로 다른 순서에 놓였다는 점뿐입니다.

이것은 행 번호가 서로 맞지 않는 이유도 설명합니다. CSV는 기록을 만든 순서를 거의 그대로 따르고, ALE은 씬 번호·컷 번호·테이크 번호로 다시 정렬하며, 일일 리포트는 씬 번호·컷의 한정자 이름·테이크 번호로 배열합니다. 일일 리포트에서 순서번호처럼 보이는 No.도 문서 전체의 행 번호일 뿐이고, 테이크 번호가 아닙니다. 그러니 그것을 파일 간 대조 키로 쓸수록 아닙니다.

행 번호가 맞지 않는 것은 각자 서로 다른 정렬 키를 쓰기 때문이고, 어느 파일이 “촬영 하나를 더했다”거나 “하나 빼먹었다”는 말이 아닙니다.

컷 표식은 서로 다른 결과물에서 같은 문자열이 아닐 수도 있습니다

사람이 읽는 일일 리포트는 컷의 한정자 이름을 쓰지만, 표 형태 결과물의 컷 열은 원시 컷 번호를 씁니다. 한 컷은 화면이나 어느 파일에서 씬 접두어나 한정된 형태를 달고 나타나고, 다른 파일에서는 더 짧은 번호만 남을 수 있습니다. 수신자는 그것들을 씬·컷·테이크 관계에 되돌려 이해해야 하고, 어느 한 열의 문자열이 완전히 일치하는지만으로 같은 테이크인지 판단하지 않아야 합니다.

여기서 설명하는 것은 저희 결과물 쪽의 생성 방식입니다. 현재 증거로 특정한 하류 소프트웨어가 이것 때문에 어떻게 잘못 대응되거나 누락되거나 가져오기가 거절된다고 더 단정할 수 없습니다. 구체적인 수신 동작은 여전히 수신자가 자신의 가져오기 템플릿에 맞춰 열마다 확인해야 합니다.

대조할 때는 무엇을 써야 하는가

파일 간에 대조할 때는 먼저 씬 번호를 고정하고, 다음에 컷을 고정하고, 그다음 테이크 번호를 봅니다. 멀티 카메라 기록에서는 카메라까지 계속 봐야 합니다. 그렇게 하는 목적은 신원 관계를 공통 언어로 삼기 위한 것이고, 어느 파일에 우연히 나타난 행 위치를 기본키로 쓰기 위한 것이 아닙니다.

한 번의 내보내기에서 나온 세 파일은 이제 행 수 규격이 같습니다. 순서가 다르다면, 각각 어떤 정렬 키를 썼는지를 보면 됩니다. 범위를 넘는 비교는 성립하지 않습니다. 일일 리포트는 촬영일 범위로 내보낼 때만 생성되고, 프로젝트 전체 범위로 내보낼 때는 ALE과 CSV만 나갑니다. 신원 관계 자체가 맞지 않을 때만 원본 기록으로 돌아가 점검해야 하고, 먼저 몇 결과물의 행이 줄마다 맞출 것을 요구하면 안 됩니다.수신자 절차에 따라 이 전달물을 계속 쓸 수 있는지 판단해야 할 때는 “현장 결과물을 계속 쓸 수 있는지 수신자는 어떻게 판단하는가”의 대조 순서로 별도로 점검하십시오。

이런 차이는 생성 방식의 결과지만, “방식이 그렇다”는 것이 확인을 생략해도 된다는 말과도 같지 않습니다. 각 결과물은 서로 다른 책임을 지고, 수신자는 자기가 쓰는 필드가 정말로 같은 현장 기록 하나로 되돌아갈 수 있는지 확인해야 합니다.

FAQ

표 형태 결과물과 구조화 목록의 순서가 왜 다릅니까?

표 형태 결과물은 기록의 선후를 보존하고, 구조화 목록은 씬·컷·테이크로 다시 정렬하기 때문입니다. 둘은 같은 한 묶음의 테이크 기록에서 출발하지만 뒤따르는 정렬 규격이 다릅니다.

한 번의 내보내기에서 나온 몇 파일의 총 행 수가 같습니까?

같습니다. 세 개 모두 카메라 한 대씩 행을 내고, 멀티 카메라 테이크 하나는 세 결과물에서 모두 같은 수의 행을 차지합니다. 다른 것은 순서뿐입니다. 프로젝트 전체 내보내기에서는 일일 리포트가 생성되지 않으니, 그 범위를 넘어 행 수를 비교하는 것 자체가 성립하지 않습니다.

일일 리포트의 No.를 다른 파일의 행 번호와 대조할 수 있습니까?

대조하지 않아야 합니다. 일일 리포트의 No.는 문서 전체의 행 번호이고 테이크 번호와 같은 개념이 아니므로, 파일 간 신원 키로 쓸 수 없습니다.

몇 파일은 어떤 공통 키로 대조해야 합니까?

씬·컷·테이크 신원을 우선 쓰고, 멀티 카메라 기록에서는 카메라까지 계속 확인해야 합니다. 행 번호나 어느 파일의 정렬 위치를 공통 키로 취급하지 마십시오.

Axiom One LLC — SlateX