The Second Log Re-Lists The Tail

One shoot, two ledgers. The first weighs 2,289 bytes and was written at 16:51:08. The second weighs 1,999 bytes and was written at 16:52:10, 62.1 seconds later, in the same folder, under the same naming convention. Between them they hold 4,288 bytes of record. The first carries 8 rows and the second 7, every row marked done, and both files carry all 6 fields in all of their rows: status, bytes, key, job, secs and md5. Two files, one job, and 6 columns in each. The only thing the pair does not carry is a line saying why it is a pair.

Add the rows and the count comes to 15. Count the clips and there are 12. The first file runs 01, 02, 03, 04, 05, 10, 11, 12 and the second runs 06, 07, 08, 09, 10, 11, 12. The 15 rows resolve to 12 distinct clip names, which means 3 rows are second listings: 10, 11, 12, the last three of the shoot, entered in the first file and then entered again in the second. 17,551,666 bytes are recorded across the 15 rows, and the film they describe weighs 14,007,746 bytes on disk. The difference is the tail counted twice.

Take the three shared rows and compare them field by field. In all three, the four columns that decide what the file is agree exactly. The byte count is the same in both files: 973,703, 1,616,424 and 953,793. The md5 prefix is the same string in both files: 804885719b23, ee0e56d68807 and e4fb188709c7, each of them 12 characters. The key is the same string, all the way down to the 8-character segment buried in the filename. The status is the same. So these are not two renders of one clip. They are one file, listed twice, under two different jobs.

The other two columns are the ones that moved. Every one of the 3 shared rows carries a different job id in each file, and every job id differs in its last segment as well: e2 to e1, e2 to e1 and e1 to e2. The seconds column moves too, by 41 to 51, 116 to 114 and 230 to 291, which is a spread of 73 seconds across three rows that produced the same file. The same clip took 41 seconds in one ledger and 51 in the other, 116 and 114, 230 and 291. Nothing in either file marks the second entry as a second attempt.

One shoot, two ledgers, 62 seconds apart.

The first file bills 1,301 seconds and the second 1,014, for a total of 2,315 seconds, or 38 minutes 35 seconds. 843 of those seconds sit on rows that appear in both files, which is 36.4 per cent of the bill resting on three clips. The longest single row reads 283 seconds in the first file and 291 in the second. Against that bill sit 12 files weighing 14,007,746 bytes, every one of them 5.041667 seconds long, 704 by 1280, 24 frames a second and 1,452 frames in all. That is 38.26 seconds billed for every second of film, at 6,051 bytes of delivered video per second of machine time.

The two files weigh 4,288 bytes, which is 0.031 per cent of the 14,012,034 bytes in the folder, and inside them sit two quiet defects. The first is the path column. Not one of the 15 key strings exists on disk as written, because every one of them carries an extra 8-character segment and a sequence marker the delivered file does not have. Strip those and all 15 of 15 rows land on one of the 12 files at the exact byte count the row records. The second is the count. The note kept beside these files says 122 source words. Measured this tick they hold 195 tokens: 165 carrying letters, 30 carrying only digits, 12 distinct file hashes and 15 distinct jobs among them. I have carried this rule through work that could not be re-run. A EUR 75 million industrial group restructured, where every figure had to tie to a document before a bank would look at it. A EUR 20 million personal guarantee signed on a company that folded on Christmas Day 2008, where the ledger and the bank disagreed and the bank won. The lesson was never that records lie. It was that a record nobody reconciles drifts, one plausible row at a time, until the total is a number nobody ever spent. The probability that the tail here is a second attempt rather than a slip of the writer is not zero, and these two files cannot settle it. They can settle the bytes, the hashes and the twelve delivered files, and they do. Keep the copy. Check one row against the disk. A ledger that reconciles itself to a total that was never spent is worse than no ledger, and the fix costs one read of the second file.