Most efficent way to transmit binary data by human voice

Question

Suppose two people want to transmit some binary data (a png image perhaps) by voice.

Two of my characters want to share binary data but they can only use their voice and no other form of communication is possible.

By "voice", I mean any sounds that can be reliably produced and differentiated by average humans.

They can use computers to encode or decode the message but the transfer of information needs to happen between them. For example: They can't use computers to encode the data to sound, play it back and let a computer on the other side record it.

They could do it by pronouncing every single zero and one. ("One, Zero, Zero, One, ..") This is very slow and inefficient though.

Or they could use the hex encoding. ("B, Four, F, Nine, ...") This is better, but there is still more room for improvement.

Perhaps they could use base64 to encode it. ("D, capital G, H, three, ...") But notice how they have to specify capital letters ("capital D"), this lessens it efficiency.

What's the most efficient way to do it?

Answer 1

This problem has been much studied. While it may be difficult to define what 'best' is, there is a very efficient one already in existence, and that's PGP Words. This method was designed for transmitting long binary keys over a voice link, each word encoding a whole 8 bit byte.

It addresses a number of problems you probably haven't thought of, like reliability over a voice link. What happens if a word is missed, or a repetition for clarity is mistaken as an actual repetition or, reading from a long list, two words get swapped?

With 8 bits per word, you would normally require 256 words. The system is more sophisticated than that, and uses 512 words, an 'even' table of two syllable words, and an 'odd' table with three syllables, that are used alternately. That way, a missed or repeated word, or two swapped words, can be immediately spotted as an error.

Here are the first few and last few, from the wikipedia article linked above. The whole table can be printed on a single sheet of A4. They are in alphabetical order to aid the receiver. Obviously the list is optimised for English. Speakers of other languages may prefer a different list.

Hex  Even Word  Odd Word
---  ---------  --------
00   aardvark   adroitness
01   absurd     adviser
02   accrue     aftermath
03   acme       aggregate
04   adrift     alkali
..  ......      .......
FB   watchword  Wichita
FC   wayside    Wilmington
FD   willow     Wyoming
FE   woodlark   yesteryear
FF   Zulu       Yucatan 

Quote from the wikipedia article

The PGP Word List was designed in 1995 by Patrick Juola, a computational linguist, and Philip Zimmermann, creator of PGP. The words were carefully chosen for their phonetic distinctiveness, using genetic algorithms to select lists of words that had optimum separations in phoneme space. The candidate word lists were randomly drawn from Grady Ward's Moby Pronunciator list as raw material for the search, successively refined by the genetic algorithms. The automated search converged to an optimized solution in about 40 hours on a DEC Alpha, a particularly fast machine in that era.

An alternative for a 4 bit nybble per word is simply to use the hex alphabet, perhaps using the ICAO/NATO pronunciation, 'zero' to 'niner' then 'alpha' through to 'foxtrot'. There are more than 16 further letters left if needed for even/odd coding. Whether the complexity of the 512 words needed for doubling the throughput with PGP words is warranted against the simplicity of hex begs the question of how you define 'best', what factors in the setup or operation of the communication are important.

You could get even higher efficiency by using more bits per word. 12 bits would need a 4096/8192 long dictionary. This would sacrifice much of the hard-won inter-word phonetic distance of the PGP scheme, so would require a higher fidelity voice channel, and more careful speakers.

Noting ruakh's comment, it's worth looking at the speed of the channel. His estimate is two seconds per word, which would probably be quite good for untrained users. That's 4 bits/s. If we compare that with Morse code, the minimum speed required by the FCC to grant a radio operator's license used to be 16 five-letter code groups per minute, which very roughly equates to about 8 bits/s.

The difference between the two systems is that Morse Code requires training. I couldn't transcribe Morse, at any speed, without a lot of practice, and probably some tuition as well. Many English speakers could transcribe those words without practice, but what about those with a limited vocabulary, or English as a second language, or speakers of other languages? PGP words is not really training-free, if it's to be used by any human at all. It's only ready-to-go if used by people like those who invented it, educated fluent English speakers, being a programmer would help as well. It's probably a skill that's easier to pick up than Morse though.

With speed in mind, it might be worth reviewing the performance of hexadecimal via ICAO pronunciation. While a word every two seconds would be good going for recording a PGP word manually, I think hexadecimal could be done at easily twice that rate, transcribing as you go, making the bit rate of the two methods equivalent.

Clearly a lot of other assumptions about the training or experience of users, the setup costs, the quality of the audio link, have to be defined before the best system can be determined.

Answer 2

