[CELT-dev] Bad artifacts at 32kbps

[Andrew Lentvorski]

On 4/14/11 8:58 AM, Benjamin M. Schwartz wrote:
> On 04/14/2011 11:35 AM, Andrew Lentvorski wrote:
>> So, I decided to run with 24KHz sample rate with 16 bit samples.
>
> Depending on how you set the sample rate, this could be a problem.  It
> might be good to post how you invoked the encoder.  You might find that
> 48KHz performs better, even if you know your audience won't hear the top
> frequencies.

I'm not quite sure I understand.  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.

> For mono at 20ms frames, no.  32Kbps is not enough for transparent
> 48KHz-samplerate mono audio, but it should be pretty good.  For stereo
> 32kbps is going to sound crappy.  For shorter frame sizes it is also not
> so good.

Yeah, it seems that I trapped myself with the frame size.  I was pushing 
around 120 (5ms packets) and it was terrible.  When I bumped it back to 
480 (20ms packets) it's okay (not great) again.

I'm sorry, I don't really understand what all the knobs do, yet.

For reference, here were my commands:
celtenc -V --framesize 120 --bitrate 32 ./marlene-24-16bit.wav 
marlene-24-16bit--frs120--br32k.oga
celtenc -V --framesize 480 --bitrate 32 ./marlene-24-16bit.wav 
marlene-24-16bit--frs480--br32k.oga

>> 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.

>> My application is going into the embedded space, so I'm quite a bit
>> resource conscious.  It's not that I couldn't live with 64kbps, but
>> every factor of 2 helps.
>
> You may want to try changing by smaller factors.

However, I suspect that changing by smaller factors doesn't buy me 
enough back in terms of resource usage.

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.

My next task is to plow through the code and take a look at how the 
buffers are allocated and/or passed around.


Thanks for the advice.  It was really useful.

-a