At the end of the day it's the same thing, 1.3 GB

I was sure. Sorting the cards by similarity before encoding would multiply the compression, because similar neighboring frames are exactly what video codecs love. I had written it in the bets, I had repeated it to the agent, and the benchmark had handed me back a strange row: the variant with inter came out bigger than the one without. The configuration was wrong, scene cut detection was on, and different card after different card is one scene cut per frame. The encoder was burning cycles looking for a scene that didn't exist. I turned it off and put together a second corpus, almost three thousand real reprints of the same art, grouped together.

That did it. With prediction in groups of sixteen frames, the file came out 29% smaller than without prediction. Groups of sixteen beat a single keyframe for the whole stream, which surprised me, and they still keep any card reachable by decoding at most sixteen frames. And a detail I didn't expect: shuffling the reprints instead of grouping them cost only two points. Part of the gain comes from the frame every card shares, not from the repeated art. The codec was exploiting the chrome, as I had suspected on day one, and that held for any order.

Building the whole corpus at night

With 29% in hand, I built the full corpus with similarity sorting and prediction on, and next to it the same corpus with none of that, to compare. And I built it with the media inside the file, because by then I no longer accepted MP4s sitting next to the database. Before getting there I opened the folder of an intermediate build and found .build, .cache, .forge-state, .tmp, a lock, a manifest, all next to a .nest of a few megabytes. What is all this for? I asked, and the honest answer was that every piece had a reason and none of them needed to be there once the build finished. Media inside the file was half the answer, the other half was cleaning up the output.

A .nest is a container of sections, each with its own hash. The new section is the simplest of all: a table of offsets and the raw bytes of the videos, glued one after another. An MP4 stays an MP4, nothing is re-encoded to fit. Opening the file doesn't touch the media, the system only maps the slice when someone asks for a card, and you can export the original MP4 back out with the hash checked before writing.

That section doesn't count toward Nest's content hash, and this matters more than it seems. The content hash is computed over what's inside the file, not over the packaging, and it's what makes a Nest citation point to a piece of knowledge instead of a place on disk. The same corpus built with the media inside and with the media outside gives the same hash. It cost three percent: the indexes, the card text and the vectors add up to about forty megabytes on top of 1.3 GB of video.

The builds ran overnight, and the night was rough. Two died with a full disk, because macOS was taking system snapshots in waves, eating and releasing gigabytes without warning, and at one point I was down to a hundred and thirty megabytes free. And in the middle of that I read a summary from the agent saying the corpus had 200 cards. I had a client meeting in a few hours.

"Seriously, you used 200 demo cards? I have a client meeting and I still don't have the dataset." I had it run validation on the 1.3 GB file. All 38 thousand blobs checked out, one by one. The corpus was complete, the summary was describing the pilot, and I had read the summary instead of the disk. After the encoder that wasn't using the tune the manifest claimed, it was the second time that week that what I read wasn't what was actually there.

At the end of the day

The sorted build sat next to the plain build. 1.3 GB both, no difference at all. I sent it to the agent at four in the morning: at the end of the day it's the same thing, right, 1.3 GB.

The reason was in the manifest, correct this time. Nest decides per segment whether to use prediction, encoding a sample both ways. On the real corpus, made of unique cards, the probe vetoed prediction in every segment. There's nothing to predict: the next card is another card, with other art, and the shared chrome doesn't pay for the cost. The 29% gain only exists on the reprint corpus, and I haven't built that one in full yet.

There was a worse part, which I only understood later. In an earlier version of the probe, it decided on bytes alone, and in a build of the sample it picked prediction for every segment because it tied on size. Median quality dropped sixteen points. The encoder compresses predicted frames with coarser quantization, and with unique cards a predicted frame is just a worse keyframe in disguise. Equal bytes aren't equal quality. The probe now measures both sides, accepts losing at most two points, and records the reason when it vetoes. The 29% matrix also compares bytes only, so the number is real but it isn't equivalent quality. I'm putting that down here because I forgot it myself for a whole day.

What if the file doesn't need to be pretty

What I take from that night isn't the 1.3 GB. It's that my intuition about codecs was wrong twice, and that I read summaries when I should read files. Now I only turn sorting on when the corpus has near-duplicates, and no build goes in without validation of the real file running alongside it.

And one question was left over that seemed more promising than any sorting. Nest's quality gate locks the codec at a conservative level because the visual metrics never pass on small cards with tiny print. But Felipe's app keeps every card's JPEG cached for display. The .nest only needs to answer which card it is. If the file doesn't need to be pretty, how far can you push the setting before search starts complaining?