Efficiency means something that is easy/quick to encode, easy/quick to pronounce and understand, and easy/quick to decode. base64 was never made to be read by a human, and saying "capital" every now and then will seriously slow you down. Hexadecimal is slightly better than spelling binaries, but perhaps too short. Seven are two syllables.

• Define 32 (or 64 or 128) short, distinctive words. Which ones depend on the languages and accents of the participants. Cat, Dog, Fox, ... but if Cat is in the list then Bat should not be there, or vice versa.
  The suggestion by the commenter Zeiss Icon to use NPA has merit, but it is limited to 5-bit units. Finding 64 words might be feasible ...
• Assign each word a number.
• Break the binary data into "bytes" of 5 (or 6 or 7) bits, encode and read the words.
• Listen to the words and then decode into "bytes."

It might be a good idea (even if it decreases efficiency) to add a checksum to your transmission.

Answer 3

Choose X syllables, and then base-X-encode your data.

Choose the largest set of syllables that you consider for your purposes to be mutually distinguishable, and then base-X-encode your binary data, where X is the number of syllables you've chosen.

A simple example: suppose we choose only syllables that begin with a consonant, and are followed by a vowel, from the following sets:

{p,k,t,ch,b,g,d,j}

{a,e,i,o,u}.

We now have 8 x 5 combinations, giving us 40 syllables. You can base-40 encode your binary data into a rapid-fire of syllables that would sound something like:

"pagidachotajapikachutagujiko.... "

This example used latin-alphabet letters and assumed a more-or-less standard English pronunciation. To make a more rigorous system, it would be advisable to use the International Phonetic Alphabet to choose the sounds for your syllables and ensure that you avoid phonemes that (1) would be difficult to distinguish from one another and (2) do not lend themselves to fast pronunciation.

Note: This answer is similar to o.m.'s...just "encoding" at the level of syllables instead of words. By customizing your list of syllables to all be quickly-speakable and using every possible combination, I expect this would tend to increase the efficiency of information per syllable. However, if the memory and cognitive processing rate of the average humans using it is taken into account, it's possible (probable?) that o.m.'s word-sequence-based transmissions will be more easily remembered without error.

Answer 4

Sing it

You're thinking too much along programming lines. This is valuable for the sake of compression: but everything else you've mentioned (like hex encoding or base64) is just a way to make binary more consumable by the human eye (and other things).

Frankly, from a programmatic perspective, the only thing you really care about is compression. You want to send as little data as possible to guarantee maximum transmissibility. But other than compression, it doesn't matter how you express your ones and zeros. (It helps to remember the good old days on the Apple II computers where the average geek cared about Assembly Language.)

What you really want to think about is music

If you want the average human to convey ones and zeros, ask them to sing. Generally speaking there are only seven notes — but there are half notes, quarter notes, sharps and flats. Those alone give you 63 notes. Add shifts in octave and you get more. Your average person can span two octaves. Now we're up to 126 notes. 127 with a "pause" (no sung note in the meter of the song). Expand the vocal range just a hair and you get to all 128 positions, allowing you to express every combination of "11111111" or 2⁷.

BTW, I'm not a music expert. I wouldn't be at all surprised that you could express a whole lot more data than 2⁷ with the magnificent expressiveness of musical notes.

From here, it's just a question of mapping notes to binary combinations and, boom, vocally expressed digital data.

Finally, I'm not suggesting that what you get would sound good... only that it could be done.

Answer 5

The best way to communicate binary information long distance by human "vocal" is by a whistle language. The existing whistle languages are used in rough landscapes to communicate longer distances than possible through voice.

In this case, you can have one pitch for one and another for zero (or work up a common set of tones for numbers 0 through 7).

Answer 6

Human speech is astonishingly effective as establishing communication between humans. Not only does it use the vocal chords efficiently, but it uses the language centers of the brain efficiently as well. Our languages have just enough redundancy to support humans.

Accordingly, the best way to have an average human transmit and recieve binary data is to map it to human language. Use an AI to construct an injective mapping between a string of bits and sentences in English (or whatever the native language of your characters is). The result should sound like a typical monologue.

This is almost certainly the most efficient way to communicate a binary string between people. If one side has other tools available , such as a tape recorder, there may be more efficient means But never underestimate the benefits of leveraging a few decades of speech on behalf of both parties.

Answer 7

What you need is a drum. Actually, any old stick and a hard surface to strike it on will do in a pinch, but that limits you to binary data ("hit" or "no hit") and doesn't allow for any out-of-band information such as "end of message". A drum that makes a different sound on sustains (the stick is kept in contact) vs. rests (the drum is allowed to vibrate on its own) will let you have notes of varying lengths which can form more complex codes. Drumbeats can be very fast and accurate, far more than most singers, and can send longer messages without pausing.

