결과물이 왜 소재를 다시 잇는 경로를 넘기지 못하는가

ALE, CSV, PDF, FDX는 모두 구조화된 기록을 넘길 수 있지만, 어느 것에서도 수신자 기계의 소재를 다시 잇는 경로는 나오지 않습니다. 기계로 읽는 두 결과물에는 “파일 이름” 칸과 “경로” 칸이 실제로 있지만, 열 이름은 서로 통하지 않습니다. CSV는 Source File Name과 Source File Path, ALE은 Source File Name과 Source File입니다. CSV는 기록에 들어 있는 그 경로를 있는 그대로 써 내지만, ALE의 그 두 칸은 문자열 전체가 ASCII일 때만 실려서 비라틴 문자가 끼면 칸 전체가 빈칸으로 나갑니다. 칸에 들어가는 것은 현장에서 옮겨 적어 넣은 문자이거나 소재를 파일에서 가져올 때 그 기계에 기록된 주소이고, 둘 다 일어나지 않았으면 칸은 빈칸으로 나갑니다. PDF와 FDX에는 그 두 칸이 없습니다.

소재는 프로젝트 저장소에 디스크 위의 저장 위치를 실제로 갖습니다. 다만 결과물 속 그 칸에 글자가 가득 채워져 있어도 그것이 가리키는 것은 보내는 쪽 기계 위의 위치라서, 수신자가 그것으로 자기 디스크 위의 소재에 바로 재연결할 수 없습니다.

결과물 속 그 주소는 보내는 쪽의 것이고, 소재가 이 기기에 있는가와 별개의 일입니다

소재가 이 기기에서 어떻게 저장되는가는 앱 자신의 문제이고, 여기서 말할 것은 결과물 속 그 칸의 경로가 보내는 쪽의 디스크에 속하고 수신자가 해석할 수 있는 포인터가 아니라는 점입니다. ALE, CSV, PDF 또는 FDX를 만들 때 파일이 담는 것은 촬영 기록과 관련 필드이지 수신자 매체의 저장 위치 목록이 아닙니다. 그래서 수신자가 릴 번호, 씬 번호 또는 테이크 번호를 볼 수 있어도, 결과물 파일에서 자기 로컬 파일의 물리적 위치를 직접 얻을 수는 없습니다. 컷 번호는 CSV와 PDF에서만 별도 열을 이루고, ALE에는 이 열이 없습니다.

파일 이름이 원래 경로의 대리물이 될 수 없는 이유

디스크 위의 파일 이름 자체는 이미 외부에서 가져온 이름과 다를 수 있으므로, 그것으로 이 소재가 어디서 왔는지 거슬러 알 수 없습니다.

사진은 두 곳에서 옵니다. 현장에서 찍거나 퀵 컷으로 얻은 사진, 그리고 사진 라이브러리에서 고르거나 파일에서 가져온 사진입니다. 어느 쪽도 원래 경로를 가져오지 않습니다. 따라서 수신자가 우연히 비슷한 파일 이름을 손에 넣어도 그것을 “원본 파일 이름 더하기 원본 바이트”의 증거로 취급할 수 없습니다. 결과물 속 그 칸의 파일 이름은 릴 번호와 클립 번호로 조립된 것이고, 디스크 위의 그 이름이 아닙니다. 매체 쪽의 정리는 이 기기에 남고, 결과물 속 그 칸의 경로가 가리키는 것은 이 기기 자신의 디렉터리일 뿐 수신자 쪽 그 소재의 위치가 아닙니다.

“그 칸의 경로는 수신자의 소재로 다시 이어지지 않는다”는 전달의 경계를 설명하는 것이고, 소재가 로컬 프로젝트 저장소에 존재하는지에 대한 판단이 아닙니다.

이것이 소재 재연결을 직접 제한하는 이유

결과물 속 그 칸의 경로는 보내는 쪽의 디렉터리에 적혀 있으므로, 수신자는 여전히 기록 한 행에서 자기 로컬 파일 위치로 곧바로 건너뛰게 하는 물리적 포인터가 없습니다. 릴 번호, 씬 번호, 테이크 번호 같은 필드는 여전히 신원 관계를 세우는 데 쓸 수 있지만, 그것들은 식별자이지 경로가 아닙니다. 수신자는 이 식별자들을 자신이 받은 매체 목록, 파일 명명, 디렉터리의 실제 상태와 대응시켜야 합니다.

이것이 바로 “ALE를 받으면 이 필드들부터 확인하라”가 수신자에게 소재와 현장 기록으로 돌아가 확인할 것을 요구하는 이유입니다. 파일을 열 수 있고 몇몇 열을 읽을 수 있다는 것이, 그 파일이 동시에 매체 위치까지 실었다는 뜻은 아닙니다. 어떤 작업 흐름이 결과물에서 소재를 바로 찾아내야 한다면, 그 대응 관계는 수신자가 이미 갖고 있는 매체 정보로 채워야 합니다.

네 가지 결과물이 같은 경계에 서 있는 이유

