similar to: bug found in CELT 0.6.1, fix proposed.

We were trying to normalize bands that didn't actually exist (e.g., the last band with 320-sample frames at 32kHz). Thanks to John Ridges for the report. --- libcelt/celt.c | 24 +++++++++++++++++------- 1 files changed, 17 insertions(+), 7 deletions(-) diff --git a/libcelt/celt.c b/libcelt/celt.c index 31d35f8..287c720 100644 --- a/libcelt/celt.c +++ b/libcelt/celt.c @@ -1137,6 +1137,7

These were used because the entropy coder originally came from outside libcelt, and thus did not have a common type system. It's now undergone enough modification that it's not ever likely to be used as-is in another codec without some porting effort, so there's no real reason to maintain the typedefs separately. Hopefully we'll replace these all again somedate with a common set

--- libcelt/Makefile.am | 6 +- libcelt/bands.c | 26 +++++++++- libcelt/bands.h | 2 +- libcelt/celt.c | 23 +++----- libcelt/pgain_table.h | 133 ------------------------------------------------- libcelt/quant_pitch.c | 117 ------------------------------------------- libcelt/quant_pitch.h | 44 ---------------- 7 files changed, 37 insertions(+), 314

Tim, et al, I have run into several problems with V0.8.0. I will address them seperately. 1. My compiler is complaining about the following code in celt.c which seems to define metric first as celt_word32, then as celt_word16. Am I mis-interpreting something? ?? VARDECL(celt_word32, metric); ?? ALLOC(metric, len, celt_word16); Thx MikeH -------------- next part -------------- An HTML attachment

Did you check it against the trunk in SVN? If it's not applied, and you can hook Jean-Marc up with an email address like yours, I'm sure he will get right on it. :) Tom Mihai Balea <mihai@hates.ms> wrote: > > Hi all, > > Did anything happen to this patch? > It seems to me that it fixes a valid issue, but I'm not an expert. > Anyways, I didn't see

There is a problem in speex_preprocess_ctl. Both speech_prob_start and speech_prob_continue are set to 327.67 for all input values except 0 which results in 0. This is in floating point mode. I think the included patch fixes the problem. Mikael -------------- next part -------------- Index: libspeex/preprocess.c =================================================================== ---

Hi, In case it is of any help, to compile a static library for the iPhone, I had to add the following 2 lines in plc.c file : #include "arch.h" #include "stack_alloc.h" otherwise "celt_word16..." type are not defined and "VARDECL...." also not. Best Regards St?phane Letz

Hi all, In my setup, I'm using a framesize of 320 samples at a sample rate of 32000 Hz (10 ms frames). This gives me a mode where nbEBands is 21 and eBands[21] is 100 (the standard 2.5 ms short block ebands). This also gives me LM = 2, so what happens is eBands[nbEBands]<<LM is 400, whereas my framesize is only 320. This causes a stack overrun at line 1978 in celt.c in both calls

I checked it against the latest code in the git repository and it wasn't there. Mihai PS: if JM wants a @hates.ms address, I could prolly hook him up. Especially if he throws in some VAD code that's not "a hack" :) On Nov 5, 2007, at 2:08 PM, Tom Grandgent wrote: > Did you check it against the trunk in SVN? > > If it's not applied, and you can hook Jean-Marc up

Firstly, running for more channels will not break my hack. All that's needed is to call RECOPLAY_MARK with different identifiers (say nb, wb or uwb) before doing the appropriate initialization. Secondly, my attempts to do the Gaussian in fixed point went like this : Define a new constant lag_factor_gauss that is manually set equal to exp(sqr(2*M_PI*lag_factor)/-2) by whoever changes the

Hi, It is better to replace this line in function filterbank_new: max_mel = toBARK(EXTRACT16(MULT16_16_Q15(QCONST16(.5f,15),sampling))); to max_mel = toBARK(EXTRACT16(sampling/2)); It gives the same but it seems to be faster and avoids overflow on 44100 kHz that prevents denoiser to process 44100 streams. (Yes I know that Speex should not pack 44100 streams but it does now and I use it). Best

Gents, In Version 8.1, QCONST16 is defined as follows in arch.h within the FLOATING_POINT section: #define QCONST16(x,bits) (x) However, in both celt.c and quant_bands.c, QCONST16 is referenced without a conditional FLOATING_POINT define. So when I compile as FIXED_POINT I get an "undefined identifier" for QCONST16. Am I doing something wrong? Thx, MikeH

Should call celt_inner_prod(). --- celt/bands.c | 7 ++++--- celt/bands.h | 2 +- celt/celt_encoder.c | 6 +++--- celt/pitch.c | 2 +- src/opus_multistream_encoder.c | 2 +- 5 files changed, 10 insertions(+), 9 deletions(-) diff --git a/celt/bands.c b/celt/bands.c index bbe8a4c..1ab24aa 100644 --- a/celt/bands.c +++ b/celt/bands.c

>> I think the residual echo estimation is fairly reliable but I do not know >> how to use this to improve Pframe and in that way solve our main problem >> with the gain during near end talk. > > How can you tell that the residual echo estimation is reliable? in any > case, I suspect that the whole Pframe idea might have to be revised > (i.e. computing it completely

Hi Jean-Marc, Based on the wonderful Speex project, I've created SpeexOutLoud, essentially a Speex codec port for Windows Mobile 2003 devices. I've included a sample project intended to show the usage of SpeexOutLoud codec in a Pocket PC application based on .NET Compact Framework. I'd request you to please go through the attached build, and include it as a contribution to the

Good Morning; Fo this portion of code in the psydecay_init( ) of CELT (psy.c)?: decayR[i]=Q15ONE*power(0.1f,deriv)?? /commented: decay corresponding to -10 dB/Bark. decayL[i]=Q15ONE*power(0.0031623f,deriv)?? /commented: decay corresponding to -25 dB/Bark. Why 0.1 (or 0.0031623)?is being raised to the power of deriv? what is the meaning of this? why 0.1(or 0.0031623) ?not other number? is

--- libcelt/bands.c | 43 ++++++++++++++++++++++++------------------- libcelt/bands.h | 6 ++---- libcelt/celt.c | 6 ++---- 3 files changed, 28 insertions(+), 27 deletions(-) diff --git a/libcelt/bands.c b/libcelt/bands.c index d0c3498..315cce8 100644 --- a/libcelt/bands.c +++ b/libcelt/bands.c @@ -247,23 +247,6 @@ void compute_pitch_gain(const CELTMode *m, const celt_norm_t *X, const

Optimize opus decode (float only) use case using ARM NE10. Mainly effects opus_ifft and ctl_mdct_backward and related functions. Work based on previous Encode optimization using ARM NE10 library. TBD: Add commit id of upstream Encode NE10 optimization patch so that users have reference of how to enable this optimization Signed-off-by: Viswanath Puttagunta <viswanath.puttagunta at

Optimize opus decode (float only) use case using ARM NE10. Mainly effects opus_ifft and ctl_mdct_backward and related functions. Work based on previous Encode optimization using ARM NE10 library. TBD: Add commit id of upstream Encode NE10 optimization patch so that users have reference of how to enable this optimization Signed-off-by: Viswanath Puttagunta <viswanath.puttagunta at

Optimize opus encode (float only) usecase using ARM NE10 library. Mainly effects opus_fft and ctl_mdct_forward and related functions. This optimization can be used for ARM CPUs that have NEON VFP unit. This patch only enables optimizations for ARMv7. Official ARM NE10 library page available at http://projectne10.github.io/Ne10/ To enable this optimization, use --enable-intrinsics