[CELT-dev] Bad artifacts at 32kbps

[Benjamin M. Schwartz]

On 04/14/2011 12:39 PM, Andrew Lentvorski wrote:
> My source is (eventually) going to be a
> stereo audio codec chip.  So, who/what is running at 48KHz?  I really want
> to run the codec chip as slow as possible as transferring data just to
> dump it is not a win.

OK.  Many audio chips only do a fixed samplerate (like 48 KHz), but if
yours can really do 24 KHz then that's perfectly reasonable.

The issue I was alluding to is that CELT is tuned for 48 KHz operation,
and other samplerates (i.e. the "custom modes") have received much less
attention, which is part of the reason they're disabled by default.

There are essentially 3 ways to use CELT on a 24 KHz input:

1. Run the codec at 24 KHz. (Least CPU)
2. Run the codec at 48 KHz and upsample the input.  (Most CPU)
3. Run the codec at 48 KHz, but include a signal that the input was
actually 24 KHz sampled, so higher frequencies are ignored. (Best Quality)

Unfortunately Option 3 is not exposed by the celtenc tool ... but it _is_
exposed by the opusenc tool, as -bandwidth SWB. See

http://git.xiph.org/?p=users/jm/ietfcodec.git;a=blob;f=README;hb=HEAD

for details.  (Opus includes CELT, and is expected to replace it.)

>>> Is there a program I can run to estimate the error or
>>> something?
>>
>> A good first step would be to post some decoded samples.  The type of
>> artifact may identify a problem.  There are also tools like PQEvalAudio,
>> but that is probably overkill.
> 
> Um, that's something I really needed.  Thanks for the pointer.
> 
> Although, it doesn't seem to be tuned very well for CELT.  There is a
> large jump in degradation while it only flags a very slight difference
> grade change.

Our results generally look like pages 24-27 of
http://www.ietf.org/proceedings/80/slides/codec-4.pdf

Whether your ears agree ... well, that's a matter of opinion.  PEAQ is far
from a perfect measure.

> Bandwidth isn't really my limitation.  Local RAM and processor MIPS are.
>  Consequently, I'm trying to twist the knobs in ways that cross the
> power-of-2 boundaries that will allow me to tighten resource usage.

OK.  If you're that crazy then you can do things like choose a power-of-2
framesize (e.g. 512 samples at 24 KHz -> 21.33 ms), substitute your own
platform-optimized FFT lib ... or find some optimizations (C or assembly)
and send us patches.

Good luck.

P.S.  Don't forget about the encoder complexity setting, if you want to
trade speed for compression in the encoder.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.xiph.org/pipermail/opus/attachments/20110414/ec3677b0/attachment-0002.pgp