ALE과 CSV는 기계 판독 표이고, PDF는 사람이 읽는 요약이며, FDX는 대본 교환을 담당합니다. ALE과 CSV는 같은 촬영 기록을 쓰고 “파일 이름” 칸과 “경로” 칸이 있지만, 열 이름은 서로 통하지 않습니다: CSV는 Source File Name과 Source File Path, ALE은 Source File Name과 Source File입니다. CSV는 기록에 저장된 값을 있는 그대로 써 내고, ALE의 그 두 칸은 ASCII만 받아들이며, 값은 현장에서 옮겨 적은 것이거나 소재를 파일에서 가져올 때 기록된 주소에서 들어오고, 둘 다 없으면 칸은 빈칸입니다. PDF는 사람이 읽는 데만 쓰이고, FDX는 대본 쪽 내용을 써서 테이크 기록조차 싣지 않습니다. 네 결과물 어디에도 수신자가 자기 매체로 직접 해석할 수 있는 주소는 없습니다. 형식이 다르다고 이 경계가 바뀌지 않습니다. 어떤 형식의 열이 더 많다는 이유만으로 그 칸의 주소가 수신자가 열 수 있는 저장 위치가 된다고 추론할 수 없습니다.“내보낸 뒤에 결과물 파일은 어디에 있으며 얼마나 남아 있는가”를 참조하십시오。

예를 들어 “CSV 전달물은 ALE보다 무엇을 더 싣고 무엇을 빼는가”가 다루는 것은 필드 집합의 차이이고, 경로가 없다가 생긴 일이 아닙니다. “ALE를 받으면 이 필드들부터 확인하라”는 어느 칸을 옮겨 적지 않아 빈칸으로 나가는지, 그 옮겨 적히지 않은 칸이 마감 대조표에 어떻게 드러나는지를 칸별로 다룹니다. “ 전달 파일의 결손치를 모양으로 구분해 읽는 법 ”은 그 빈칸 아래를 한 층 더 나눕니다. 빈 문자열, 하이픈 자리 표시, 생성된 기본 번호, 모두 0인 타임코드는 각각 비어 나온 이유가 다릅니다. 받을 때는 “이 칸은 옮겨 적지 않았다”, “이 칸은 옮겨 적은 문자를 담고 있다”, “매체를 실제로 다시 연결할 수 있는 포인터”를 나눠서 이해해야 합니다. 열에 이름이 적혀 있는 것은 위치가 적혀 있는 것이 아닙니다.

수신자가 소재 대응 관계를 세우는 방법

결과물 기록을 매체와 대응시켜야 할 때, 수신자는 릴 번호, 씬 번호, 테이크 번호처럼 보이는 식별자에서 출발해 자신의 매체 목록과 항목별로 대조해야 합니다. 매체 쪽 명명, 릴 번호 또는 디렉터리 규칙이 결과물 기록과 맞지 않으면, 경로를 짐작하는 대신 실제 소재와 현장 기록으로 돌아가 확인해야 합니다. 직접 재연결 관계는 결과물 자체가 제공하지 않습니다.

그러므로 이런 파일은 매체 목록이나 매체 백업이 아니라 기록 및 교환 데이터로 이해해야 합니다. 이들이 내놓는 것은 칸 하나에 들어간 보내는 쪽의 문자이지, 기록에서 수신자 기계의 소재 위치로 가는 해석 가능한 포인터가 아니며, 수신자 프로젝트에서 매체 링크가 자동으로 세워진다는 약속도 구성하지 않습니다. 마무리할 때 수신자는 릴 번호, 씬 번호, 테이크 번호로 자신의 매체 목록을 직접 확인해야 합니다.

FAQ

칸에 경로가 적혀 있는데도 왜 수신자의 소재로 다시 이어지지 않습니까?

파일 이름은 기록 속 신원 단서이고, 경로는 매체가 실제로 놓인 위치로, 둘은 같은 것이 아닙니다. ALE과 CSV에 그 두 칸이 있지만, 열 이름은 서로 다릅니다: CSV는 Source File Name과 Source File Path, ALE은 Source File Name과 Source File이고, CSV는 저장된 값을 있는 그대로 써 내고, ALE의 그 두 칸은 ASCII만 받아들여서 비라틴 문자가 끼면 칸 전체가 빈칸이 됩니다. PDF와 FDX에는 그 두 칸조차 없습니다. 칸에 들어가는 값은 현장에서 옮겨 적은 것이거나 가져올 때 그 기계에 있던 주소이고, 어느 쪽이 이름 붙이는 것도 촬영 쪽 파일일 뿐이라 수신자 기계의 디렉터리로는 이어지지 않습니다. 그래서 그 칸에 글자가 있다고 수신자가 열 수 있는 저장 위치가 채워지지 않습니다.

결과물에서 사진 원본 파일을 되받을 수 있습니까?

결과물만으로는 되받을 수 없습니다. 결과물이 담는 것은 릴 번호와 클립 번호로 조립한 파일 이름이고, 사진의 원래 경로가 아니며, 원본 파일과 바이트 단위로 같다는 보장도 없습니다.

CSV는 필드가 더 많아서 수신자가 쓸 수 있는 경로까지 함께 얻습니까?

열이 더 많다는 이유만으로 수신자가 해석할 수 있는 저장 위치가 채워지지는 않습니다. CSV는 기록에 있는 그 경로를 한 칸에 있는 그대로 써 내고, ALE의 같은 이름 두 칸은 ASCII만 받으며, PDF와 FDX에는 그 두 칸이 애초에 없어서, 칸에 글자가 있어도 그것이 가리키는 것은 보내는 쪽 기계 위의 위치입니다.

소재를 재연결해야 할 때는 무엇을 근거로 해야 합니까?

수신자는 릴 번호, 씬 번호, 테이크 번호처럼 보이는 식별자를 직접 자신의 매체 목록과 실제 파일에 대조해야 합니다. 결과물 속 그 칸의 경로가 가리키는 것은 보내는 쪽의 디렉터리라서, 그것을 자기 기계 위의 주소로 써서는 안 됩니다.

Axiom One LLC — SlateX