[CELT-dev] 22 kHz version of CELT
gmaxwell at gmail.com
Mon May 11 09:38:48 PDT 2009
On Mon, May 11, 2009 at 12:13 PM, Marc Padellini
<marc.padellini at gmail.com> wrote:
> I'd like to know the reasons why CELT supports only signals with sampling
> frequency in the range of 32-96 kHz.
> In effect, it can clearly outperform speex at high bitrates, and has
> potential to be used in high quality voice communications even for 11, 16
> and 22 kHz speech signals. It could also compete with SILK codec (to be soon
> released by Skype).
> See this page for more specifications on SILK:
> I don't see any limitation in the current CELT design, though trying to code
> 22 kHz signals with ./testcelt.exe made the highest frequency band
> disappear. Would you know the reason of this ?
> Anyway, thanks a lot for this codec, it looks very promizing,
I'm assuming you made the one-line change to the code to remove the
320kHz lower limit? Or were you just telling testcelt a different rate
than your actual input?
Assuming the former— the reason you lost the highest frequencies is
because if the sampling rate isn't high enough to capture a whole
whole band then the current code simply drops that band rather than
making it smaller.
For a sampling rate of 32000 this behaviour is acceptable as there is
a band edge at 15500Hz. For 22050 this results in a lowpass of
Adjusting the code to reduce/merge bands is someplace on my todo list,
but you can try it easily enough by adjusting bark_freq in
libcelt/modes.c and change the 12000 to 11024 and you should be able
to get the full bandpass of your 22050 signal.
I don't consider supporting lower sample rates a high priority, and if
doing so will ultimately increase decoder size or complexity I'd
suggest we not include it in the specification. However— what we
should do well is support decent quality even at very low bitrates.
How much demand do you see for >16kHz but <32kHz? Going to 16kHz
dramatically improves speech quality, but you really can't get
transparency until ~32000 (especially for music). I haven't personally
seen much advantage for rates between 16kHz and 32kHz for this
Would you really need support for 22050 at 24kbit/sec if CELT could
produce identical results at 44100 24kbit/sec? If your interest is
just in operating at lower bitrates then there is a lot we can achieve
by running at full rate and low-passing internally.
Regarding the SILK datasheet: They are making claims about speex
running at bitrates that speex can't actually run at. I'd take the
claims with a grain of salt. :)
More information about the celt-dev