Codec2 — an Open Source, Low-Bandwidth Voice Codec 179
Bruce Perens writes "Codec2 is an Open Source digital voice codec for low-bandwidth applications, in its first Alpha release. Currently it can encode 3.75 seconds of clear speech in 1050 bytes, and there are opportunities to code in additional compression that will further reduce its bandwidth. The main developer is David Rowe, who also worked on Speex. Originally designed for Amateur Radio, both via sound-card software modems on HF radio and as an alternative to the proprietary voice codec presently used in D-STAR, the codec is probably also useful for telephony at a fraction of current bandwidths. The algorithm is based on papers from the 1980s, and is intended to be unencumbered by valid unexpired patent claims. The license is LGPL2. The project is seeking developers for testing in applications, algorithmic improvement, conversion to fixed-point, and coding to be more suitable
for embedded systems."
what about LATENCY? (Score:4, Interesting)
i assume it's acceptable... but it angers me that someone thought it was relevant to give the exact number of bytes for a seemingly arbitrary 3.5 seconds of audio, but failed to say how long it take to encode that 3.5 seconds of audio, or what average latency can be expected after buffer conditions are met.
Serindipidy. (Score:3, Interesting)
Re:what about LATENCY? (Score:2, Interesting)
also, considering the advantages of using lower bitrate voice codecs, the ability to implement the encoder and decoder algorithms directly in very low transistor count custom hardware would appeal to the same crowd... so not just latency in terms of x86 instructions per second, but the ability to implement those instructions in hardware.
i am concerned about bruce's use of the term "real time"... either he is implying there is no noticeable latency to him, (which is irrelevant to me as numerous others claim skype video chat is "real time", and also impossible given the implicit time consuming process of encoding), or he's cleverly stating that the time it takes to encode is the real time it takes to encode. it's not the fake time. it's real time.
again, i assume, and it seems i'm correct to do so, that the codec is "very usable"... i won't be trying it as i have no need for it.
Re:Great news (Score:5, Interesting)
Re:what about LATENCY? (Score:2, Interesting)
why not refine the a DSP chip architecture until it works well with the original codec? i know masks are expensive... but why not do it all the way?
Packet loss? (Score:4, Interesting)
I didn't see it mentioned when quickly scanning TFA, but how does this codec handle packet loss?
It is all nice and well to develop a codec to cram as much speech as possible in as few bits as possible, but in this case, one lost packet could mean a gap of several seconds. The success of a low-bandwidth codec, at least when it comes to IP telephony, also depends on how well it can handle lost packets. Low bandwidth codecs are usually used in low bandwidth networks, such as the internet, and there the packetloss is the highest.
Same goes for delay and jitter, by the way. If a stream of packets is delayed, and more voice is crammed in fewer bits, then the delays in the voice stream will get longer too.
Re:Original Rationale (Score:3, Interesting)
Looks really cool. I haven't messed around with D-STAR since I don't like the idea of being tied into a specific system (seems to contravene the point of amateur radio). I'll definitely be keeping an eye on this to see where it heads.
I had a really awesome idea just now for transmitting this at 1200bps using AFSK Bell 202 (like APRS) and hacking up live voice using entirely existing equipment (TNCs, etc). But the given example of 1050 bytes/3.75s works out by my math to 2240bps. I guess you could run it over 9600bps packet, with room to spare (text chat?)
73,
KC2YWE
English only ? (Score:5, Interesting)
Mumble integration ? (Score:4, Interesting)
One of the fastest ways to ensure its testing and distribution is to use it in Mumble - the low latency voice chat software (with an iPhone client as well).
Mumble is typically used by gaming clans for their chat rooms and it Codec2 would be tested in real-life conditions.
Re:English only ? (Score:5, Interesting)
Re:Mumble integration ? (Score:5, Interesting)
Is there an existing Mumble developer whom we could get interested in this? It might be that we should take some of the Alpha-isms out of the code first.
Re:Original Rationale (Score:3, Interesting)
By the way, look over his web site rowetel.com for the other work he's done: two really nice Open Hardware projects - a PBX and a mesh telephony device, an Open Source echo canceler for digital telephony, used in Asterisk and elsewhere, and his own electric car conversion.
I've got one of his little ip01 telephony boxes, and it is quite fantastic - a tiny, cheap, fanless, (embedded) Linux computer with plenty of memory and CPU grunt, and of course telephony hardware on board. It also has a package manager, with a quite a few pieces of software available, and regular firmware updates. It's much more powerful than the various Linux-based consumer routers that are available - it's a great option if you're looking for a small Linux server to run Asterisk, a little web site, DNS server, SSH, etc...
(I'm not affiliate with David or Rowetel in any way - just a happy customer, who is in awe of the amazing things this guy has achieved in such a wide variety of areas).
Re:English only ? (Score:1, Interesting)
One of the earlier observations in this field was that a low-bandwidth filter specifically hurt languages with hissing sounds, and I presume you'd have similar problems with click sounds.
As the GP indicated, Chinese (Mandarin) would be an important addition as it's a tonal language, and compression should not blur that distinction. Languages such as Arabic have emphatic consonants, which aren't that common in Western languages either. But French? That's for all practical purposes identical to English. Finnish would make more sense. As for the click sounds, try Zulu. It apparently has 15 distinct click sounds, and there should be enough speakers online.
How does it handle background noise? (Score:3, Interesting)
Bruce, have you guys done any testing of performance in the presence of background noise? I know that in the PMR area, there are a lot of firemen who are very unhappy with what happens to AMBE when their is background noise (e.g. saws, Personal Alert Safety System, fire) gets into the mike - while AMBE does ok at encoding just speech, throw the noise of a saw in the background and all you get is garbage.
While the initial application of CODEC2 is hams in their shacks with their noise-canceling mikes, It Would Be Nice If the vocoder didn't curl up its toes and die in an noisy environment.
See "Urgent Communications", September 10th edition, page 10, "Round 2 of digital radio fireground tests held" [urgentcomm.com], and the test plan [urgentcomm.com].
Re:Wonderful Name (Score:3, Interesting)
But there it's called AMBE, not Codec. Codec2 is a bad name for a codec for the same reasons that Variable2 is a bad name for a variable. If this is supposed to supplant AMBE, why not AMBE2 or S(uper)AMBE?