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

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

> i was wondering whether speex frames could be made "independent",
If you tweak the encoder, you can probably do that... except that you'll
multiply the bit-rate by about 3.
> 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.
Read the draft and manual carefully. Speex does provide a way to recover
from packet loss (without retransmission). The frame that follows the
lost frame won't be exact, but it can still be decoded (and Speex
accounts for all that).
> if Speex's decoder's state memory is small enough, it could be sent
> from encoder to the decoder.
There ain't no such thing as a free lunch. Of course the decoder state
is large.
> or there are other
> mechanisms in place to deal with the lost packet problem?
Yes, just read the doc, and optionally look at the --packet-loss option
in speexdec, which simulates loss of packets.

	Jean-Marc

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

hi,

I am currently trying out speex version of 1.1.6 FIXED_POINT.

noticed there's a 64 bit integer being used in the long term prediction.
any chance of using a 32 bit integer without incurring some major side-effects?

cheers,
tk