similar to: Is Speex 1.0 and >=1.1 compatible?

On Saturday 10 April 2010 21.51.55 Jean-Marc Valin wrote: > All version after 1.0 are compatible with each other and with 1.0. Hi Jean-Marc and thanks for the quick reply. I have now looked at this further and got the idea to hard code the number of frames in the decoder temporarily as a test and voil?, it works! The problem seem to be some incompatibility in the termination handling. After

The main difference is not that much in the bit-stream but in the API. In earlier versions you had to append the terminator manually, whereas I modifed later versions to do it automatically in case programmers forgot (there was no reason not to do so). Jean-Marc On 2010-04-11 05:23, Tobias wrote: > On Saturday 10 April 2010 21.51.55 Jean-Marc Valin wrote: >> All version after 1.0

All version after 1.0 are compatible with each other and with 1.0. Jean-Marc On 2010-04-10 15:44, Tobias wrote: > Hi list, > > I'm trying to figure out how to do the most compatible implementation that will > work with as many versions of Speex as possible. I am streaming multi frame > Speex blocks over a TCP connection which works fine as long as the version of > Speex is

The entries in xenstore have permission attributes. The attributes can be easily altered by xenstore-chmod, however, I cannot find a easy way to see them. I''ve modified xenstore_client.c to raise a new utility. The utility checks the permission and makes an easy-look output. Please tell me any suggestions. Thanks. Signed-off-by: Frank Pan <frankpzh@gmail.com> ---

David, Here's the trick ... do this just before your speex_bits_write(): speex_bits_insert_terminator(&bits); Then, when decoding, keep calling speex_decode() until it returns -1 or speex_bits_remaining(&bits) returns 0. Works for me, anyway. Tom David Barrett (dbarrett@quinthar.com) wrote: > > Hi, I'm using Speex and I want to pack multiple frames into a single >

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 15/04/2010 01:30, Conrad Parker wrote: > >> But how can I know the size of each speex frame into a multiframe payload? > > use speex_bit_read_from() just once on the packet, then call > speex_decode() once for each frame. > > Conrad. Thanks for the reply, Conrad. What is not clear for me (and I didn't found it on the

> 16 bit ints have a range of -32768 to 32767. If you divide > -32768 by 32767.0 you end up with -1.00003051850948 which > is a bad thing. > > Try normalizing with a value of 32768.0. No. Speex expects values in the +-32767 range, not +-1.0. Just converting from int16 to float *is* the right thing to do. Jean-Marc -- Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca>

I wanted to confirm that my understanding of the situation is correct. For background, I've been working have an optimizer pass for a research architecture which works best when there are large basic blocks and good alias analysis results. I first noticed the issue in rgbcmy01 from eembc-1.1, but have created a simpler test case which demonstrates the same issue which is unencumbered by the

Dear all, I have one simple question. I understand that speex_encode and speex_decode takes float * as an arguement to encode and decode the sound. However, when I get the PCM data from the sound card under win32, it is a just 16 bit array. May I know how do I convert this 16 bit value to speex float format and to convert back? Is there got any routine to do this? YueWeng

Dear all, First, my aim is to achieve VoIP using VBR and DTX under Win32. I face a problem using speex 1.0.4 and need some help. My voice is ok and no background noise when I do NOT normalize 16 bit value to floating value. Normalized means dividing the 16 bit value by 32767. Turning on VBR is also ok but DTX has no effect. However, the speak is has a continous background beep sound AFTER I

Il 14/04/2010 14:37, Randy Yates wrote: > > Usually a buffer is one frame of data, and a frame is 20 milliseconds. > Since the sample rate is typically 8 kHz in narrowband mode, this > corresponds to a buffer size of 160 samples. Hi Randy, thanks for the reply. So, suppose I encode an audio buffer (8000 kHz, MONO, float) of 640 PCM frames. In output I have 4 speex frame of 20 byte

After searching the mailing list archive (I forgot to do that before posting, sorry!) I found the solutions: 1) The documentation has a mistake: The bit terminator is NOT set automatically! (I'm using the latest speex version!) It has to be set manually using speex_bits_insert_terminator(&bits); 2) speex_decoder_int() has to be called as long, as it returns -1. After that, all frames

Hi, I'm very sorry if those questions are repeated over and over, but I cannot find a solution on the net. I try to use speex to encode/decode voice to send over the network. My doubts are: 1. The Bits_Per_Sample I use, are independent from the speex encoding/decoding? (So...can I use 8, 16, 24..and so on?) 2. If I have this situation: SAMPLE RATE.....: 8000 BITS PER SAMPLE.: 16

Hello there I'm having trouble decoding speex frames when using 32KHz audio and quality setting 4. If I encode three frames and then decode the three frames then the speex_bits_remaining() still reports that there are bits remaining. All other band modes and qualities reports that the buffer is emptied. Here's an example that shows 4 bits remaing in the buffer after the frames have

>> Consider a device that only has enough ROM to store one set of >> quantization tables (the limitation could also be about speed, network, >> ...). If you specify MUST be able to decode, then it means that this >> device simply *cannot* implement the spec *at all*. This is bad for >> interoperability. > > For me: device which don't have all mode

Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca> wrote: > > > 1) Supporting the various versions of Speex is a nuisance, mainly > > because there is no #define or API call to query the version. > > It is possible to get the version using speex_lib_ctl(int request, void > *ptr). Possible requests are SPEEX_LIB_GET_MAJOR_VERSION, > SPEEX_LIB_GET_MINOR_VERSION,

I have (finally) posted my Speex wrapper classes. They are at: http://www.grandgent.com/spx/tgAudioCodec.zip I followed your recommendations and they worked fine with 1.1.0. However, I'm still having the same problem with 1.1.7 that I had the last time I tried to upgrade. I'm using the same code with both versions, except for calling speex_encode_int instead of speex_encode, and

>> The main idea is that Speex supports many bit-rates, but for one reason >> or another, some modes may be left out in implementations (e.g. for RAM >> or network reasons). What we're saying here is that you should make an >> effoft to at least support (and offer) the 8 kbps mode to maximise >> compatibility. > > I understood this. But as you may know: the

I tried feeding in the 3 encoded frame in ONE BLOCK, and calling speex_decode() 3 times in a roll. Only the 1st frames came out perfectly. For the other 2, I got "corrupt" frame warning. I was supposed to get 38 bytes consumed each frame (narrow-band, VBR off). I tried speex_bits_remaining() to peek on the # of bits consumed, and got variable (clearly wrong)#s returned. But if I

Ok, I figured it out. :) This seems to work: 1) Call speex_bits_read_from() once, specifying the location in memory of the compressed data, and the total length of that data. 2) Keep calling speex_decode() until speex_bits_remaining() returns 0. Then you don't have to keep track of the # of frames per packet, or the size of each compressed frame. It's done magically by the codec.