For instance, with such a drum, you could have a code of "short" and "long" beats that encodes letters and punctuation; you may know this as Morse code. Or, you could cut to the chase and encode a binary or quaternary (or any other convenient base) number directly as a series of beats.

The advantage and goal here is to keep the encoding and decoding simple, because the limitation is not in the ability of the human body to make noise, but the speaker's ability to figure out which noises they ought to be making. A base-32 or -64 code is more efficient in terms of symbols, but any speed benefit is undercut by the user's own speed in interpreting those symbols as actual sounds.

In contrast, using only three symbols (short, long, and silence), Morse code is a proven example of encoding and decoding a message, by human operator, in real time. So it makes sense to investigate the area of low-density but high-speed communications to make most efficient use of the human part of the equation.

Answer 8

I'd encode the binary to a huge lookup table of values and concepts, link these concept and values to phonemes that are easy for the human vocal apparatus to process, and for the human ear to hear.

Group these sounds into more complex structures, for improved bit density.

Ideally, I'd assign some contextual meaning to these complex structures of phonemes, to ensure greater ease of comprehension, and cut down on the error rate when producing them. There would be intricate rules regarding juxtaposition of these structures, disallowing obvious errors. We might need to make lookup tables of these structures, as an aide to learning and for error-checking.

Of course, the art of learning such a highly complex and convoluted data pattern will need to commence from childhood, and continue throughout adult life.

For convenience, we will call this convoluted binary-encoded-as-phonetic-sounds-in-structured-groups-with-contextual-meanings an easier name to identify it.

How about "English"?

Answer 9

I suggest combining the best of o.m.'s accepted answer and JBH's suggestion of singing, to use a spoken tonal approach. Many people use languages in daily life that rely on tone for meaning, so your "average person" may well be able to.

Tone isn't usually employed in English, but combining even a simple high-low distinction, which pretty much anyone can do, with the NATO alphabet's 36 characters gets you 72 distinct values (or 6 bits if you want simpler mapping). I reckon this is optimal for a pair of English speakers with no training.

Three tones (high-mid-low) gives you 108 values (more than enough for something based on ASCII85), but if you can use rising and falling tones too, you get 36×5=180 values. Some Chinese dialects use even more. Unless mapping bits to vocalisations has to be done by people using a look-up table, you don't need your unique vocalisations to add up to a power of two, as demonstrated by ASCII85. The more tones used, the more training will be required, at least if your speakers aren't used to it.

Cooking up a new phonetic alphabet using only one- and two-syllable words is probably helpful for efficiency. Of course you could discard the mapping to the alphabet, but that mapping does makes transcription easier (tone markers will be needed).

You should consider the fidelity of the channel - a quiet room, across a deep gorge with a noisy river, a telephone line, a party, etc. will have different characteristics. Some will need a wider distinction between sounds than others. Only in the quietest settings could volume be used as another variable.

Running some numbers on the rate using simple mappings (i.e. rounding the number of unique sounds down to a power of two): English speech is apparently around 4 syllables per second. Using simple mappings, with 6 bits over two tonal variants of the two-syllable A-Z0-9 alphabet, you'd get 12 b/s. With 5 tones rounded down to 7 bits, but upping the rate to a still-reasonable 6 syllables/second you're now at 21 b/s. Pushing it further, if you can come up with 64 distinct single-syllable words and can manage to apply 4 tones to those sounds you'd get 256 values per syllable, or a grand total of 32b/s. Don't forget to breathe.

Answer 10

There are approximately 470k English words. $\log(470000)/\log(2)$ yields 19 bits per word. Good luck teaching kids all English words and their binary counterparts as well.

At that point, it might be easier to create 256 "words" at 1 byte per word. Words that are syllabically short and enunciated carefully. You could likely do 1-syllable each, so, "cabagathadedodunit", where each syllable is a 1-byte value "word". That string would yield 8 bytes or 64 bits.

If you think your kids are just really damn smart, you could bump that up to 65536 words stowing 2 bytes per word with more syllables per word, but that presents a much greater error risk.

Answer 11

Morse code may be voiced or whistled. Computers can turn the binary data into letters (base 26, or perhaps a lower base by dropping the longest morse codes.)

Those who train, gets their morse up to 60 wpm or so. The average word is about 5 letters. So 300 letters per minute, each encoding 4.7 bits. 1410 bits per minute, or 23.5 bps. Well, that is for morse using equipment. I found no data for voiced morse.