[Speex-dev] Recommended version for production use

[Jean-Marc Valin]

> What I've been noticing is that there are vast differences between the way
> certain encoding scenarios sound under 1.1.11 (or 1.1.12, which I've built
> myself) and 1.0.4, the latest stable binary package.  Sometimes it's not
> easy to judge which version's "better"... but the impression I'm getting is
> that the 1.1 branch does not offer consistent (or, frankly, any) quality
> improvements over 1.0.

The main difference you're likely to see between 1.0. and 1.1.12 is that
the later can be (depending on the options) up to 2-3 times faster.
Because the bit-stream is frozen, it's not possible to change the
algorithm itself. Still, the next upcoming version (soon) will have some
quality improvements for low bit-rates. 

> Even without using any of the new 1.1 features such as AGC or denoising,
> files encoded with the 1.1.11/1.1.12 speexenc.exe tend to contain wild
> amplitude-level variations, tonal artifacts, and clipped regions.
> 
> Here's a good example of what I'm talking about:
> 
> speexenc --bitrate 7500 pcm16k.wav speex.spx
> speexdec speex.spx recovered.wav
> 
> If you run these commands with the file
> http://www.speakeasy.net/~jmiles1/pcm16k.wav in 1.0.4, the recovered.wav
> output doesn't sound too bad.  Under 1.1.11, the recovered audio sounds
> terrible by comparison.

I just tried that and figured out why it sounds bad. First thing I
should say is that the --bitrate option picks the highest bit-rate
available that's equal of below the number you set. In this case, that's
5.75 kbps. Now, you are right that 1.1.12 sounds significantly worse
than 1.0.x. There is no reason this should happen and I'll investigate
the problem right away and make sure I fix it for the next version.

> So: what are peoples' thoughts on the best version of Speex to use in
> production code?  Should I incorporate the current stable 1.0.5 source tree
> into my product... or am I making some fundamental goofs in my evaluation of
> 1.1.11?

I think the code in the 1.1.x branch (marked unstable) is overall much
better (cleaner, faster) than 1.0.x but because I make lots of changes,
bugs tends to creep in once in a while (as you just found out). My
recommendation at this point is to use 1.1.x and do a bit more QA to
make sure you're not hit by a stupid bug like you've just seen.

> I've noticed that if I run my test above with --bitrate 10000 instead of
> 7500, the two versions sound much closer.  (I still prefer the sound of the
> 1.0.4 encoder, but the 1.1.1 encoder no longer sounds broken.)  I'd
> appreciate any advice, or corrections to my observations.

10000 is also affected by the bug. It seems like basically all wideband
modes below 20.6 kbps are affected, which points to only a couple dozen
lines of code.

	Jean-Marc