Perché un file di consegna non può restituire un percorso che ricolleghi i media
ALE, CSV, PDF e FDX possono tutti passare record strutturati, ma nessuno di loro passa un percorso che si risolva nei media sulla macchina di chi riceve. Nei due file leggibili dalla macchina ci sono una casella per il nome del file e una per il percorso, ma i nomi delle colonne non sono gli stessi: nel CSV sono Source File Name e Source File Path, nell’ALE sono Source File Name e Source File: il CSV scrive il percorso che il record contiene, mentre le due caselle dell’ALE escono solo se l’intera stringa è ASCII, quindi un testo non latino le lascia vuote per intero. I valori vengono dal testo copiato sul set, oppure, quando i media sono stati importati da un file, dall’indirizzo registrato su quella macchina; se non è avvenuto nessuno dei due, la casella viene consegnata vuota. PDF e FDX non portano nessuna delle due caselle.
I media hanno una loro posizione su disco nell’archivio del progetto; anche quando la casella nella consegna è piena di testo, quel che nomina è una posizione sulla macchina di chi invia, e chi riceve il file non può riconnettere i media propri partendo da quella.
Che l’indirizzo in un file di consegna appartenga a chi invia è una cosa, e un’altra è se i media siano su questo dispositivo
Come l’app conserva i media su questo dispositivo è una faccenda che riguarda solo lei; qui conta che un percorso scritto in un file di consegna appartiene alla macchina di chi invia e non è un puntatore che chi riceve il file possa risolvere. Quando si genera un ALE, un CSV, un PDF o un FDX, il file porta i record di ripresa e i campi correlati, non un elenco di percorsi dei materiali. Chi riceve il file, anche se vede il numero di rullo, il numero di scena o il numero di ciak, non riceve la posizione fisica del file locale usata dal progetto di origine. Il numero di inquadratura è una colonna separata solo in CSV e PDF; ALE non ha quella colonna.
Perché anche il nome del file non sostituisce il percorso originale
Il nome del file su disco può essere già diverso dal nome con cui il materiale è arrivato, e quindi non permette di risalire da dove provenga.
Le foto arrivano da due fonti: quelle scattate sul set o con l’istantanea e quelle scelte dalla libreria o importate da un file. Nessuna delle due categorie porta il percorso originale. Anche se chi riceve il file incontra per caso un nome di file simile, non può trattarlo come la prova di un rapporto «nome originale più byte originali»; quella casella del nome nel file di consegna è composta a partire dal numero di rullo e dal numero di clip, non è il nome su disco. La normalizzazione dei media resta su questo dispositivo, e un percorso scritto in una casella della consegna nomina la directory di quel dispositivo, non la copia dei media di chi riceve il file.
«Il percorso in una casella della consegna non ricollega i media di chi riceve il file» descrive un confine dello scambio, non è un giudizio sull’esistenza dei media nell’archivio del progetto sul dispositivo.
Perché questo limita direttamente la riconnessione dei media
Un percorso scritto in un file di consegna punta alla directory di chi invia, e a chi riceve il file manca comunque quel puntatore fisico che porterebbe da una riga di record alla posizione di un file sul proprio dispositivo. I campi come numero di rullo, numero di scena e numero di ciak servono ancora a stabilire i rapporti di identità, ma sono identificatori, non percorsi. Chi riceve il file deve far corrispondere quegli identificatori al proprio elenco dei media, alla denominazione dei file e alla struttura reale delle directory.
È la ragione per cui «Ricevuto un ALE, controlla prima questi campi» chiede a chi riceve il file di tornare sui media e sulle registrazioni del set. Che un file si apra e che alcune colonne si leggano non vuol dire che porti anche la posizione dei media. Se un flusso di lavoro richiede di partire dal file di consegna per localizzare i media, quella corrispondenza va integrata con le informazioni sui media già disponibili sul lato ricevente.
Perché tutti e quattro i formati cadono sullo stesso confine
ALE e CSV sono tabelle leggibili dalla macchina, PDF è un riassunto destinato alla lettura umana e FDX serve allo scambio della sceneggiatura. ALE e CSV partono dagli stessi record di ripresa e portano una casella per il nome del file e una per il percorso, ma i nomi delle colonne non sono comuni: nel CSV Source File Name e Source File Path, nell’ALE Source File Name e Source File: il CSV scrive il valore registrato così com’è, le due caselle dell’ALE accettano solo ASCII, e i valori vengono dal testo copiato sul set o dall’indirizzo registrato quando i media sono stati importati da un file; con nessuno dei due, la casella resta vuota. Il PDF esiste per essere letto, e FDX lavora su contenuti del lato sceneggiatura che non portano nemmeno i record di ciak. In nessuno dei quattro file c’è un indirizzo che chi riceve il file possa risolvere nei propri media, e la differenza di formato non cambia questo confine. Dal fatto che un formato abbia più colonne non si può inferire che quell’indirizzo diventi un luogo che chi riceve il file può aprire. Vedi «Dove restano i file di consegna dopo l’esportazione, e per quanto».
«Cosa porta in più una consegna CSV rispetto a un ALE», per esempio, discute la differenza tra gli insiemi di campi, non un percorso che compare dal nulla. «Ricevuto un ALE, controlla prima questi campi» passa in rassegna casella per casella quali escono vuote perché sul set non è stato copiato niente, e come quella casella mancante si mostri nella tabella di confronto di fine giornata. «Le diverse facce di un valore mancante nei file di consegna» aggiunge uno strato sotto quella casella vuota: stringa vuota, trattino come segnaposto, numero predefinito generato dal sistema e timecode tutto zeri arrivano ciascuno per una ragione diversa. In ricezione «la casella non è stata copiata», «la casella contiene testo copiato» e «un puntatore che potrebbe davvero riconnettere i media» vanno tenuti separati. Un nome scritto in una colonna non è una posizione.
Come ricostruisce la corrispondenza con i media chi riceve il file
Quando i record di consegna vanno fatti corrispondere ai media, si parte dagli identificatori visibili, numero di rullo, numero di scena e numero di ciak, e li si confronta a uno a uno con il proprio elenco dei media. Se la denominazione lato media, i numeri di rullo o le regole delle directory non tornano con i record di consegna, occorre confermare sui materiali effettivi e sulle registrazioni del set, non indovinare un percorso. Il file di consegna, di per sé, non fornisce quel rapporto di riconnessione diretta.
Questi file vanno quindi intesi come dati di record e di scambio, non come un elenco dei media o un loro backup. Quello che danno è una stringa che viene dal lato di chi invia, non un puntatore risolvibile dal record ai media sulla macchina di chi riceve, e non costituiscono l’impegno che un progetto ricevente stabilisca i legami con i media in automatico. In chiusura, chi riceve il file deve verificare in autonomia numero di rullo, numero di scena e numero di ciak contro il proprio elenco dei media.
FAQ
Perché una casella piena di percorso comunque non ricollega i media di chi riceve il file?
Il nome del file è un indizio di identità dentro il record, il percorso è dove i media stanno davvero: non sono la stessa cosa. ALE e CSV hanno ciascuno una casella per il nome del file e una per il percorso, ma i nomi delle colonne non sono comuni: nel CSV Source File Name e Source File Path, nell’ALE Source File Name e Source File: il CSV scrive il valore registrato così com’è, e le due dell’ALE accettano solo ASCII, quindi un testo non latino le lascia vuote per intero. PDF e FDX non hanno nessuna delle due. I valori vengono dal testo copiato sul set o dall’indirizzo registrato all’importazione, e in entrambi i casi dànno un nome ai file del lato riprese, non alla directory della macchina di chi riceve, così una casella piena non ricostruisce mai una posizione che chi riceve possa aprire.
La consegna mi restituisce il file originale della foto?
Non con la sola consegna. Il file di consegna porta un nome di file composto dal numero di rullo e dal numero di clip, non il percorso originale della foto, e non promette una corrispondenza byte per byte con il file originale.
Più campi nel CSV finiscono per portare un percorso risolvibile da chi riceve il file?
Un numero maggiore di colonne non consegna a chi riceve il file una posizione che possa risolvere. Il CSV scrive ciò che il record contiene, che sia testo copiato sul set o l’indirizzo registrato quando i media sono stati importati da un file, le due caselle omologhe dell’ALE accettano solo ASCII, e PDF e FDX quelle due caselle non le hanno affatto; una casella piena nomina comunque la directory di chi invia.
A cosa ci si deve appoggiare quando i media vanno riconnessi?
Chi riceve il file deve verificare in autonomia gli identificatori visibili, numero di rullo, numero di scena e numero di ciak, contro il proprio elenco dei media e i file effettivi. Il percorso che sta in una casella del file di consegna appartiene alla macchina di chi invia e non va letto come un indirizzo sul disco di chi riceve.
Axiom One LLC — SlateX