Hi -- I'm looking at adding Speex decoder and encoder support to the Miles Sound System, a commercial library used by game developers on various platforms including PCs, the Mac, and game consoles. As part of my initial evaluation, I've gone ahead and downloaded the 1.0.4 and 1.1.1 Win32 binary distributions and played around encoding and decoding various files with the speexenc.exe and speexdec.exe apps. 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. 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. 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'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. Thanks! -- john RAD Game Tools www.radgametools.com
> 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
> 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.OK, bug found and fixed in svn. Unlike what I originally said, only the 4 kbps narrowband and 5.75 kbps wideband modes were affected. The bug was present since 1.1.7. Jean-Marc
Thanks very much for the quick confirmation on this one, Jean-Marc. I was hoping it was a bug rather than a "feature!" I'll give the fixed version a try. (And thanks for making the package available in the first place -- Speex really scratches a major itch for us, since our current speech-compression solution is an opaque Win32 binary module.) -- john RAD Game Tools> > 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. > > OK, bug found and fixed in svn. Unlike what I originally said, only the > 4 kbps narrowband and 5.75 kbps wideband modes were affected. The bug > was present since 1.1.7. > > Jean-Marc >