[sz3]

Hello all,

You've seen QR codes, maybe Microsoft HCCB [0], maybe jabcode [1] – well, here's a prototype of something new for the pile. :)

I saw txqr [2] a while back and was impressed, but also curious about how much throughput was possible with animated bar codes. I may have gotten carried away in my research into the question.

cimbar is a single and multi-frame color barcode format using reed solomon (for now) and wirehair [3] for error correction. Files are encoded into an animated series of bar codes drawn to the display. Files are decoded by an Android app [4] with its camera pointed at the cimbar code. This works with all antennas off, e.g. in airplane mode, because it's only using the visual data channel.

I ported the encoder to wasm, because I could: https://cimbar.org

Sustained transfer speed is currently on the order of 800 kilobits/second. So it's not very practical for files larger than a couple of MB, unless you have a lot of free time. :)

[0] https://en.wikipedia.org/wiki/High_Capacity_Color_Barcode

[1] https://github.com/jabcode/jabcode

[2] https://github.com/divan/txqr

[3] https://github.com/catid/wirehair

[4] https://github.com/sz3/cfc/releases/latest

[ignoramous]

As a possible tangent, convert those images to inaudible audio to transfer files over the air: https://github.com/ganny26/awesome-audioqr

(air-gapped computers be damned)

[sz3]

Well, there's diminishing returns in format shifting. The encoded barcode contains various types of quasi-redundant visual information (e.g. error correction codes) to allow decoding to happen, so for audio-based transfer it'd be better to skip the image encode and blast out the file directly.

That said... given the somewhat remarkable way fountain codes work, there's nothing stopping us from having a protocol that uses the audio and the video channels simultaneously for better throughput...

[rmetzler]

Would it be beneficial to use one channel (either audio or visual) to transmit the information and the other one for responses like acknowledge? So kind of like TCP over two different channels?

[sz3]

Well, as for acks specifically -- cimbar itself doesn't really need them, thanks to fountain codes [0].

But I can imagine a reverse (request?) channel being useful, if it had enough bandwidth for the desired application. :)

As /u/ggerganov notes elsewhere in this thread (with some expertise on the audio side -- I can't claim any), the bandwidth of any audio channel is probably going to be pretty bad.

edit: Notwithstanding how viable of an idea it might be, HTTP over audio+video would be pretty neat. :)

[0] https://en.wikipedia.org/wiki/Fountain_code

[ggerganov]

I don't think air-gapped audio transmission could ever reach a fast and reliable transmission so that it allows transferring files in reasonable amount of time over reasonable transmitter-receiver distances. It's just too many hardware and physical limitations for this approach.

Having said that, I am actually working on a small library for data-over-sound which can be used for small data chunk transmissions across the room [0].

[0] https://github.com/ggerganov/ggwave

[ktpsns]

Amazing! Do you know any variants of these which squeeze out the maximum transfer rate over a high quality connection? Thinking about data transfer from a VPN/RDP remote desktop where I want to grab the screen output on the client with very little loss in quality (basically only limited by the chosen video encoder).

[mleonhard]

Using it to transfer files over a remote desktop connection is like a graphical version of zmodem [0].

[0] https://en.wikipedia.org/wiki/ZMODEM

[sz3]

I don't think I do?

I'm not 100% sure I understand your example. Is it RDP server (remote) -> RDP client (local) -> cell phone?