Nine Rows Numbered To Ten

Open the log and there are nine keys, food_01 through food_10, and food_08 is not among them. Every key holds four fields, status, key, bytes, job, so the whole file is 36 cells in 1,906 bytes, and 9 of 9 statuses read done. The hole is in the middle of the sequence, not at the end of it. A run numbered to ten holds nine rows. Nothing in the file records an attempt at the tenth, no error, no retry, no note, no date of any kind. The names are the only description of what is inside the clips, and they are short: overhead table, overhead hands, overhead fruit, overhead brunch, coffee, juice, eating, sunlight, plants. 211.8 bytes a row. 52.94 bytes a cell. That is the entire record of nine finished renders.

The bytes column is nine distinct values adding to 7,004,438, a mean of 778,271 a row. The lightest is 653,105, the plants row. The heaviest is 986,773, the juice row, 1.511 times the lightest. Read the four overhead rows together and they hold a line: 673,764, 676,915, 683,150, 685,205. An 11,441 byte band across four rows, a spread of 1.017. Four frames of one table from one afternoon, priced within two per cent of each other by a machine that was not asked to price them at all.

Above that band the column opens. The heaviest overhead frame is 685,205 and the juice row is 986,773, which is 301,568 bytes heavier, 44 per cent above the top of the band. Three of the five remaining rows sit close together: coffee at 945,747, juice at 986,773, sunlight at 954,483, a 41,026 byte band. The other two fall well below it, eating at 745,296 and plants at 653,105. So the column is two shapes, a tight four and a wide five. The four average 679,759 bytes and the five average 857,081, a ratio of 1.261 between them. The name does not predict the weight. Plants is the lightest row in the file and it is written last.

The nine keys run 65 to 75 characters, and the first 35 of them are identical: one directory, one output folder, one video path. What changes is the tail, and the tail is built the same way in 9 of 9 rows. Every leaf is emma_, then the row's own name, then _00001_, then .mp4. So every row prints its own name twice, once as the key and once inside the address of the file it points at, and every leaf carries take one. Nine rows, no take two anywhere in the folder. 1,906 bytes of record describe 7,004,438 bytes of mp4, a ratio of 3,674.9 to 1, which is 11,153.6 bytes of finished video for every character of key.

Nine rows, thirty six cells, 7,004,438 bytes of finished video, and a hole in the middle of the sequence.

Each row carries one job id, 39 characters long, and the nine UUID bodies behind them are all distinct. Three end in one suffix, six in another, and the split does not follow the byte band. The three are overhead table, overhead brunch and plants, a group that spans 653,105 to 685,205 bytes, so it holds two of the four overhead frames and the lightest row in the file. Nobody reading this in six months will know why. The job ids are 351 of the 1,906 bytes, 18.4 per cent of the record, and they are the one field that outlives the render. There is no clock anywhere in it. No date, no seconds, no start, no finish. Four fields a row, and none of them says when.

Nothing in the 1,906 bytes records the tenth row. The file cannot say whether food_08 was skipped, failed, renamed or never asked for, because it holds only what came back done. I restructured a EUR 75 million industrial group once, and the surviving paperwork from that was thinner than this. The probability that the missing row was a decision rather than a failure is not zero. Neither is the probability that somebody will need to know which one it was. Nineteen hundred and six bytes is the whole insurance policy on this shoot, and it does not cover the single row anyone will ask about. Write the row that failed. It is the cheapest thing in the folder.