similar to: Multiple Frames per Packet

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 >

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

This patch will export new speex functions in the generated library, such as speex_encode_int as well as the preprocessor, echo-cancellation and jitterbuffers. The ordinals used matches the 1.1.6 release from the speex.org website, so any new library created with this def file should be binary compatible with that one. -------------- next part -------------- Index: speex.def

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

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

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

Ohh... Nice! This is new in 1.0.1, isn't it? It doesn't seem to be included in the reference manual yet, though. Thanks! Tom <p>Jean-Marc Valin (jean-marc.valin@hermes.usherb.ca) wrote: > > OK, this is how it works: > > The encoder calls speex_encode any number of times and then calls > speex_bits_insert_terminator before sending the bits. > > The

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 think Timothy intended for this to go to the list; my apologies if it wasn't.) -------- Original Message -------- Subject: Re: [Theora-dev] Force keyframe creation Date: Sat, 06 Aug 2005 00:06:32 -0400 From: Timothy B. Terriberry <tterribe@vt.edu> To: David Barrett <dbarrett@quinthar.com> References: <42F4186C.1050605@quinthar.com> David Barrett wrote: > Is there any

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.

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, what is the good way to encode / decode multiple frames in packet ? I read that I must do multiple call to encode and thats it. But when I'm trying to decode,, it doesn't work. Maybe, the problem is my decode function. Here is my encode function void ms_speex_enc_process(MSSpeexEnc *obj) { .... Do I need to increase gran value to 640 or read / encode (2 times)

Hi, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output

I'm only doing one frame using speex_encode_int greatly simplifies my code I'm not sure why the sample I was working off of was converting the shorts to floats then calling the other encode/decode methods. Based off of your suggestions I tried the following but I get the same result. virtual Enigma::u8* Encode(Enigma::u8* inputBuffer,size_t inputSize, size_t& outputSize) {

I have non terminate loop when decode speex bits stream. These are my pseudocode for encoding and decoding -- Encode -- while(stillhaveinput) { speex_encode(enc_state, curr_spx_frame, &bits); } speex_bits_insert_terminator(&bits); speex_bits_write(&bits,(char *)(pBufferOut),MAX_LEN); -- Decode (these code loop forever) -- speex_bits_read_from(&bits, (char *) pBuf,act_length);

for the bits init I am using speex_bits_set_bit_buffer and I don't use the write to or read from because the data is already in the buffer I am reading from and I am writing to the final buffer so I don't need to move arrays around. what part is the vocoder part of the decode? Thanks for your help! -Mike >>> Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> 08/06/07

Hi, I've attached a patch against SVN r14645 which adds GCC visibility information to all symbols exported from libspeex.so and libspeexdsp.so. It includes a configure.ac change to test that both the compiler flags and __attribute__((visibility)) works, and if so will #define EXPORT __attribute__((visibility("default"))) and if not #define EXPORT I've attached a diff output

Hi everybody, I have been examining on how I can use speex completely so I have one more question. I looked at examples and source code and it goes on. speex_bits_insert_terminator is called in speex_bits_write function. Shall I call this method one more time anywhere? Because in speexenc project, firstly speex_bits_insert_terminator is called then speex_bits_write is called when we assume that

Hi, I am using speex 1.2beta2 on a narrowband 16-bit, 8khz system that has a severe program space problem and will not fit speex in its normal operation. In an attempt to shrink speex I placed a breakpoint in every function and ran a decode and encode and removed the breakpoints that I hit. in the functions that had a breakpoint that I didn't hit I commented out those functions (as well as