Speex dev - Feb 2010 - Fwd: Re: Fixed Point on wideband-mode: Single Frame loss on 2000 Hz sine causes "freak off"

Hi Jean-Marc,

my answers: see below. Any good ideas how I should proceed?


Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> hat am 1. Februar 2010
um 13:09 geschrieben:
> Hi Frank,
>
> On 2010-02-01 05:56, Frank Lorenz wrote:
> > I get really strange results when comparing floating and fixed point
> > versions of interal variables of the ltp, so either something is
> > terribly wrong or I do not understand some fundamental thing (I think
> > the second point is valid...)
> >
> > I observed that for the sine that causes trouble in fixed point, the
> > computed pitch value is quite different for fixed and floating point.
> > So I tried to get into pitch analysis a little deeper...
>
> It's expected that the actual pitch period be different (especially for
> a sine because there can be more than one pitch period that fits
> perfectly). What's important is that after removing the pitch, the
> residual should be small.
I think there's some misunderstanding here: I meant the pitch value is
different *between* fixed and floating point. While for floating point it looks
more or less "random", you can see a clear preference for value of 80
(which is 10 periods of the 2000 Hz input signal) in fixed point.

My understanding of fixed point coding is that any (rounding) differences caused
by fixed point arithmetic must be so small that they do not alter the parameters
(like pitch, pitch gain, LPC etc.). This is not the case here -- something
messes up at least the pitch value. Or behaves the fixed-point arithmetic inside
speex different from my assumption?

> > So I tried to plot the value of energy[0] inside
> > open_loop_nbest_pitch. Find attached two pics showing the plots. The
> > floating point variant looks o.k., while the fixed point variant
> > shows only random values...
>
> Doesn't look completely random to me. Whether this is normal or not is
> hard to tell.
Random or not, the point I wanted to show you is that the values of energy[0]
are different btw. fixed and floating point.
>
> > Is there some pre-scale of input values on fixed point beside the
> > scaledown parameter, or what causes this "randomization" of
the
> > energy[0] value?
>
> So you already took the scaledown into account? If that's the case, it
> looks a bit more odd, but I'm not ready to say that's definitely
the
> problem. Just curious, does the problem occur if the signal's amplitude
> is lower?
For a 2000 Hz sine, a -42 dBFs signal still "freaks out", -43 dBFS and
below is stable.
For such small signals, scaledown will always be 0 (or am I wrong?)
>
> > P.S.: I only write this e-mail to you but not to the mailing list
> > because I don't want to spam the list with details. Is this o.k.
for
> > you or would you prefer these mails go to the list, too?
>
> Unless there's a specific reason you don't want this to be public
(e.g.
> some private info), then the list is the place where it should go.
>
>         Jean-Marc
______________________________________________________
GRATIS f?r alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de

Hi Frank,

Quoting Frank Lorenz <Frank_wtal at web.de>:
> > It's expected that the actual pitch period be different
(especially for
> > a sine because there can be more than one pitch period that fits
> > perfectly). What's important is that after removing the pitch, the
> > residual should be small.
>
> I think there's some misunderstanding here: I meant the pitch value is
> different *between* fixed and floating point. While for floating point it
> looks more or less "random", you can see a clear preference for
value of 80
> (which is 10 periods of the 2000 Hz input signal) in fixed point.
Yes, it's expected to be different between fixed and float because and tiny
rounding error can cause the pitch to change (between mostly equivalent
choices). I would even expect two float version compiled differently to produce
different results just due to small rounding errors in the float.
> My understanding of fixed point coding is that any (rounding) differences
> caused by fixed point arithmetic must be so small that they do not alter
the
> parameters (like pitch, pitch gain, LPC etc.). This is not the case here --
> something messes up at least the pitch value. Or behaves the fixed-point
> arithmetic inside speex different from my assumption?
The rounding differences are small, but they are enough to swing close decisions
in different directions. And once you have a single change, it can affect later
decisions in the encoder. OTOH, on the *decoder*, float and fixed-point should
be much more similar because there are no decisions to make (it's all in the
bit-stream).
> > So you already took the scaledown into account? If that's the
case, it
> > looks a bit more odd, but I'm not ready to say that's
definitely the
> > problem. Just curious, does the problem occur if the signal's
amplitude
> > is lower?
> For a 2000 Hz sine, a -42 dBFs signal still "freaks out", -43
dBFS and below
> is stable.
> For such small signals, scaledown will always be 0 (or am I wrong?)
How do you define dBFs? What if you feed a sine signal that never exceeds +/-
8000 in short.

    Jean-Marc