Three Videos On Codec2 and Open Hardware

Bruce Perens writes "Codec2 is the Open Source ultra-low-bandwidth speech codec capable of encoding voice in 1200 Baud. FreeDV (freedv .org) is an HF (global-range radio) implementation that uses half the bandwidth of SSB, and without the noise. Here are three speeches about where it's going."

• David Rowe: Embedding Codec2: Open Source speech coding on a low-cost microprocessor, at Linux.conf.au 2014. YouTube, downloadable MP4.
• Bruce Perens: FreeDV, Codec2, and HT of the Future (how we're building a software-defined walkie-talkie that's smarter than a smartphone), at the TAPR/ARRL Digital Communications Conference 2013. Blip.tv, YouTube
• Chris Testa on the .Whitebox handheld software-defined radio design that is the RF portion of HT of the Future, which was also shown at the TAPR conference.

Comments

MOS?

[AK Marc]

I wouldn't trust a CODEC I can't even find a MOS for (yeah, I found some independent tests, but they varied wildly).

Re:MOS?

[ajb44]

Feel free to pay to have that done. the algorithmic versions (PESQ, POLQA) are proprietary, and doing it with real people is also pretty expensive.

Re:MOS?

[AK Marc]

So, I have to pay to see if it works? And people wonder why Open Source doesn't take off...

Re:MOS?

[Bruce Perens]

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.

Re:MOS?

[AK Marc]

There are links in Alaska running on radio-phones of very poor quality. But I can't compare the quality of a bad radiophone link to this. I'd love to replace a radiophone system with a packet radio running a lower, but more robust bitrate, but if I can't compare the quality at a glance, I'll never get a business case approved to even evaluate it, let alone implement it. Not all telcos are made out of money.

Re:MOS?

[Bruce Perens]

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.

Re:MOS?

[AK Marc]

That's a "radio link" but not a radiophone. I also don't have any radio phones on hand to test with. They are licensed devices, and the cost to test is $1000+ (as I'd have to fly to get to where the license is legal). They go long-distance, so can be difficult to test.

Again, not all telcos are AT&T.

Re:MOS?

[Bruce Perens]

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.

NSA Codec?

[Anonymous Coward]

I wonder if this is the codec that the NSA uses when it records all audio from all internet connected microphones?

Re:NSA Codec?

[Bruce Perens]

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

Re:NSA Codec?

[Lije Baley]

My dirty napkin says that's about 15 seconds of encoded audio per printed page. Now all I need is a smartphone app which takes a picture and plays back the audio. VoilÃ, a hot useless gift idea for Xmas 2014!

Re:NSA Codec?

[Bruce Perens]

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

Interviews at #lca2014

[Anonymous Coward]

I interviewed David Rowe during #lca2014 last week as well as many other speakers and attendees.

http://goo.gl/jhnefC

Onno VK6FLAB

Code2 voice sample @4:50

[bill_mcgonigle]

http://www.youtube.com/watch?v=u4svoub6XcE&t=4m50s

This is pretty neat. Some high school friends and I were attempting to get voice working over 2400 baud c. 1990 (we wanted Internet phones). We never even came close, and thought we'd have to do phoenmic deconstruction to get that kind of data rate. This is pretty amazing for 1200 baud, even if it is almost 25 years later.

Re:Code2 voice sample @4:50

[CastrTroy]

Would be if people used this for podcasts, Or if they just realized that they don't need to use 320 kbps stereo MP3 for their talking only podcasts. I don't really care about this when I'm at home, but most of the time I download my podcasts directly onto my phone. Using smaller formats means I can download it faster (I usually don't updated until I realize that I want to listen to something), and that I can store more stuff on my phone for listening to it later. It's kind of annoying when podcast creators end up generating a 120 MB file for 60 minutes of audio. I've seen decent quality podcasts use 1/10 of that.

Re:Code2 voice sample @4:50

[Anonymous Coward]

300bps seems to be the current state-of-the-art for decent quality speech coding, but it takes the very latest hardware to manage it and the latency isn't so great (120ms)

Re:Code2 voice sample @4:50

[Bruce Perens]

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.

Latency?

[afidel]

How does it handle latency? I was interested in FreedomPop since the cost was so low but the latency and jitter of 3G data networks caused it to be completely unusable and they were supposed to be using one of the better VoIP codecs for the conditions.

Re:Latency?

[stevew]

I've used codec2 daily in the ghpsdr-alex branch for controlling SDR over Linux remotely.

It is deployed on the Android App glSDR that you can find in the Android Market.

The app provides a GUI with spectrum & waterfall along with Audio from the radio being controlled. Codec2 is used to provide a low-overhead transport that survives the Internet quite nicely.

I've used the app with my 4G phone quite successfully.

Now to the question of latency. When I connect to my own radio with a real-time playback PLUS the codec playback running at the same time, there is a fraction of a second delay - perhaps 100ms-200ms at a guess.

So bottom line is there are real applications for Ham Radio already deploying this technology.

KA6S

Re:Latency?

[stox]

glSDR is awesome! Thanks for mentioning it. Now off to build a dspserver. ;->

KC9KBP

from codec2.org

[viperidaenz]

The way that current digital voice products for Radio Amateurs encode voice signals to digital bits is both trade-secret and patented.

Excuse me, but if something is patented, how can it be a trade secret?

