[lifthrasiir]

> I can’t help but wonder if any of the other modes could be more efficient still—numeric mode, kanji mode and byte mode.

Byte mode is obviously most efficient. Alphanumeric mode uses 5.5 bits per each character, so combined with base45 it uses 5.5 * 3 = 16.5 bits to pack two octets. Base45 is actually not that bad as it seems (3.1% overhead). [EDIT: I've since seen edflsafoiewq's mention that typical QR readers try to interpret binary data as UTF-8, so it is not pointless.]

[MORE EDIT: I've completely missed the last paragraph, so I was actually just confirming what chrismorgan said.]

[chrismorgan]

> Maybe a compatibility issue?

From the introduction:

> Even in Byte mode a typical QR-code reader tries to interpret a byte sequence as an UTF-8 or ISO/IEC 8859-1 encoded text. Thus QR-codes cannot be used to encode arbitrary binary data directly.

Back to your comment:

> Base45 is actually not that bad as it seems (3.1% overhead)

That’s very close to my logarithm calculations from edflsafoiewq’s 40-L figures (the log₂₅₆ 45⁴²⁹⁶ bit of my comment, just added). Would you mind explaining to me what I did wrong with my 45³ ÷ 256² calculation that said 39%?

[lifthrasiir]

Oops, I've completely missed the last paragraph and thought that you were giving a wildly larger figure with a wrong assumption. Your actual assumption for optimally-efficient base-45 is correct and close enough to the actual QR code spec.

[chrismorgan]

I’ve been adding bits to my comment as I went. It wasn’t there when you wrote your comment. I’m stopping now and going to go eat, confused about the 39% and 3% and what’s going on. I haven’t worked with QR codes enough!