Speex dev - Aug 2004 - Speex test cases?

I'm trying to get speex to encode a bit faster, mainly by rewriting a few
functions in SSE and translating the GCC __asm__ to VC __asm.

There's 2 functions I'm targeting, first is vq_nbest which consumes 40%
of
the time at high complexity and split_cb_search_shape_sign. Which consumes
just over 30%. I've split out two functions from:

cb_search_precompute_energy - loop at the comment:
        /* Pre-compute codewords response and energy */
cb_search_update target - loop at the comment:
        /* New code: update the rest of the target only if it's worth it */

These functions represent 1/2 of the compute time at complexity 10 and 4/5
at complexity 4.

The next hot functions at low complexity are: qmf_decomp, fir_mem_up and
pitch_gain_search_3tap

Some questions I have:

1. I haven't been able to get the version of iir_mem2 in filters_sse.h
translated and working. Does this work with GCC, I'm burning my eyeballs
trying to spot the difference in my version.
2. I don't have a good source of wav data for testing. I've noticed that
introducing bugs into speex (even gross ones like returning completely
incorrect codebook entries) tends to, sometimes subtly, degrade quality
instead of blowing up. Is there an existing set of source data - and maybe
even a test harness that will do binary comparison, so I can avoid writing
one?
3. I noticed the idea of a fixed-point version of speex on the webpage, what
kind of performance difference is expected from that and are the value
ranges already known?

Thanks,

John

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'speex-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Hello,
> 2. I don't have a good source of wav data for testing. I've noticed
that
> introducing bugs into speex (even gross ones like returning completely
> incorrect codebook entries) tends to, sometimes subtly, degrade quality
> instead of blowing up. Is there an existing set of source data - and
> maybe even a test harness that will do binary comparison, so I can avoid
> writing one?
I don't have answers to 1 or 3, but on the issue of good test data, I've
been doing a bunch of testing. My best source of test data is System Shock
2, the video game. It includes 177 MB (4.3 hours) of speech WAV files in
16kHz IMA ADPCM format by various types of voices (male, female, noisy,
sharp, robotic, organic). Using a shell script and sox, I was able to
compress it down to 17 MB using 16 kHz wideband, variable bit rate,
quality 8 with release candidate 1. It definately isn't lossless, but
it's very good. If you'd like a few of these wav files to test
(100k-300k
each), I can put a few on my web server.

My second source of data is my own microphone. Using sox, and a good
topic, I can rant for hours. sox can either save to wav, au, GSM,
SPHERE, IMA ADPCM, u-law, A-law, or other more established codec or it
can pipe it to speexenc. The script I made for on-the-fly compression is:

  sox -t ossdsp -r 8000 -b -s -c 1 /dev/dsp -t wav -r 8000 -s - | \
  speexenc -n --quality 8 - test.spx

You can replace 8000 with 16000 or 32000 and n with w or u to test
wideband and ultra-wideband.
And to save a lossless copy in wave format to compare, simply:

  sox -t ossdsp -r 8000 -b -s -c 1 /dev/dsp test.wav
  speexenc -n --quality 8 test.wav test.spx

Hope it's a bit of help on the testing side. My preliminary assessment of
Speex is: sweet. If you need someone to test specific things, I would be
happy to. While my coding knowledge is more at the application level
(programming 3d games and user apps specifically), I'd like to help if I
can. I plan to use Speex in the near future, so I'd like to help make
it better.

Btw, has anyone else noticed that the Speex XMMS plugin is missing? While
speexdec works well, I'd kinda like to use XMMS.

