search for: speex_decoder

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

I thought it would be more update/better/faster, any thing wrong? In the future, would you use short, and forget about float? If so, I use 1.1.4, I wouldn't need to change my code in the future, right? You said, it's unstable, yes, I got compiling errors with MsVC6 and MsVC.net And I modified it a bit to get it compiled. Should I post the errors here? <p>-----Original Message-----

Ok, I'm using 1.1.4, so I should pass signed short(wav data) directly to speex_encode()? But the samplecode that comes with 1.1.4 shows me to put short in float array, and pass the float array to speex_encode() <p>-----Original Message----- From: owner-speex-dev@xiph.org [mailto:owner-speex-dev@xiph.org] On Behalf Of Jean-Marc Valin Sent: Saturday, April 17, 2004 6:25 AM To: speex

> You said, it's unstable, yes, I got compiling errors with MsVC6 and MsVC.net > And I modified it a bit to get it compiled. Should I post the errors > here? YES, kindly post the errors that you encountered. - Abhishek <p><p><p>---------- Original Message ----------- From: "Kenji Chan" <adslbqmr@tpg.com.au> To: <speex-dev@xiph.org> Sent:

I'm confused about the format of the PCM/WAV data for speex_encode & speex_decode speex_encode(enc_state, input_frame, &bits); In the manual, it says "input_frame is a (float *) pointing to the beginning of a speech frame" (for encode) But I've found that in speexenc.c and testenc.c, short* is used instead of float* So, isn't it signed 16 bit samples(if

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 >

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

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 same on both sides. When using a newer Speex (1.1.?) to encode and an older version to decode (1.0.5), it does not work. The encoder

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

-----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

Speex 1.0.3 uses floats, but the unstable version 1.1.x uses short. Jean-Marc Le ven 16/04/2004 16:04, Kenji Chan a crit : > Im confused about the format of the PCM/WAV data for speex_encode & > speex_decode > > speex_encode(enc_state, input_frame, &bits); > > In the manual, it says input_frame is a (float *) pointing to the > beginning of a speech

Le ven 16/04/2004 à 16:39, Kenji Chan a écrit : > Ok, I'm using 1.1.4, so I should pass signed short(wav data) directly to > speex_encode()? First, I'd like to ak why you want to use 1.1.4. If you don't need the new features (fixed-point or preprocessor), you should probably stick to 1.0.3, which has received more testing. If you choose to use 1.1.4, you need to send shorts to

I've just started testing Speex, and it seems very good so far. In testing the Speex decoder and simulating packet loss, I noticed that simply not calling speex_decode(st, NULL, output) when a packet is dropped doesn't appear to degrade the quality of the audio later on. The reason for this test is that in a real-time situation, you may not know right away when a packet is dropped

...e is a problem in the way we uses speex decoder API. Basically, we initialize speex decoder only once and just reset the decoder before we decoding another file. Do we need to intialize speex decoder and destory decoder for each audio file decoding ? Here is current pseudo code. main() { m_speex = speex_decoder_init(speex_nb_mode); speex_decoder_ctl(m_speex, SPEEX_SET_ENH, &tmp); speex_bits_init(&m_bits); while(end of files) { speex_decoder_ctl(m_speex, SPEEX_RESET_STATE, &tmp); speex_bits_reset(&m_bits); OpenFile(speex audio file); while(end of file) { fread(speex...

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

Jean-Marc Valin wrote: >>I believe it is adaptive, but no, I haven't used it, because it's >>coupled only to the speex codec. We're working on a generic >>application and codec-independent jitter buffer algorithm, for use in >>asterisk and iaxclient (at least). Some information is available at

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.

...in SPXDEC.exe: 0xC0000005: Access violation reading location 0x0000000c. Unhandled exception at 0x004010fa in SPXDEC.exe: 0xC0000005: Access violation reading location 0x0000000c. It looks like the same error. I've attached the code below Thanks, Mon Portion of the revised code: decstate = speex_decoder_init (&speex_nb_mode); // Set default options for decoding: temp = 1; speex_decoder_ctl(decstate, SPEEX_SET_ENH, &temp); // Initialize spxbits (structure SpeexBits) speex_bits_init (&spxbits); while (!(feof(fo))) // this is where the problem starts { fread (&nbBytes, sizeof(int),...

Here's the situation: 3 frames are being transferred back to back over RTP. The total payload is known (thus the TOTAL frame size). We'd like to decode all 3. According to IETF RTP Profile (appendix C, of Jean-Marc's Speex Codec Manual, verison 1.0), "it's only necessary to consider the sequence of bits as output by the Speex encoder, and present the same sequence to

Hi, I'm using Speex and I want to pack multiple frames into a single packet. The manual (section 4.5) says to call "speex_encode()" multiple times before calling "speex_bits_write()", and then call "speex_decode()" until it returns -1. However, when I try that "speex_decode()" never returns -1, and it enters an infinite loop. I'm using 1.0.4. Any