Martin Monperrus

He covers error correction and information densities on the linked page: https://www.monperrus.net/martin/perfect-ocr-digital-data (Last section before conclusion.) IIUC this provided the best overall reliable information density (at 4.2kb / A4 page).

You could add an appendix with printed, scannable, binary data. You could create a page with a bunch of QR codes. Martin Monperrus vouched [0] for Twibright Optar [1]. [0] https://www.monperrus.net/martin/store-data-paper [1] https://ronja.twibright.com/optar/

Take a look at the ideas here https://www.monperrus.net/martin/store-data-paper

Was running it fine on Linux IIRC (maybe look it up if you're actually interested?), but again, long time ago so things may have changed. EDIT: Things seem to have deteriorated quite a bit and no major improvement in sight. Maybe not a surprise. https://www.monperrus.net/martin/bankid-linux https://www.sweclockers.com/forum/trad/1592956-bankid-pa-linux

This site suggests a limit of around 100KB per page with standard printer and scanner fidelity: https://www.monperrus.net/martin/store-data-paper

Paper? https://www.monperrus.net/martin/store-data-paper I mostly jest. It would require a lot of paper. But it should be stable storage for potentially centuries.

What about mu plus mu4e Thunderbird plus global search Recoll + client of choice https://www.monperrus.net/martin/recoll-maildir-thunderbird

https://www.monperrus.net/martin/perfect-ocr-digital-data https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki

I wonder if you could convert TeX. (Background: http://www.monperrus.net/martin/compiling+Knuths+tex+with+GNU+Pascal+-… )

The font choice is discussed here: https://www.monperrus.net/martin/perfect-ocr-digital-data From the linked article: >The optimal font varies very much on the considered engine. Monospaced fonts (aka fixed-width) such as Inconsolata, are more appropriate in general. ocr-a and ocr-b ocrb give really poor results. I noticed that they liked using lower case letters for bases where that is a choice. I would think that the larger, upper case letters would be better for OCR. Using lower case for either OCR-A or OCR-B would be a poor idea in any case. The good OCR properties are only provided for the upper case letters. The lower case letters were mostly provided for completeness. Also, the author might be training on entire blocks of characters rather than individual characters. That isn't really want you want here unless you are using something like words for your representation. OCR-A and OCR-B were designed for character by character OCR.

I only recently started using it, but I think most of the limitation on metadata is from git itself. (Remember all the metadata is in git; the data is in the "annex".) This person said they put over a million files in a single git repo, and pushed it to Github, and that was in 2015. https://www.monperrus.net/martin/one-million-files-on-git-and-github I'm using git annex for a repository with 100K+ files and it seems totally fine. If you're running on a Raspberry Pi, YMMV, but IME Raspberry Pi's are extremely slow at tasks like compiling CPython, so it wouldn't surprise me if they're also slow at running git. I remember measuring and a Rasperry Pi with 5x lower clock rate than an Intel CPU (700 Mhhz vs. 3.5 Ghz) was more like fifty times slower, not 5 times slower. --- That said, 500 million is probably too many for one repo. But I would guess not all files meed a globally consistent version, so you can have multiple repos. Also df --inodes on my 4T and 8T drives shows 240 million, so you would most likely have to format a single drive in a special way. But it's not out of the ballpark. I think the sync algorithms would probably get slow at that number. It's definitely not a cloud storage replacement now, but I guess my goal is to avoid cloud storage :) Although git annex is complementary to the cloud and has S3 and Glacier back ends, among many others.