If you want to have a little fun then writing a python script to convert a file to beeps and recover it from beeps is quite doable.

It also teaches you just how insane the speeds we have today are.

Yeah, I was experimenting with a similar thing a while back. The idea was to use camera equipped devices looking at each other to negotiate data transfer through dense QR-codes. Even with that substantially larger data frame support, transfer speed was abysmal at best.

Maybe this could interest: https://divan.dev/posts/animatedqr/

Wow! One of those moments when you realize that someone is doing exactly what you have been doing. My hobby project was seriously called QRTX. And each data frame started with ###-- where # are padded frame numbers. Pretty much identical to this guys project. Thanks for that find, I'm chuckling.

Points of difference: I was using a leading metadata frame with filename and total number of frames etc, and the receiving device were ACK'ing frame decodes with its own QR codes. Still, wow.

You are welcome, great project :)

Using QR codes sets you up for disappointment.

I wanted to store a gpg key offline by engraving it in metal. A reasonably sized one would taken six of the largest 177x177 plates to record.

The best solution I came up with was to use metallic punched tape of some description.

On low error correction level you can save 2953 bytes in binary and 4296 in alphanumeric mode. The latter should be fine for a gpg key.

I'm experimenting for fun on this side: https://github.com/dtonon/papiro

My fault: alphanumeric mode is not suitable for a GPG key, because it is:

> 0–9, A–Z (upper-case only), space, $, %, *, +, -, ., /, :

and so we miss the lowercase [a-z]. Therefore we need to use the 2953 bytes binary option.

A v40 QR code can hold ~3000 chars/bytes. Isn't that enough for a GPG key?

It's been over two years since I looked at it, but from memory I wanted a 8 KiB key pair that I could engrave. One was to be the public key that would be scannable, the other was the private key that would be kept in a safety deposit box.

The practical limit was 3KiB for the qr code and there was some metadata in the key I didn't want to lose. I can't remember if it was the private or public key that was giving me the most trouble. But the idea of just having something to point your phone at on a wall and read a signed message from me wasn't practical.

Compare also the FT8 weak signal radio protocol. Remarkably robust but serves a max of 77 bits per 15 seconds (and also hard codes radio specific codes/IDs in the message, it's not even general purpose)