similar to: Update

Le dim 31/08/2003 à 20:12, Daniel Vogel a écrit : > > This works really well for white noise reduction. However > > what I've noticed was the amplitudes of normal speech samples > > also get reduced. > > Noticed this as well recently. This is probably due to the AGC (Adaptive Gain Control) that's integrated with the denoiser. I'll try adding an option to

Le lun 10/11/2003 à 11:19, Massimo a écrit : > On Sun, 2003-11-09 at 21:00, Jean-Marc Valin wrote: > On recent x86 processors, floating point is faster than fixed-point. > > Jean-Marc > > This left me something shocked. Please, can you tell me what kind of > processors are showing this behaviour? Are you referring to speex > codec

Hi everyone, I've just released version 1.1.4. This includes some code cleanup and improvements to the fixed-point port and SSE optimizations. All the SSE code has been converted to intrinsics and some new functions have been implemented with SSE. Overall, the speed has been increased by up to ~30% with SSE. Jean-Marc -- Jean-Marc Valin, M.Sc.A., ing. jr. LABORIUS

> How do i detect whether there is silence in media using speex? > Is there any API which decides that the audio data only contains > silence? > Basically i will have PCM linear data, I want to know whether it is > complete silence. Well, the best way is probably to turn VAD *and* DTX on. Then when there's silence, the speex_encode function will return zero, which

> What I did to find this out: > I comprared a speex AVB with 6.3 KBit/sec (total, overhead for packets and > stuff included) and the 6.3 Kbit/sec Celp Codec vom hawkvoice ( > http://www.hawksoft.com/hawkvoice) and the result is quite favorable for > hawkvoice. > I cant believe that this is *normal* speex behavior, please correct me if that > hawkvoice thing just performs

Yes it's the minimum, as you can't decode half a frame. In Speex frames are 20ms which should be low enough anyway. Jean-Marc Le ven 16/05/2003 à 04:03, Robert M. a écrit : > Here is my situation: > > I have large Speex encoded stream which I would like to playback on wave > out device. I could decode whole stream to pcm and play it back as pcm > audio, but this

OK, what happens is that I try to allocate one big chunk of memory, so that no other allocation is needed in run-time. The biggest part of that memory is used for a custom stack I use everywhere because C doesn't allow variable-length stack arrays. The sizes I used will work for all configurations (any mode/bit-rate/complexity), but if you're only interested in a subset, you can probably

Thanks for the fix. I applied to CVS. It'll be included in the 1.0.1 version I plan to release soon. Jean-Marc Le sam 31/05/2003 à 18:10, Anders S. Johansen a écrit : > Hi! > > Speexdec "clips" playback of files on fast Windows machines when > invoking it in decode-and-play mode by only supplying a filename for the > source file - the end of the sound

Oops... You've just found a bug. Seems like you're the first one to use that call. Anyway, it's now fixed in CVS (both trunk and 1.0.x branch). Thanks for the bug report. Jean-Marc Le mar 03/06/2003 à 01:16, Christian Buchner a écrit : > Hi there. > > I am having a little trouble understanding the frame sizes chosen > by the codec. > > testenc_uwb.c from

Did you really experience problems with the code? Since I only care about the last bits (because of the & "(size-1)"), I thought it should work even if sizeof(int) != sizeof(void*). If it doesn't work with int, I suspect the solution with the long could also fail on some archs. Jean-Marc Le mer 11/06/2003 à 11:56, Christian Weisgerber a écrit : > Casting a pointer to

Hi, Well, there are already Speex plugins for widely used GUI players. I don't see what an "official" standalone player would add. Of course you can still write it, but I don't see a point in making one player "the official player". As for cross-platform, it would basically mean it would have to be written in Java, but even that is inconvenient for platforms that

> I've just kicked off project "Sphinx". Which is supposed to > sound like "Speex" merged with "INT". ;) Meaning I am working > on an integer encoder and decoder. Good news! Although you might want to choose another name since "Sphinx" is already used by CMU's open-source speech recognition engine (http://fife.speech.cs.cmu.edu/sphinx/).

Le ven 27/06/2003 à 05:10, Christian Buchner a écrit : > Hi there. > > Just a little status update how that integerization is coming along. > I am trying to limit myself to 32 bit arithmetics. That means > not using any __int64 or long long datatypes at any point. If possible, it would be nice to restrict ourselves to 32x32->64 multiplies, so the code could run on almost any

> Ultimately, it's Jean-Marc's call. Integrating the Intel IPP/MKL might > be a side-project for someone else to do and offer. If done right, it > can boil down to a set of compiler/linker directives (a la PGP/OpenSSL > using RSAREF) so the only sticking point would be a legal/ethical one > and not technological. Here's my take on it. I don't believe that using the

> QUALITY MEASUREMENT IDEA: > I find it difficult to hear 2 voice samples and tell > which is nearer the original, especially if the > background hiss is slightly different. So what if you > actually subtract the post-compression sound from the > original and then listen to the DIFFERENCE. If you > can't hear any voice except background noise and some > hiss from

Actually, the SNR calculation in testenc has been broken for a while. The reason for taking the last frame was that the codec would introduce a one-frame latency. I changed that to half a frame (10 ms) a while ago and never updated testenc. Jean-Marc Le lun 01/09/2003 à 13:12, Mike Dunn a écrit : > Hi all, > > I'm new to the group. I'm looking at the speex code with an

Just to let you know I released 1.1: This is an unstable release. It brings many new features, some of which are still experimental. The new features are: * a denoiser that removes most of the background noise and can be used before encoding (available as --denoise in speexenc) * adaptive gain control (AGC), which adjusts the volume to a constant level (available as

> Then I pulled the microphone out. Our system still records noise. To > isolate the problem, I wrote a small app just to open the device and > record raw samples, calls speex_denoise() and outputs both sample > sets. > The noise is still there, with level fluctuating with gain level, > unless > "All mute" is chosen. > In the case when NO microphone is

> 1) What should I use for a filter length for speex_echo_state_init()? Well, it depends on your problem. The filter length represents the maximum delay of the echo. For acoustic echo, that value is generally higher than for line echo. You'll need to experiment, but a value around 500 (for 8 kHz) might be a good start. > 2) I'm assuming I want to call speex_echo_cancel() on each

Hi, There seems to be some confusion as to how speex_denoise (now called speex_preprocess) works. Unlike what some here assume, the noise estimation is not done offline or while prompting the user. The system automatically adapts the noise estimate when it detects that the user is not talking. This also means that it is able to adapt to changing noise environments - as long as the noise is not