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, a célula Source File Name e a célula do arquivo de origem, e o que há nelas é o texto copiado no set: o software não varre o disco atrás de uma posição, e a célula que ninguém copiou sai vazia. O caminho real que está no repositório do projeto nunca foi trazido ao snapshot de exportação.

A mídia tem um lugar de gravação no repositório do projeto; a célula na entrega é texto copiado, e a parte receptora não consegue reconectar a mídia a partir dela.

Por que a mídia local tem dois destinos de gravação

A mídia salva na máquina não segue uma única regra de diretório. O vídeo gerado no formulário de criação vai para uma área plana de recebimento; a foto tirada, a escolha da galeria e a importação de arquivos feitas no lado da listagem vão para um diretório estruturado em camadas por projeto, cena, plano e tomada. Os dois destinos dizem respeito a como o repositório do projeto guarda a mídia.

O limite essencial é que esses caminhos existem só dentro do repositório do projeto e não entram no snapshot de exportação. Ao gerar ALE, CSV, PDF ou FDX, o que se recebe é um snapshot dos registros de filmagem e dos campos relacionados, e não uma lista de caminhos de mídia. 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 do arquivo na máquina. 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

Antes de a mídia ser gravada, o nome do arquivo passa por uma regularização: caracteres inválidos são substituídos por sublinhado, caracteres de controle são removidos e nomes longos demais são truncados; se depois disso não sobrar conteúdo utilizável, o nome cai em um marcador de posição fixo em inglês. Ou seja, o próprio nome do arquivo em disco já pode ser diferente do nome que existia na origem externa.

As fotos se dividem em dois casos: as obtidas por captura no set ou por tomada rápida são reencodadas, enquanto as escolhidas na galeria ou importadas de um arquivo entram no repositório com os bytes inalterados. 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. Caminho, regularização de nome e tratamento dos bytes da mídia são fatos da camada de armazenamento local, e não se transformam numa coluna de caminho de mídia dentro do arquivo de entrega.

“Não se lê o caminho na entrega” descreve um limite do resultado da exportação, 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

Sem um caminho de mídia na entrega, falta à parte receptora o ponteiro físico que leva de uma linha de registro direto a uma posição de arquivo na 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. O snapshot dos registros de filmagem que está por trás de ALE e CSV traz a célula Source File Name e a célula do arquivo de origem, e as duas se preenchem pelo que foi copiado no set: copiou, a célula tem conteúdo; não copiou, fica vazia. O PDF existe para a leitura, e o FDX usa um snapshot do lado do roteiro, que nem traz registros de tomada. Em nenhum dos quatro há uma célula com um caminho que o software tenha descoberto num disco, e a diferença de formato não muda esse limite. Não se pode inferir que, porque um formato tem mais colunas, ele traria junto os lugares da mídia no repositório do projeto.

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. 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 copiada 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 ALE e CSV têm o nome do arquivo, por que ainda não se lê o caminho da mídia?

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. ALE e CSV têm cada um a célula Source File Name e a célula do arquivo de origem, preenchidas só se alguém as copiou, e as duas do ALE só aceitam ASCII, então um texto não latino as deixa vazias. O PDF e o FDX não têm nenhuma das duas. A string copiada dá nome aos arquivos do lado das filmagens, não ao diretório da máquina da parte receptora, por isso a presença dela nunca reconstrói uma posição que a parte receptora consiga abrir.

Depois de gravadas, as fotos ainda são os bytes inalterados do arquivo externo?

Nem sempre. As fotos obtidas por captura no set ou por tomada rápida são reencodadas; as escolhidas na galeria ou importadas de um arquivo entram com os bytes inalterados. Nenhum dos dois casos traz o caminho original.

Como o CSV tem mais campos, ele traria por isso o caminho da mídia?

Mais colunas não fazem aparecer um caminho que o software tenha encontrado. As duas células do CSV trazem texto copiado no set, as duas células de mesmo nome do ALE só aceitam ASCII, e PDF e FDX não têm essas duas células.

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. Não se deve deduzir o caminho completo da máquina a partir do conteúdo da entrega.

Axiom One LLC — SlateX. Os números acima são os de 2026-09-24.