Por qué las mismas tomas no coinciden fila por fila entre los archivos de entrega
Que el mismo lote de registros de toma dé números de filas y órdenes distintos en varios archivos de entrega no viene de que cada archivo saque los datos de un proyecto diferente. Todos parten de la misma instantánea, tomada por hora de creación, y después cada uno aplica claves de ordenación y granularidades de despliegue distintas: el producto tabular y la lista estructurada se despliegan por cámara, mientras que el informe diario sigue sacando una fila por take; la lista estructurada reordena por escena, plano y toma, y el informe diario usa otra clave de plano.
Al hacer la tabla de correspondencias entre archivos, la clave común estable es la identidad de escena, plano y toma, y no «la fila número tal».
El punto de partida es el mismo y las reglas de ordenación se separan después
La instantánea de origen se toma al principio por hora de creación de los registros, de menos a más. El producto tabular no aplica después otra ordenación, así que conserva en gran medida ese orden de creación. La lista estructurada reordena por número de escena, número de plano y número de toma, y en las dos primeras claves usa una comparación en orden natural. El origen de los datos es el mismo, pero la posición de las filas ya se separó de la del producto tabular.
El informe diario legible recorre además una ordenación propia: después de la escena usa como segunda clave el nombre cualificado del plano y ordena luego por número de toma. Ese nombre cualificado no es la cadena del número de plano original que usa la lista estructurada, así que dos archivos que contienen el mismo lote de tomas tampoco guardan una relación de «la segunda fila tiene que corresponder a la segunda fila».
El registro que se ve en pantalla tiene todavía otro orden: sube por la cadena del número de plano y después por el número de toma. Con ordenación de cadenas, 10 queda delante de 2. Esa es una secuencia de visualización propia de la capa de interfaz, y tampoco sirve para deducir desde ella la posición de las filas exportadas.
Los recuentos de filas cambian sobre todo por el despliegue por cámara
La lista estructurada y el producto tabular se despliegan por cámara: si un take incluye varias cámaras, genera varias filas, y si no hay cámara se conserva igualmente una fila. El informe diario hace lo contrario, cuenta las filas por take, así que un take multicámara sigue ocupando una sola fila.
Esto explica también por qué un mismo conjunto de registros del rodaje produce totales de filas distintos. Un take multicámaras se desdobla en la lista y en la tabla, y en el informe diario sigue siendo un take. Además, esa columna del informe que parece un número de secuencia, No., es el número de fila de todo el documento, no un número de take, así que menos todavía puede usarse como clave de correspondencia entre archivos.
Que cambie el número de filas viene de la granularidad del producto, no de que un archivo «tenga una grabación más» o «le falte una grabación».
La etiqueta del plano tampoco es la misma cadena en todos los productos
El informe diario legible usa el nombre cualificado del plano, mientras que la columna de plano del producto tabular usa el número de plano original. Un mismo plano puede aparecer en la interfaz o en un archivo con el prefijo de escena o en forma cualificada, y en otro archivo quedarse solo en la numeración más corta. El receptor debe leerlos dentro de la relación de escena, plano y toma, y no decidir si es el mismo registro solo porque dos cadenas de una columna coincidan por completo.
Lo que aquí se describe es el mecanismo del lado de nuestros productos. La evidencia actual no permite afirmar además cómo va a emparejar mal, dejar sin correspondencia o rechazar la importación un software de destino concreto. El comportamiento de recepción real sigue teniéndolo que comprobar el receptor columna por columna con su propia plantilla de importación.
Qué conviene usar al hacer la correspondencia
Al comprobar entre archivos hay que sujetar primero la escena, después el plano y después el número de toma; en los registros multicámara hay que seguir bajando hasta la cámara. El fin es tratar la relación de identidad como lenguaje común, y no tomar como clave principal una posición de fila que apareció por casualidad en uno de los archivos.
Si los dos archivos no tienen el mismo total de filas, hay que preguntar primero si habrán usado granularidades de despliegue distintas; si el orden no coincide, ver si habrán usado claves de ordenación de plano distintas. Solo cuando la propia relación de identidad no empareja hay que volver al registro de origen, en lugar de exigir antes que los productos coincidan fila por fila.
Estas diferencias son consecuencia del mecanismo de generación, pero que «el mecanismo sea así» tampoco autoriza a saltarse la comprobación. Cada producto asume una responsabilidad distinta, y el receptor sigue teniendo que confirmar que los campos que usa vuelven de verdad al mismo registro del rodaje.
FAQ
¿Por qué el producto tabular y la lista estructurada no siguen el mismo orden?
Porque el producto tabular conserva el orden de hora de creación, mientras que la lista estructurada reordena por escena, plano y toma. Los dos salen de la misma instantánea, pero las reglas de ordenación posteriores son distintas.
¿Por qué, con varias cámaras, los archivos no tienen el mismo total de filas?
Porque la lista estructurada y el producto tabular se despliegan por cámara y un take multicámara ocupa varias filas, mientras que el informe diario cuenta las filas por take, así que ese mismo take sigue ocupando una sola fila.
¿Puede emparejarse el No. del informe diario con el número de fila de otro archivo?
No debería. El No. del informe diario es el número de fila de todo el documento y no es el mismo concepto que el número de take, así que no sirve como clave de identidad entre archivos.
¿Qué clave común conviene usar para comparar varios archivos?
Hay que usar antes que nada la identidad de escena, plano y toma, y en los registros multicámara seguir comprobando la cámara, y no convertir el número de fila ni la posición de orden de un archivo en la clave común.
Axiom One LLC — SlateX. Las cifras de arriba son a fecha de 2026-09-24.