Skip to main content
Topic: Codec2 (Read 19436 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Codec2

I was wondering, if someone has already played around with Codec2 by David Rowe.

The codec delivers impressive quality at 1500bps. I wonder what container I should use for archiving, as I don't have an interactive software that uses Codec2 right now. I wonder how I can run some tests with it, as I don't know of any decoder software right now.

Anyways, would be nice to know if this actually got any public exposure at all.

Codec2

Reply #1
The latest codec2 2000 bps produces the same quality as G.729 8000 bps (the second most used codec in basic telephony) and close to AMR-NB at the same 8000 bps.
It means it has a real-life telephone quality just at 2000 bps.  4x times more efficient than G.729 .  Now, that's impressive.

Codec2

Reply #2
Still under heavy development. So, talk about archiving or any serious deployment is still early IMHO.

This might interest you, from the Opus/CELT guy:
http://jmspeex.livejournal.com/10446.html

Codec2

Reply #3
Well I certainly know Codec2 is early development. Then again, Opus isn't quite finished as well...

Since both don't have minimal bitstream containers, and they're not supported in any existing container, it's quite difficult to do some exemplary testing. All I know, is that it looks really promising, and all. I just wish, development would hurry up a little.

Codec2

Reply #4
Well I certainly know Codec2 is early development. Then again, Opus isn't quite finished as well...

Since both don't have minimal bitstream containers, and they're not supported in any existing container, it's quite difficult to do some exemplary testing. All I know, is that it looks really promising, and all. I just wish, development would hurry up a little.


You can test Codec2:
http://www.rowetel.com/blog/?page_id=452#quickstart

Just look at the script dir and replace the included test files with your own.

Opus is ready(1) from a technical POV. It's just stuck in bureaucratic and legal bullshit. It already has container support(2) ,  reference encoder/decoder tools(3) and even an excellent (even if flagged experimental) TVBR mode in the reference codec(4).

(1) https://www.ietf.org/mail-archive/web/codec...t/msg02826.html
(2) https://wiki.xiph.org/OggOpus
(3) http://git.xiph.org/?p=users/greg/opus-tools.git;a=summary
    http://git.xiph.org/?p=users/jm/opus-tools.git;a=summary
(4) http://git.xiph.org/?p=opus.git;a=shortlog.../heads/exp_wip4

Codec2

Reply #5
...and even an excellent (even if flagged experimental) TVBR mode in the reference codec(4).

It's actually on alpha (if not pre-alpha) stage and hardly usable.

Codec2

Reply #6
...and even an excellent (even if flagged experimental) TVBR mode in the reference codec(4).

It's actually on alpha (if not pre-alpha) stage and hardly usable.


Hate to go offtopic. But, In what sense is it hardly usable?

Codec2

Reply #7
Have You actually tested it to call it an excellent? I have and my findings are different.

It's an experimental, not for use.

Codec2

Reply #8
Have You actually tested it to call it an excellent?


Yes (exp_wip4 not before). But not with killer samples. So, I will take your word for it.

Codec2

Reply #9
Well, What I mean is, suppose I'd like to encode into Ogg/Opus, I'd like an encoder like oggenc for instance. Things like ffmpeg are a bit slow in development these days, though.

Since it is practically a given, that Opus will be contained in Ogg, I have two questions: What encoder should I use to encode in Ogg/Opus, and does Opus support a minimal bitstream container, like FLAC.

Now, this is just for Opus, but the real questions are about Codec2. Basically, what container will it have, if it is gonna have one at all? A minimal bitsream container, maybe? The demo encoders aren't really that nicely usable. For plain demo purposes it's OK, but I can't really do practical tests with it, since I don't even know a decoder for it (or in that sense, a Codec2 player...).


Codec2

Reply #11
I looked through the whole conference video. I understood somewhat of what was explaind and I enjoyed the geek talk a lot. Now I wish I had the skills to program audio codecs (and effects). Thank you for the link. Regards.

Codec2

Reply #12
Hi, I hope you don't mind me resurrecting this old thread, but I think it's better than opening a new one.

I've seen people doing some voice chatting with the c2qso.sh shell script. Other than that, I'm waiting for the very low bitrates (1400bps and 1200bps), to reach maturity. I'd still like a container "endorse" Codec2, I see how it introduces a very large amount of overhead, but for things like audio books or even just recorded voice communications, a container would be nice. I wouldn't mind using Ogg/Codec2...

As an interactive codec, Codec2 has no immediate necessity for a container, but at the same time recording those (long) communications in a different codec, in a different container, is just dumb...

This may be a wrong place to bring it out, but remember Speex /can/ be contained in Ogg. Although -- on a personal note -- naming the tools went completely overboard: oggenc for Ogg/Vorbis with .ogg extension, and opusenc for Ogg/Opus with .opus extension. Anyway, I don't see why Codec2 shouldn't be contained in Ogg or some other container.

I was thinking of using a Raspberry PI as "encoding device", or even two of them as a test bed, a bit like a tin can telephone.

Codec2

Reply #13
As an interactive codec, Codec2 has no immediate necessity for a container, but at the same time recording those (long) communications in a different codec, in a different container, is just dumb...
This may be a wrong place to bring it out, but remember Speex /can/ be contained in Ogg. Although -- on a personal note -- naming the tools went completely overboard: oggenc for Ogg/Vorbis with .ogg extension, and opusenc for Ogg/Opus with .opus extension. Anyway, I don't see why Codec2 shouldn't be contained in Ogg or some other container.
I was thinking of using a Raspberry PI as "encoding device", or even two of them as a test bed, a bit like a tin can telephone.
AFAIK Codec2 is far from done, ... not great to fix a bunch of things in files before its done.  Putting it in Ogg would be utterly trivial and a fine thing, though I don't know how necessary it would be given that codec2 is CBR so you can even do accurate seeking without a container.

With 1 second per page and 20ms packets the overhead would be 2248 bits per second. If you permitted multiple frames per packet (e.g. put he CBR rate in the header) then 1 second pages would let you have 224 bit/sec overhead... which is probably acceptably small considering you get error detection out of it.

 

Re: Codec2

Reply #14
It's time to resurrect this thread once more: http://www.rowetel.com/?p=6212

Codec2 at 450 bit/s
Quote
Thomas Kurin is a Masters student at the Institute of Electronics Engineering, part of the Friedrich-Alexander University Erlangen-Nuremberg. Thomas and his supervisor Stefan Erhardt recently contacted me with some exciting news – a version of Codec 2 running at 450 bit/s, including a 16 kHz mode!

I won't link to the samples directly, because this might not be in David Rowe's best interest, however I'd greatly suggest you have a listen.

The details how that ultra-low-bitrate codec has been achieved, are further down in that article, it is quite impressive.

Especially the 16kHz mode, which extracts extra legibility purely on the decoder side.

In case anyone is interested in the original, uncompressed samples, some of them can be found here: http://www.rowetel.com/?page_id=452 and the others are available with the source code of Codec2. I'm pretty sure it's alright to link to them like this: http://svn.code.sf.net/p/freetel/code/codec2-dev/wav/

I guess it's pretty obvious I'm quite a big fan of David Rowe's work. I've been following his Codec2 development for many years now. While it sometimes seems that the project is slowing down, every now and again, it basically leaps forward like it did just recently.

I'm wondering how well up-scaling from those low bitrates would go. Digital mobile radio, like DMR or TETRA is pretty lackluster right now, when it comes to speech clarity.

 
SimplePortal 1.0.0 RC1 © 2008-2018