Por que um arquivo de entrega não devolve um caminho até a mídia
ALE, CSV, PDF e FDX conseguem entregar registros estruturados, mas nenhum deles entrega um caminho que resolva até a mídia na máquina da parte receptora. Os dois arquivos legíveis por máquina trazem, sim, uma célula de nome de arquivo e uma célula de caminho, mas os nomes das colunas não são comuns: no CSV são Source File Name e Source File Path, no ALE são Source File Name e Source File: o CSV escreve exatamente o caminho que o registro guarda, e as duas células do ALE só saem quando a cadeia inteira é ASCII, de modo que um texto não latino as deixa vazias; o que há nelas é o texto copiado no set ou, quando a mídia foi importada de um arquivo, o endereço registrado naquela máquina, e sem nenhuma das duas a célula sai vazia. O PDF e o FDX não trazem nenhuma das duas.
A mídia tem um lugar de gravação no repositório do projeto; mesmo quando a célula na entrega está cheia de texto, o que ela nomeia é uma posição na máquina de quem envia, e a parte receptora não consegue reconectar a sua própria mídia a partir dela.
O endereço numa célula da entrega pertence a quem envia, e a mídia estar ou não nesta máquina é outra questão
Como o app guarda a mídia neste dispositivo é assunto do próprio app; o que importa aqui é que um caminho numa célula da entrega pertence ao disco de quem envia e não é um ponteiro que a parte receptora consiga resolver. Ao gerar ALE, CSV, PDF ou FDX, o arquivo leva os registros de filmagem e os campos relacionados, e não uma lista de lugares da mídia da parte receptora. Assim, mesmo que a parte receptora veja o número do rolo, o número da cena ou o número da tomada, ela não obtém do arquivo de entrega a posição física de um arquivo local seu. O número do plano vira coluna separada apenas no CSV e no PDF; o ALE não tem essa coluna.
Por que o nome do arquivo também não serve de substituto do caminho original
O próprio nome do arquivo em disco já pode ser diferente do nome que ele tinha quando chegou, e por isso não dá para reconstituir por ele de onde aquela mídia veio.
As fotos vêm de duas fontes: as capturadas no set ou por tomada rápida e as escolhidas na galeria ou importadas de um arquivo. Nenhum dos dois casos traz o caminho original. Portanto, mesmo que a parte receptora encontre por acaso um nome de arquivo parecido, não pode tomá-lo como prova de “nome original mais bytes originais”; a célula de nome de arquivo na entrega é montada a partir do número do rolo e do número do clipe, e não é o nome que está em disco. A arrumação do lado da mídia fica nesta máquina; o caminho escrito numa célula da entrega nomeia o diretório desta máquina, não a cópia da mídia que está com a parte receptora.
“O caminho de uma célula da entrega não reconecta a mídia da parte receptora” descreve um limite da troca, e não um julgamento sobre a mídia existir ou não no repositório local do projeto.
Por que isso limita direto a reconexão da mídia
O caminho escrito numa célula da entrega aponta para o diretório de quem envia, por isso continua faltando à parte receptora o ponteiro físico que leva de uma linha de registro direto a uma posição de arquivo na sua própria máquina. Campos como número do rolo, número da cena e número da tomada continuam servindo para estabelecer relações de identidade, mas são identificadores, não caminhos. Cabe a ela relacionar esses identificadores com a própria lista de mídia, com a nomenclatura de arquivos e com o conteúdo real dos diretórios.
É por essa razão que “Ao receber uma ALE, confira estes campos” pede que a parte receptora volte à mídia e ao registro do set para conferir. Um arquivo abrir bem e ter algumas colunas legíveis não quer dizer que ele carregue também a posição da mídia. Se um fluxo de trabalho exige localizar a mídia direto a partir da entrega, essa correspondência precisa ser completada pela informação de mídia que o lado do recebimento já tem.
Por que os quatro formatos param no mesmo limite
ALE e CSV são tabelas legíveis por máquina, o PDF é um resumo feito para a leitura humana e o FDX cuida da troca de roteiro. ALE e CSV partem dos mesmos registros de filmagem e trazem uma célula de nome de arquivo e uma de caminho, mas os nomes das colunas não são comuns: no CSV Source File Name e Source File Path, no ALE Source File Name e Source File: o CSV escreve tal qual o valor guardado, as duas do ALE só aceitam ASCII, e o valor vem do que foi copiado no set ou do endereço registrado quando a mídia foi importada de um arquivo; sem nenhum dos dois, a célula fica vazia. O PDF existe para a leitura, e o FDX usa conteúdo do lado do roteiro, que nem traz registros de tomada. Em nenhum dos quatro há um endereço que a parte receptora consiga resolver na sua própria mídia, e a diferença de formato não muda esse limite. Não se pode inferir que, porque um formato tem mais colunas, aquele endereço vire um lugar que a parte receptora consiga abrir. Veja “Onde ficam os arquivos de entrega depois da exportação e por quanto tempo eles ficam”.
Por exemplo, “O que um CSV de entrega leva a mais e a menos que um ALE” trata da diferença entre conjuntos de campos, e não de um caminho que passa do nada a existir. “Ao receber uma ALE, confira estes campos” percorre célula por célula quais saem vazias porque no set ninguém as copiou, e como essa célula ausente aparece na folha de conciliação do fim de dia. “ As várias caras de um valor ausente num arquivo de entrega ” abre uma camada abaixo dessa célula vazia: string vazia, hífen no lugar do valor, número gerado por padrão e timecode todo em zero — cada um sai por um motivo diferente. Ao receber, “essa célula ninguém encheu”, “essa célula traz texto copiado” e “um ponteiro que de fato reconecta a mídia” precisam ficar separados. Um nome escrito numa coluna não é uma posição.
Como a parte receptora deve montar a correspondência com a mídia
Quando for preciso relacionar os registros da entrega com a mídia, a parte receptora deve partir dos identificadores visíveis, como número do rolo, número da cena e número da tomada, e conferir item por item contra a própria lista de mídia. Se a nomenclatura do lado da mídia, o número do rolo ou a regra de diretório não baterem com o registro da entrega, a confirmação deve voltar à mídia real e ao registro do set, em vez de adivinhar um caminho. O arquivo de entrega, por si, não fornece essa relação direta de reconexão.
Esses arquivos, portanto, devem ser entendidos como dados de registro e de troca, e não como uma lista de mídia ou uma cópia de segurança da mídia. O que eles dão é uma string que vem de quem envia, escrita numa célula, não um ponteiro que resolva do registro até a mídia na máquina da parte receptora, nem constituem promessa de que um projeto receptor consiga montar os vínculos de mídia automaticamente. No fechamento, a parte receptora deve conferir ela mesma o número do rolo, o número da cena e o número da tomada contra a própria lista de mídia.
FAQ
Se a célula traz o caminho escrito, por que ainda assim ele não reconecta a mídia da parte receptora?
O nome do arquivo é uma pista de identidade dentro do registro, e o caminho é onde a mídia realmente está gravada: não são a mesma coisa. O ALE e o CSV trazem cada um essas duas células, mas os nomes das colunas não são comuns: no CSV são Source File Name e Source File Path, no ALE são Source File Name e Source File; o CSV escreve tal qual o valor guardado, e as duas células do ALE só aceitam ASCII, então um texto não latino as deixa vazias, e o PDF e o FDX não têm nenhuma das duas. O valor vem do que foi copiado no set ou do endereço registrado na máquina no momento da importação; nos dois casos ele dá nome aos arquivos do lado das filmagens, não ao diretório da máquina da parte receptora, por isso uma célula cheia nunca reconstrói uma posição que a parte receptora consiga abrir.
A entrega me devolve o arquivo original da foto?
Não só com a entrega. O arquivo de entrega traz um nome de arquivo montado a partir do número do rolo e do número do clipe, não o caminho original da foto, e não promete uma correspondência byte a byte com o arquivo original.
Como o CSV tem mais campos, ele traria por isso um caminho que a parte receptora consiga usar?
Mais colunas não entregam à parte receptora uma posição que ela consiga resolver. O CSV escreve na sua célula o caminho que o registro guarda, as duas células de mesmo nome do ALE só aceitam ASCII, e PDF e FDX não têm essas duas células — cheia de texto, a célula continua nomeando uma posição na máquina de quem envia.
Em que se apoiar quando for preciso reconectar a mídia?
A parte receptora deve conferir ela mesma os identificadores visíveis, como número do rolo, número da cena e número da tomada, contra a própria lista de mídia e os arquivos reais. O caminho que a entrega traz pertence à máquina de quem envia e não deve ser lido como um endereço no disco da parte receptora.
Axiom One LLC — SlateX