search for: speex_bits_read_whole_byt

...bits_read_from(SpeexBits *bits, const char *bytes, int len); /** Append bytes to the bit-stream * @@ -85,7 +85,7 @@ void speex_bits_read_from(SpeexBits *bits, char *bytes, int len); * @param bytes pointer to the bytes what will be appended * @param len Number of bytes of append */ -void speex_bits_read_whole_bytes(SpeexBits *bits, char *bytes, int len); +void speex_bits_read_whole_bytes(SpeexBits *bits, const char *bytes, int len); /** Write the content of a bit-stream to an area of memory * diff --git a/libspeex/bits.c b/libspeex/bits.c index 8e5e6b6..95adbfd 100644 --- a/libspeex/bits.c +++ b/libsp...

Hello there, I thought I would contribute to this wonderful project but noting a simple but problematic bug in speex_bits_read_whole_bytes(). SITUATION: I have a large stream of frames with NO breaks or length indicators inbetween each frame. For this reason, I call speex_bits_read_whole_bytes() and fill it to MAXIMUM in a loop while calling speex_decode() until there are no more bytes to read. SYMPTOM: You can only go up to MAX_...

...PER_FRAME the buffer will resize automatically, so there's no problem. Just use the size you want. Jean-Marc Le lun 25/08/2003 à 02:27, Thomas S a écrit : > Hello there, > I thought I would contribute to this wonderful project > but noting a simple but problematic bug in > speex_bits_read_whole_bytes(). > > SITUATION: > I have a large stream of frames with NO breaks or > length indicators inbetween each frame. For this > reason, I call speex_bits_read_whole_bytes() and fill > it to MAXIMUM in a loop while calling speex_decode() > until there are no more bytes to read. &...

...//!!!!!!!!!!!!!!!!!!! bits->charPtr=0; bits->bitPtr=0; bits->overflow=0; } What is bits->nbBits=len<<3 ? Shouldn't it be bits->nbBits=len<<3 LOG2_BITS_PER_CHAR ? And another question. What is the difference between functions speex_bits_read_from and speex_bits_read_whole_bytes ? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20060802/cadc2ff2/attachment.html

...ll to shrink nb_celp, but is there anything else I can do to shrink the code or am I reaching my limit? Thanks. these are the functions that I removed: In bits.c: speex_bits_init speex_bits_init_buffer speex_bits_destroy speex_bits_reset speex_bits_rewind speex_bits_read_from speex_bits_flush speex_bits_read_whole_bytes speex_bits_write speex_bits_write_whole_bytes speex_bits_unpack_signed speex_bits_peek_unsigned speex_bits_peek speex_bits_nbytes speex_bits_insert_terminator In cd_search.c: noise_codebook_quant noise_codebook_unquant In filters.c: compute_rms syn_percep_zero16 qmf_decomp qmf_synth In ltp....

...-speex_encode -speex_encoder_ctl -speex_decoder_init -speex_decoder_destroy -speex_decode -speex_decoder_ctl -speex_mode_query -speex_lib_ctl -speex_lib_get_mode -speex_bits_init -speex_bits_init_buffer -speex_bits_destroy -speex_bits_reset -speex_bits_rewind -speex_bits_read_from -speex_bits_read_whole_bytes -speex_bits_write -speex_bits_write_whole_bytes -speex_bits_pack -speex_bits_unpack_signed -speex_bits_unpack_unsigned -speex_bits_nbytes -speex_bits_peek_unsigned -speex_bits_peek -speex_bits_advance -speex_bits_remaining -speex_bits_insert_terminator -speex_inband_handler -speex_st...

...t be the packet loss concealment function (nb_decode_lost). > these are the functions that I removed: > > In bits.c: > speex_bits_init > speex_bits_init_buffer > speex_bits_destroy > speex_bits_reset > speex_bits_rewind > speex_bits_read_from > speex_bits_flush > speex_bits_read_whole_bytes > speex_bits_write > speex_bits_write_whole_bytes > speex_bits_unpack_signed > speex_bits_peek_unsigned > speex_bits_peek > speex_bits_nbytes > speex_bits_insert_terminator You probably don't need most of these, but I'm surprised you're not at least using speex_b...

Hi everyone, I've recently done some major internal changes in Speex aimed at reducing RAM (by nearly a factor of 2!) and improving quality of the fixed-point. In doing so, I might have accidently broken a few things. I'd like to hear feedback on the current svn code to make sure I fix any regression before the next release. I'm already aware that --enable-vorbis-psy is broken and

...e code or am I reaching > my limit? Thanks. > > > these are the functions that I removed: > > In bits.c: > speex_bits_init > speex_bits_init_buffer > speex_bits_destroy > speex_bits_reset > speex_bits_rewind > speex_bits_read_from > speex_bits_flush > speex_bits_read_whole_bytes > speex_bits_write > speex_bits_write_whole_bytes > speex_bits_unpack_signed > speex_bits_peek_unsigned > speex_bits_peek > speex_bits_nbytes > speex_bits_insert_terminator > > In cd_search.c: > noise_codebook_quant > noise_codebook_unquant > > In filter...

Hi there. I made a couple of noted regarding the speex API. These are not meant be seen as critisism - rather constructive suggestions. I like speex a lot, but I would like it even more if some of the following features were available. ;) Christian <p>Comments about the Speex API - from a developer's perspective ------------------------------------------------------------- ***

...coded frame). > This way the speex_bits could be used as a buffer. > > Suggested name: speex_bits_append_from(). Or alternatively > a flag passed into speex_bits_read_from() signalling whether > to append or to replace. If I understand what you said correctly, there is such a call: speex_bits_read_whole_bytes, which adds a couple byte to the SpeexBits struct while removing the ones that have already been read. > *** Querying the codec if there's enough data for a full frame > decode and verifying the bitstream > > It appears there is no way to tell in advance if the decoder >...

...to the TI C54x, C55x builds. Because these processors have 16 bit char size, there is some special code in bits.c to handle the packing. As part of this, there is code to swap the byte order for each 16-bit char within speex_bits_write. There is no such byte swapping in speex_bits_read_from, speex_bits_read_whole_bytes, or speex_bits_write_whole_bytes. For consistency, the byte swapping should be done in all four places or in none of them. In my present build, I have byte swapping in all four places, but it seems cleaner to take this out and leave it to the calling function to do the swapping if it is nee...

I am wont to decode a speex 11kbps 8kHz 16bit to a raw data 8kHz 16bit LSB on a c5509. Trying to understand the "testenc-TI-C5x.c" exsample, but it looks to me wary complicated. Is there more documentation for the exsample or a decoder exsample available? Can somebody help? Peter -------------- next part -------------- An HTML attachment was scrubbed... URL:

...code or >> am I reaching my limit? Thanks. >> >> >> these are the functions that I removed: >> >> In bits.c: speex_bits_init speex_bits_init_buffer >> speex_bits_destroy speex_bits_reset speex_bits_rewind >> speex_bits_read_from speex_bits_flush speex_bits_read_whole_bytes >> speex_bits_write speex_bits_write_whole_bytes >> speex_bits_unpack_signed speex_bits_peek_unsigned speex_bits_peek >> speex_bits_nbytes speex_bits_insert_terminator >> >> In cd_search.c: noise_codebook_quant noise_codebook_unquant >> >> In filters...

> If I understand what you said correctly, there is such a call: > speex_bits_read_whole_bytes, which adds a couple byte to the SpeexBits > struct while removing the ones that have already been read. Oh, how could I not have seen that one? That is exactly what I need. Thanks for the pointer. >> It is unusual to require a different sequence of API calls >> depending on whet...

...x builds. > Because these processors have 16 bit char size, there is some special code > in bits.c to handle the packing. As part of this, there is code to swap the > byte order for each 16-bit char within speex_bits_write. There is no such > byte swapping in speex_bits_read_from, speex_bits_read_whole_bytes, or > speex_bits_write_whole_bytes. For consistency, the byte swapping should be > done in all four places or in none of them. In my present build, I have > byte swapping in all four places, but it seems cleaner to take this out and > leave it to the calling function to do the s...

Hi, I want to take a .wav and generate a bytestream that I can feed direct to speex_decode(). The speexenc program appears to produce it wrapped up in an ogg stream, and it doesn't have any sort of "raw" mode. I've tried hacking on it to remove the ogg parts, but I must have got it wrong, as my decode dies after decoding 160 bytes (which I believe is one frame) with an

...bits->bitPtr=0; bits->overflow=0; } -void speex_bits_read_from(SpeexBits *bits, char *chars, int len) +EXPORT void speex_bits_read_from(SpeexBits *bits, char *chars, int len) { int i; int nchars = len / BYTES_PER_CHAR; @@ -153,7 +153,7 @@ bits->charPtr=0; } -void speex_bits_read_whole_bytes(SpeexBits *bits, char *chars, int nbytes) +EXPORT void speex_bits_read_whole_bytes(SpeexBits *bits, char *chars, int nbytes) { int i,pos; int nchars = nbytes/BYTES_PER_CHAR; @@ -185,7 +185,7 @@ bits->nbBits+=nchars<<LOG2_BITS_PER_CHAR; } -int speex_bits_write(SpeexBits *b...

...bits->bitPtr=0; bits->overflow=0; } -void speex_bits_read_from(SpeexBits *bits, char *chars, int len) +EXPORT void speex_bits_read_from(SpeexBits *bits, char *chars, int len) { int i; int nchars = len / BYTES_PER_CHAR; @@ -153,7 +153,7 @@ bits->charPtr=0; } -void speex_bits_read_whole_bytes(SpeexBits *bits, char *chars, int nbytes) +EXPORT void speex_bits_read_whole_bytes(SpeexBits *bits, char *chars, int nbytes) { int i,pos; int nchars = nbytes/BYTES_PER_CHAR; @@ -185,7 +185,7 @@ bits->nbBits+=nchars<<LOG2_BITS_PER_CHAR; } -int speex_bits_write(SpeexBits *b...