Exactly. CELT at 2.5kbit/sec: http://myrandomnode.dyndns.org:8080/~gmaxwell/celt/16k_60ms_20-2.wav http://myrandomnode.dyndns.org:8080/~gmaxwell/celt/16k_60ms_

Exactly. CELT at 2.5kbit/sec: http://myrandomnode.dyndns.org:8080/~gmaxwell/celt/16k_60ms_20-2.wav http://myrandomnode.dyndns.org:8080/~gmaxwell/celt/16k_60ms_... So sure, CELT can be coerced to run at obnoxiously low rates— it's far more flexible than MP3 in this regard, every frame size which is an integer number of bytes greater than 8 or so should more or less work (and it should use every bit effectively). This doesn't mean that it'll actually be useful at very low rates. 32kbps is about the limit for 20ms frames where things really start to come apart and everything starts sounding pretty poor. The CELT _decoder_ is more computationally complex than you might guess. We started the design in 2007, and the decoder is pretty comparable to MP3 or Vorbis decoding (though requiring a _lot_ less memory). Using substantially less CPU than that, if there was quality to be gained would have been a sin. So although the overall design is nice and simple— we use a number of 'more optimal' techniques which are decent CPU sinks. E.g. Everything is range coded (so we're not constrained to coding things with probabilities of the 1/2^n form) and we use high dimensionality vector quantization. The encoder, however, doesn't need a psy-model at all nor does the current one have much of a psy-model (it has some simple hacks for a couple psycho-acoustic tweaks, but nothing too complex) Reasonable perceptual performance is implicit in the format. This means that a good CELT encoder can be much faster than, say, a good vorbis encoder. On the subject of DSP stimulating curiosity, checkout http://www.xiph.org/video/ http://www.xiph.org/video/