similar to: seeking in time, feedback+question

Hi All, We are using speex decoder only for narrow band decoding. Quite often, even though source frame is not silence, decoded audio is silence. I wonder there is a problem in the way we uses speex decoder API. Basically, we initialize speex decoder only once and just reset the decoder before we decoding another file. Do we need to intialize speex decoder and destory decoder for each audio file

Hi Peter, Can you say a little bit more about what you're doing exactly with the information you're exposing and how? unfortunately, I don't have a concrete proposal in mind right now. That's in part because I don't quite understand the use case, but also because it's really hard to expose this kind of information in a way that both avoids breaking application with new

Hi, Can someone please tell me how should I go about changing the frame size which is hardcoded to 160 for NB and WB and 320 for UWB. For NB speech(8KHz) the framesize of 160 is 20ms frame but for WB and UWB its 10ms. What are the parameters being affected by simply changing the framesize and sub-frame size in "modes.c" How to change the buffer size and how its affected. can we have a

Hi, I am an user of speex codec.Can I ask some question about the speexcodec 1.2beta2 on installed to linux(fedora 6) thanks! After I downloaded the latest version of codec then I type the commands to install : configure -prefix=/home/...../test -enable-shared -enable-static make make install then I try to compile my encode.c here is the encode.c of mine: =====================================

Hi, in my application i quite often (not allways) get those two warning: "Invalid mode encountered: corrupted stream?" "Invalid wideband mode encountered: corrupted stream?" The stream is not corrupted but i wish to know what those warning mean to correct my code. My encode and decode routines are those (libspeex 1.1.4): SpeexBits enc_bits, dec_bits; void *enc_state,

Hi Jean-Marc, We're exposing the opus_internal_flags data structure so that we can access the value assigned to prevSignalType. Here's a snippet of our code: error = opus_encoder_get_internal_flags(vad->opus, &internalflags); if (error != OPUS_OK) { return OPUSVAD_OPUS_ERROR; } cur_signal_type = internalflags.prevSignalType; if

Hi Peter, There's two main issues with a patch like the one you're proposing. First, the data is only valid when SILK is being used and is essentially undefined in CELT mode. The second issue is that by exposing internals, it makes it impossible to improve these algorithms since it would break API compatibility. I'm not fundamentally against trying to expose some information, but

Hi Jean-Marc, Thank you for the valuable feedback. You're correct in that we focused on enabling this just for SILK. Because our solutions are focused on voice, we did not explore doing the same in CELT mode, but we can certainly look into the details of analysis.c. Regarding the concern of exposing internals, do you have a specific proposal in mind? We've been sharing this patch with

----- Original Message ----- From: "Jean-Marc Valin" <Jean-Marc.Valin@USherbrooke.ca> To: "tunkeat" <tunkeat@gmail.com> Cc: "speex" <speex-dev@xiph.org> Sent: Wednesday, January 05, 2005 2:48 PM Subject: Re: [Speex-dev] different output for opt/non-opt on win32 platform >No. Like any other CELP codec, Speex has a memory. The only non-PCM

Hi everyone! Our company is writing some voice chat software using Speex, and I am in charge of writing the Windows-only portion of the code. I've just finished tracking down a very nasty little bug in our program, and, I saw similar symptoms of the bug in one or two posts in the list archives, so I thought I would make a new post in case anyone runs across this again. Symptom:

> Hi, > > It could (and should) definitely be done, but it's somewhere > (unfortunately not on top) on my TODO list. I think the simplest way > (until I really integrate the preprocessor with the codec, which will > take a while) to do it is to add a speex_encoder_ctl() call as you > proposed. I'd call it SPEEX_SET_EXT_VAD_STATUS and I'm willing to merge > a

Thanks! Btw, have you tried using SBR-technology or similar with speech codecs? That might be a good idea I thought.. But I don't know if it produces as good quality with speech codecs as it does for music codecs. Do you know if there is any open source variant of SBR? /Pontus -----Ursprungligt meddelande----- Från: owner-speex-dev@xiph.org [mailto:owner-speex-dev@xiph.org]För Jean-Marc

Hello! I should have asked this earlier, but... :) We're returning to voice processing in our app now, in which we're trying to achieve n-way full duplex voice in a 3d environment. Since Speex is a single voice stream CODEC, we've been looking at having each client upload its stream to the servers, which multiplex several spatially nearby active channels back down to the

Pontus Carlsson wrote: >Thanks! > >Btw, have you tried using SBR-technology or similar with speech codecs? That >might be a good idea I thought.. But I don't know if it produces as good >quality with speech codecs as it does for music codecs. Do you know if there >is any open source variant of SBR? > SBR exploits a limitation of your ears. At high frequencies (like over

Hi Jean-Marc, Sorry for late reply, thanks for interest. It's quality good for 10ms/audio, poorer for 20ms/audio. Quality equivalent for 10,20ms for mode=voip. PESQ was the tool that alerted me to something of interest, but I don't trust PESQ to almost any degree! It's good for hearing relative differences, of course, but not absolutes. Bitrate here was 28kbps, but I hear

Well, I don't know what SBR is, but there's something in the wideband mode that may be similar: It's possible to encode the whole 4-8 kHz band with just ~1-2 kbps by only encoding the (LPC) shape of the spectrum and then just filling that band with "something that makes sense". Quality is quite reasonable... Jean-Marc Le dim 13/10/2002 à 06:18, Steve Underwood a

David Hogan a ?crit : > Are you calling the speex API from multiple threads? > > If so, I suspect that if you use a mutex to ensure that only one > thread can access the speex API at a given moment, the problem will > go away. Obviously this reduces the scalability of your program, but > it makes a good test. If that fixes it, then I recommend changing the > code to ensure

Le mercredi 10 mai 2006 ? 10:17 +0100, devilal sharma a ?crit : > Hi, > Can someone please tell me how should I go about changing the frame > size which is hardcoded to 160 for NB and WB and 320 for UWB. > For NB speech(8KHz) the framesize of 160 is 20ms frame but for WB and > UWB its 10ms. Sorry, you got your calculations wrong, it's 20 ms regardless of the modes. > What

hi, basically I am anyway using GMM based parametric VQ for LSF quantization so that is not a problem. Can you plz. tell me how to retrain the pitch codebook and innovation codebook. what are the tools to train the pitch and innovation codebook? Regarding the pitch prediction for high-band, I understand your reason of not using it for high-band. There is one paper, "A 14 kb/s wideband

hi, thanks for answers to my previous qns. have some more of them. hope it's ok to ask questions on the basics of CELP here. let me know if it's not. 1) synthesized filter stability after interpolation of LSFs I read from some resources that if LSF representation of LPCs is used for interpolation, stability of the synthesis filter is guaranteed. from another source, i read that the