Re:from codec2.org

[Anonymous Coward]

The way that current digital voice products for Radio Amateurs encode voice signals to digital bits is both trade-secret and patented.

Excuse me, but if something is patented, how can it be a trade secret?

You patent the abstract mathematic basis of the compression, thereby making it as hard as possible to make a competing product; while you are also keeping the practical methods you use to implement the mathematics at a reasonable speed and the actual format of the bitstream a trade secret, thereby making it as hard as possible to make a compatible and/or open-source product. Patents don't have to contain a description of a complete product.

Re:from codec2.org

[CanHasDIY]

Perhaps they are referring to different products, some of which are patented, others trade secrets.

Re:from codec2.org

[Bruce Perens]

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.

Transcode

[tepples]

Using smaller formats means I can download it faster [...] and that I can store more stuff on my phone for listening to it later. It's kind of annoying when podcast creators end up generating a 120 MB file for 60 minutes of audio.

Consider using a quad-core CPU to transcode 320 kbps MP3 to 64 kbps Vorbis. Divide the recording into four parts and run one part on each core. Then you can store the four parts on your phone without using too much internal storage. It won't solve your download time or monthly transfer cap problem, but it will help you work around phone makers' tendency to cut out microSD slots and mark up internal storage at highway robbery prices.

Re:Transcode

[hairyfeet]

Uhhh...where is he gonna get a phone that will actually play the resulting 64kbps Vorbis? Like it or not while most phones will play MP3 from what I've seen very few will play Vorbis and while most phones have hardware MP3 decode to cut down on battery usage Vorbis is strictly CPU decode which will end up costing more in battery life.

I'd say he'd be better off encoding to 128kbps MP3 or simply investing in a bigger microSD, not like you can't get those cheap nowadays.

Re:Transcode

[chowdahhead]

All Androids by now have native Vorbis decoding libraries. It's software-based, but if I recall correctly, the battery life is about the same for mp3 and vorbis. Neither codec is ideal though, because podcasts are mainly speech. Speex or Opus (ideally) would be better and VLC will play those just fine.

1200 bits/s, not bauds.

[Moskit]

Even codec2 authors wrote "1200 and 2400 bits per second".

Nowadays with QAM64/256 and other modern techniques one symbol is not equal to one bit, and 1200 baud can be many times more bits/second.

Already in 1990s V.32 standard transmitted 4800 bits/s over 1200 baud line, using symbols with 4 bits.

Come on, this used to be technology geek site.

Re:1200 bits/s, not bauds.

[ArcadeMan]

To put things in perspective for the new-ish Slashdot readers who aren't nerds at all, this means 1200 bit per second, 150 bytes per second or 0.146484375 KiB per second or roughly 870 times smaller than a typical 128kbps MP3/AAC file.

Re:1200 bits/s, not bauds.

[ArcadeMan]

Or maybe I messed up somewhere and 128kbps divided by 1.2kbps is 106 times smaller, not 870.

Still very impressive, unlike my math.

Re:1200 bits/s, not bauds.

[ArcadeMan]

I.E. that means 1 hour and 56 minutes of audio in a 1 MiB file.

Re:1200 bits/s, not bauds.

[Bruce Perens]

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.

Re:1200 bits/s, not bauds.

[Moskit]

Thank you for taking time to reply and adding interesting information!

Regardless of bauds/bits (and 1200 bits/s is more impressive than 1200 baud), Codec2 is a very interesting development in voice area. It also demonstrates how much has changed on endpoints when it comes to processing power and capabilites, while bandwidth (that in Hz and that in bit/s) still remains limited.

Dubious application in VoIP

[janeuner]

The typical VoIP packetization interval is 20ms. At their highest bitrate, you would be transmitting 48 bits (or 6 bytes) of data per packet.

However, RTP packets have 54 bytes of overhead, and 20ms of G.729 is 20 bytes. Switching from G.729 to codec 2, the net bandwidth would only be a 19% decrease in bandwidth. For comparison, the last widespread codec change (G.711 to G.729) was a 65% decrease in bandwidth. It would be a much harder sell.

On the other hand, VoIP could use the bandwidth for redundancy; perhaps a moving window of 60ms every 20 ms to protect against single packet loss. It could happen...

Re:Dubious application in VoIP

[Bruce Perens]

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.

Decoding Vorbis is drop in bucket

[tepples]

where is he gonna get a phone that will actually play the resulting 64kbps Vorbis? [...] he'd be better off encoding to 128kbps MP3 or simply investing in a bigger microSD

No iPhone has a microSD slot. So unless and until Windows Phone or BlackBerry becomes popular again, pretty much any phone with a microSD slot is going to ship with Android. And as chowdahhead pointed out, every Android device I've owned going back to 2.2 has come with a Vorbis decoder.

Vorbis is strictly CPU decode which will end up costing more in battery life.

MoonShell and Guitar Hero On Tour run 67 MHz ARM9 (ARMv5) CPU of a Nintendo DS, and they decode Vorbis in real time. With the higher clock speed and signal processing instructions of the processor in a modern phone, CPU use of a Vorbis decoder would probably be a drop in the bucket compared to things like the cell and Wi-Fi radios, the screen, and even the headphone op-amp. The Settings > Battery report on my Nexus 7 tablet consistently shows two-thirds of energy spent on Screen.