Best Regards,
Joel R. Voss
http://javantea.com/

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'speex-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Le dim 09/02/2003 à 21:50, John Hayes a écrit :
> I'm trying to get speex to encode a bit faster, mainly by rewriting a
few
> functions in SSE and translating the GCC __asm__ to VC __asm.
Keep in mind that the SSE code is still experimental, even more so for
wideband. I'd suggest you first make sure you can get it to work
correctly under Linux.
> There's 2 functions I'm targeting, first is vq_nbest which consumes
40% of
> the time at high complexity and split_cb_search_shape_sign. Which consumes
> just over 30%. I've split out two functions from:
Regarding complexity, if you're tight on CPU, I don't suggest using more
than complexity 2. Even complexity 1 has quite decent quality. The
higher quality setting are mostly there if you can afford it and really
want to do all you can.
> cb_search_precompute_energy - loop at the comment:
> 	/* Pre-compute codewords response and energy */
> cb_search_update target - loop at the comment:
> 	/* New code: update the rest of the target only if it's worth it */
> 
> These functions represent 1/2 of the compute time at complexity 10 and 4/5
> at complexity 4.
Again, why do you need complexity 10. I'd say it's overkill in 99% of
the time (there's very little improvement between 5 and 10). 
> 1. I haven't been able to get the version of iir_mem2 in filters_sse.h
> translated and working. Does this work with GCC, I'm burning my
eyeballs
> trying to spot the difference in my version.
As I said, I haven't really tested for wideband, so I suggest you try
them on Linux first. Otherwise, common problems when converting from gcc
to MSVC are (some may be obvious):
- make sure to load and store inputs/outputs correctly
- make sure to backup all registers that are modified by the asm code,
otherwise the compiler screws up because it expects that the asm doesn't
touch anything.
- gcc uses the AT&T syntax with "opcode src dest" while MSVC is
"opcode
dest src"
> 2. I don't have a good source of wav data for testing. I've noticed
that
> introducing bugs into speex (even gross ones like returning completely
> incorrect codebook entries) tends to, sometimes subtly, degrade quality
> instead of blowing up. Is there an existing set of source data - and maybe
> even a test harness that will do binary comparison, so I can avoid writing
> one?
The way I do that is I take a file (there are some on the site), encode
it and decode it and check the SNR I get. I then compare to an encoder
which is known to work. Note that in narrowband, there's a 80-sample
offset created by the codec, while in wideband it's 223 samples. Note
that you can't just do a bit-wise comparison because with floating
point, even different optimizations can make a difference.
> 3. I noticed the idea of a fixed-point version of speex on the webpage,
what
> kind of performance difference is expected from that and are the value
> ranges already known?
The idea of having a fixed-point is not really to increase performance
but to allow Speex to work on platforms without an FPU, like PDA's.

        Jean-Marc


-- 
Jean-Marc Valin, M.Sc.A.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada

<p>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 242 bytes
Desc: signature.asc
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20030209/e924255c/signature.pgp

> Btw, has anyone else noticed that the Speex XMMS plugin is missing? While
> speexdec works well, I'd kinda like to use XMMS.
Yes, I mailed the web master and Jens about it a few days ago.  I
have the version I'm currently using which was based on an old
version of Jens and has streaming support. It's a bit queer on
seeking, and crashes XMMS if you seek while in pause, but it does
work otherwise. Available from http://dagobah.ucc.asn.au/speex-xmms/

As a random aside, I've been compiling together the speex'd audio
recordings from Linux.conf.au 2003 (which was a blast!). I'm running
a program called normalize over them to bring them all to the same
level. The originals were encoded with speex 1.0beta4, and I'm
decoding with rc2, normalizing and reencoding with rc2 ... I was
expecting a loss of quality, but they actually sound *better* (even
without normalizing) - the audio sounds clearer.

Whether or not this was expected with rc2, I'd like to give a huge
thank you to Jean-Marc and anybody else involved for developing such
a high quality codec!

Best wishes,

Bernard.


-- 
 Bernard Blackham 
 bernard at blackham dot com dot au


-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20030211/73e73050/part-0001.pgp

> I don't have answers to 1 or 3, but on the issue of good test data,
I've
> been doing a bunch of testing. My best source of test data is System Shock
> 2, the video game. It includes 177 MB (4.3 hours) of speech WAV files in
> 16kHz IMA ADPCM format by various types of voices (male, female, noisy,
> sharp, robotic, organic). Using a shell script and sox, I was able to
> compress it down to 17 MB using 16 kHz wideband, variable bit rate,
> quality 8 with release candidate 1. It definately isn't lossless, but
> it's very good. If you'd like a few of these wav files to test
(100k-300k
> each), I can put a few on my web server.
Please don't do that. Tandeming should be avoided whenever possible and
it's simply not acceptable as testing conditions for a codec (unless you
explicitly want to test for tandeming quality). While not necessarily
perceptible, ADPCM will modify the spectral shape of the signal and will
likely make Speex (at least slightly) less efficient.

        Jean-Marc


-- 
Jean-Marc Valin, M.Sc.A.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada

<p>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 242 bytes
Desc: signature.asc
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20030211/35049035/signature-0001.pgp