Speex dev - Jan 2005 - different output for opt/non-opt on win32 platform

hi,

Jean-Marc, thanks for the comments. 
> > just downloaded speex v 1.1.6.
> >  when I removed optimisation flags for win32 in libspeex.dsp,
> > I get a slightly different output for decoding using speexdec.exe
> > (debug version). no prob for speexenc.exe except for some
> > differences in the ogg header.
> 
> What difference in the ogg header? It's quite normal that compiler
> options will (slightly) change the result. The reason is that the
> rounding depends on when the compiler loads/stores the float values.
diff in ogg header: oh, due to a random number passed to the
second argument of ogg_stream_init().

without a good understanding of the celp and haven't delved into the 
codes, I am surprised that there is no such issue with the encoder.
whether the optimsation flags are included or excluded, the encoded
bits are the same. I assumed the decoder shared quite a number of 
functions as the encoder except maybe the perceptual enhancement part.
strange.
> 
> > i have the understanding each speex frame is self-contained,
> > i.e., the decoder could decode each frame independently. is that
> > right?
> 
> No. Like any other CELP codec, Speex has a memory. The only non-PCM
> speech codec I know that has independent frames is iLBC and it's
> suboptimal for most uses because of that.
> 
how big is this "Speex's memory"?  I am thinking perhaps naively:
at
the encoder side, is it possible to get the states for the decoder
from the encoder's memory without doing the actual decoding? if yes,
the decoder's states could be sent over.
I hope I am making sense here.

thanks in advance,
tk

> without a good understanding of the celp and haven't delved into the 
> codes, I am surprised that there is no such issue with the encoder.
> whether the optimsation flags are included or excluded, the encoded
> bits are the same. I assumed the decoder shared quite a number of 
> functions as the encoder except maybe the perceptual enhancement part.
> strange.
Depending on the mode used, there can even be a random component in the
decoded signal.
> how big is this "Speex's memory"?  
No problem, as long as you decode the stream in order.
> I am thinking perhaps naively: at
> the encoder side, is it possible to get the states for the decoder
> from the encoder's memory without doing the actual decoding? 
In theory, you could, but I don't see what you'd gain there.
> if yes,
> the decoder's states could be sent over.
> I hope I am making sense here.
You're not. Sorry ;-)

-- 
Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca>
Universite de Sherbrooke

hi,
> > how big is this "Speex's memory"?
> 
> No problem, as long as you decode the stream in order.
> 
> > I am thinking perhaps naively: at
> > the encoder side, is it possible to get the states for the decoder
> > from the encoder's memory without doing the actual decoding?
> 
> In theory, you could, but I don't see what you'd gain there.
i was wondering whether speex frames could be made "independent",
as in if some packets are lost, there is no need for re-transmission of
these frames (for VoIP app, i see concealment is provided in speex) to decode 
future frames . from the draft RFC for speex, I don't see space
reserved for state info.

if Speex's decoder's state memory is small enough, it could be sent 
from encoder to the decoder.  at the decoder, when each frame is
received, the decoder's state could be initialised and decoding could
be performed using the
transmitted state.  possible? or is it already enforced? or there are other
mechanisms in place to deal with the lost packet problem?

TIA,
tk