I have been trying some different sample rate and bitrate combinations to get a feel for how CELT behaves. I then encoded it with a couple of different frame sizes and sample rates. There were some small differences, but nothing horrible. So, I decided to run with 24KHz sample rate with 16 bit samples. This seemed like a reasonable tradeoff against the quality degradation that my folks could perceive. Then I tried some bitstream rate changes 128Kbps, 64Kbps, and 32Kbps. 128K and 64K are fine. 32K is *terrible*. Really, really horrendous. Is this expected? Is there a program I can run to estimate the error or something? I expected degradation, but this just falls off a cliff with really objectionable artifacts. 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. By the way, celtenc needs some better error messages. If you don't compile celt with "--enable-custom-modes" (which is no longer the default!), trying to figure out why celtenc just errors out no matter what you do is maddening. -a
On 4/14/11 8:35 AM, Andrew Lentvorski wrote:> 32K is *terrible*. Really, really horrendous. > > Is this expected? Is there a program I can run to estimate the error or > something? I expected degradation, but this just falls off a cliff with > really objectionable artifacts.And, of course, I forgot to include the fact that I'm running the latest code out of the git repository. -a
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.> Then I tried some bitstream rate changes 128Kbps, 64Kbps, and 32Kbps. > 128K and 64K are fine. > > 32K is *terrible*. Really, really horrendous. > > Is this expected?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.> 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.> I expected degradation, but this just falls off a cliff with > really objectionable artifacts.In general, good lossy codecs often have a very small bitrate transition zone between "great" and "ugly". Also, a power of 2 is not exactly a small fractional 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. -------------- 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/de1aa7a9/attachment-0002.pgp
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