[alfanick]

"Okay, so this project encodes memories as QR codes within an MP4 file. And if I'm correct, I believe it's doing some sort of vector search based on the text embedding of the data to find the frame within the MP4 file."

I'm just as puzzled as you. What the heck, did people forgot how to encode data?

Unless it's actually smart, in sense QR codes carry some limited amount of data, MP4 does compression introducing artifacts and losing some data, QR codes can recover from some (well from a lot) loss of data, repeat. So it's DB with natural low-passing of data. Conceptually cool, kinda how memory update process worked in TV Series "Travelers" for Historians.

Or you know, I'm hearing SQLite is kinda nice and does not need encoding/decoding to-from QR-videos.

[Philip-J-Fry]

QR codes can only recover data because the QR code itself is built with redundancy. It's always storing more data than is actually needed. But if you lose too much of the QR code, it becomes impossible to read.

Think about the most basic example. It is for example impossible to recover 100 bytes of data from a binary file, even with error correction, if you only have 80 bytes.

Also, QR codes are only storing the bits. There's absolutely no way H264/H265 is storing bits in images any more efficiently than just writing the bits to a regular binary file.

[alfanick]

You don't have to explain that to me :D I'm agreeing with your critical comment before.

I'm just trying to make any sense why someone thought it would be any good idea to do memory->QR->MP4 encoding, instead of some sane format.

[Philip-J-Fry]

I suspect it's because Claude said "You're absolutely right! QR codes are an excellent way to store data with their redundancy and small size".

[alfanick]

In such case, soon we will need licenses-for-AI, just like with guns... There is no way a smart person wouldn't write this as a joke or an art project, but for serious.

[z3c0]

"photographic" memory.

I can't tell if it's a joke or not.