similar to: [patch] speex_preprocess_ctl

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

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

From 1.2rc1 source code: preprocess.c: /* FIXME: This VAD is a kludge */ st->speech_prob = Pframe; if (st->vad_enabled) { if (st->speech_prob > st->speech_prob_start || (st->was_speech && st->speech_prob > st->speech_prob_continue)) { st->was_speech=1; return 1; } else { st->was_speech=0; return 0; } } else { return 1; } AND case

On Mar 28, 2004, at 8:23 PM, Jean-Marc Valin wrote: >> The st->zeta pointer isn't freed in the >> speex_preprocess_state_destroy() >> function of the preprocess.c file (alloced in line 167). It's in >> Speex 1.1.4 >> by the way. > > Oops... Thanks for letting me know. I'll change that for the next > release (in the mean time, the fix is

Hello, in this commit in celt_encoder.c https://git.xiph.org/?p=opus.git;a=commitdiff;h=652c4559f593d3aad78bd5c85a216eeae7859429 I see the note: + /* We should never see NaNs here. If we find any, then something really bad happened and we better abort + before it does any damage later on. If these asserts are disabled (no hardening), then the table + lookup a few lines below

I have been trying to understand how to get the VAD algorithm working. I sent an input stream of all zeros into the preprocessor but still got a return value of 1 indicating that speech was detected. Is this feature not available with the latest release? I thought at the very least it would detect this as silence and return 0 but that does not seem to be the case. Does anyone have any

Hi, I'll try to keep this as brief, yet descriptive enough to save everyone some time. If I'm off with this one please forgive me, but it has fixed my issues. I am not sure whether it is just my compiler (gcc 3.3.5) doing the wrong thing with the cast. File: preprocess.c Arch affected: x86, (others?) svn revision: 12778 Description: The SpeexPreprocessState_ member 'nb_adapt'

Hi, Here are the next two patches for the data export. speex_get_psd should be applied after speex_get_agc_gain (sent in previous mail). It allows applications to get the power spectrum for the signal and the noise estimate. speex_get_prob should be applied last. It allows fetching the speech probability of the current frame (the value that the _PROB_START and _PROB_CONTINUE parameters are

Here some Blackfin inline assembly, mainly picked and adapted from speex. It's helps a little on my BF537 eval board. Julien -------- /** @file fixed_bfin.h @brief Fixed-point operations for the ADI BF5xx DSP family */ /* Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: -

Hi Jim, Actually, I don't see anything wrong with the internal structure having a different type than the interface, as long both types are big enough to hold the possible values (in this case 0 and 1). Though, as you pointed out, testenc needs to be fixed to use spx_int32_t instead of int. I'll change that. Jean-Marc Jim Crichton a ?crit : > st->highpass_enabled is typed

preprocess.c: /* FIXME: This VAD is a kludge */ st->speech_prob =3D Pframe; if (st->vad_enabled) { if (st->speech_prob > st->speech_prob_start || (st->was_speech && st->speec= h_prob > st->speech_prob_continue)) { st->was_speech=3D1; return 1; } else { st->was_speech=3D0; return 0; } } else { return 1; } AND case SPEEX_PREPROCESS_SET_VAD:

preprocess.c: /* FIXME: This VAD is a kludge */ st->speech_prob =3D Pframe; if (st->vad_enabled) { if (st->speech_prob > st->speech_prob_start || (st->was_speech && st->speec= h_prob > st->speech_prob_continue)) { st->was_speech=3D1; return 1; } else { st->was_speech=3D0; return 0; } } else { return 1; } AND case SPEEX_PREPROCESS_SET_VAD:

For what it's worth, I've had significantly better luck with the WebRtc VAD. It's pretty good. http://code.google.com/p/webrtc/source/browse/#svn%2Ftrunk%2Fsrc%2Fcommon_audio%2Fvad%2Fmain%2Fsource In general, the WebRTC voice engine seems to be more sophisticated and mature than the Speex preprocessor (as opposed to the Speex codec, which is pretty good). Ken Smith Cell:

Hi, Ref the disucussion on IRC yesterday; here's a patch which makes a bit more data from the analysis of the preprocessor and the echo canceller available. For the preprocessor: - Size of power spectrum. - Power spectrum and noise estimate of the previous frame. These are given as squared values, so sqrt() to get values in the 0->32767 range. - Current amplification level

Hello, in celt/celt_encoder.c line 369, the 'b' argument to MAX16 can sometimes be greater than what can be represented by a 16bit integer. The default definition of MAX16 is type-less, but I am working on an architecture with hardware support for min/max of 16bit. Changing the default definition to take advantage of this hardware changes the result of that computation. Please consider

O.k., some more info: I just tested bandwidth widening to fix this. But I need to go to gamma values below 0.9 to become stable -- clearly too much widening, I think. I looked inside the Levinson-Durbin algorithm next. The lines #ifdef FIXED_POINT r = DIV32_16(rr+PSHR32(error,1),ADD16(error,8)); #else r = rr/(error+.003*ac[0]); #endif look interesting. While for floating point,

Hi, I'm moving my "metadata" which accompanies some of the speech packets into the speex bits. However, as usual, I'm a bit confused. The manual (PDF from current SVN), section 5.10 (bottom of page 21) states that: "Finally, applications may define custom in-band messages using mode 13. The size of the message in bytes is encoded with 5 bits, so that the decoder can

Daniel Schmidt a ?crit : > I found the cause of the problem. The function shift_timings can > produce overflows in the timing array if the jitter is huge or the > time units are very short. After changing the timing values' type from > spx_int16_t to spx_int32_t it seems to work. Hmm, I always assumed there wouldn't be any overflows. What parameter range are you using that

Tried your fixed_generic.h change but that didn't help. Andy ----- Original Message ---- From: Andy Ngo <ndno72-speex@yahoo.com> To: Jean-Marc Valin <jean-marc.valin@usherbrooke.ca> Cc: speex-dev@xiph.org Sent: Wednesday, December 12, 2007 4:13:35 PM Subject: Re: [Speex-dev] 4kbps sounds robotic on TMS320C64 Jean-Marc, Yes, fixed-point is enabled (#define FIXED_POINT in

Jean-Marc Valin wrote: >>Reverberation suppression? >> >> > >Basically, it means that if you are in a room with lots of echo (long >decay), I can reduce it a bit. > > > >>I guess this would help reduce local source echoes? I've never >>_noticed_ that to be a problem in my use, but I would imagine that >>using a notebook's