How about a smartphone app that encodes steganographic audio in your photographs? If you upload your photos, the spies get your audio too!

You could do this using FRS walkie talkies, as long as they have microphone and earphone connections. Or analog telephones. It's been tested multiple times on ham FM walkie talkies. Anything that carries voice should work. The bandwidth is only 1.25 kHz and I think the low end starts at about 700 Hz.

There is a video of the codec vs. SSB on the same radio link here. You can also take any radio links you have at hand and run the FreeDV program. This is an evening project to set up without a business case, and at least some companies appreciate people who take the initiative to do this sort of thing.

I can get the soundrack of your entire lifetime on a 32G micro-SD card.

Since I did this talk, a lot of information about AMBE has been revealed and there is a receive-only implementation in Open Source. The patents in general run out by 2015. But AMBE is still a relatively low-performance codec compared to ours.

Sorry. When I say "1200 Baud", I am in general thinking of the TAPR TNC 2, which was never built for voice but can do it, to a degree, with this codec. It's sort of a Bell 212 modem on half-duplex radio. There were many commercial products based on the TNC 2 design and many hams have them on hand. It's a good demo to put speech through a pair of them, not really practical because the latency is high.

MOS is only for people who want to pay a lot of money. Of the automated processes, the one available to us isn't validated for less than 4K bps codecs.

It would be a great improvement to MOS if there was an open version of POQLA. But the actual customer base for the codec have never even heard of MOS and thus we aren't volunteering to write that. The folks who want to put it in expensive government support systems yet aren't willing to help with testing don't get our sympathy.

Correct. It's made for radio, and indeed you need to go connection-based rather than datagram-based to keep the header overhead smaller than the payload.

We avoid some techniques that would make the noise performance worse. The HF version of the codec doesn't vector quantitize, and doesn't do any delta coding between frames. The current FEC is Golay and we are investigating low-density parity codes.

There is a lot yet unheard about the Ratheon codec, regarding its actual noise performance and how well the listener can distinguish different speakers.

Hi.

the Nyquist limit of the audio sampling hardware of a cell phone over instruction rate of a modern CPU is a pretty small fraction.

The "audio" in question is most likely all below 24 kHz, that being the Nyquist limit for the 48 kHz sampling hardware, unless it happens that some phones can actually sample faster, and have microphones that can respond to higher frequencies.

The instruction rate of the CPUs in question is many times that frequency.

It doesn't sound likely.

Using multiple cores turns out to help the attack (by shifting down the signal frequencies).

Say what? Through what mechanism would multiple cores shift down the frequency? And what about parallel instruction streams contributing to noise?

First, you'd need a GPG port to Commodore 64.

TEMPEST was a details-secret government requirement meant to defeat means of eavesdropping on classified computer data from its electromagnetic emissions. I guess they need to include audio too.

My impression is that the noise comes from the power supply, not the CPU. I can certainly hear it with some computers, and it is related to work on the video card in my experience. I'm astonished that you can actually pull data from that, and in fact I'd like to see independent confirmation before I believe it.