similar to: frame size

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

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 all, One question that I hope someone on the list just knows the answer to without having to delve too deeply into the code: How does UWB mode divvy up the bandwidth and pack it in the bitstream? I know from the documentation that WB mode codes the first 0-4K kHz band as a Narrowband packet, and then adds on the 4-8 kHz band coded separately (so that a NB decoder can decode a WB bitstream

Thanks Jean-Marc. I do want to change Speex frame size to 320. In this case, I've changed frame size in init and modes (include framesize and subframesize). However, the audio quality becomes bad. It seems something else needs to be changed as well. Could you give a clue? Thanks, Dennis -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent:

Hi Kevin, Are you saying that the quality is good at 20 ms and bad at 10 ms, or the reverse? Also, is this speech or music? What tool, what options? In general, it helps a lot if you post the sample (input and output). Cheers, Jean-Marc On 06/03/2016 12:48 PM, Kevin Connor wrote: > Hi Opus list, > > I'm noticing a discontinuity in the quality between use of 10ms and > 20ms

Speex tells me that the decoder is always 5 ms, but it says that the encoder is 5 ms for NB, 8.9375 ms for WB, and 10.90625 ms for UWB. Is there an extra frame of delay in the encoder that isn't otherwise accounted for? John Ridges Jean-Marc Valin wrote: > Quoting John Ridges <jridges at masque.com>: > >> I also need to know the precise delays from Speex but I used

I'm trying to convert my current headphones and microphone chat application to support loudspeakers and microphone, and so I thought I'd give speex_echo_cancel() a try. Since my users quite frequently have other sound-producing applications running on their computer (such as winamp), I sample 'wave' recording device of the soundcard in addition to the microphone. I then call

Hi Jean-Marc, > Can you confirm I'm understanding everything correctly? You encode > with > the same encoder and then decode with either A) blackfin assembly and > fixed-point or B) fixed-point only on Blackfin. Then A) sounds bad and > B) sounds good. If you do the same in narrowband, it sounds OK. Is > that > correct? If that's the case, it's *probably* some

> Ok, here is cleaned up and fixed version. > > * Function is named speex_get_num_frames() now and return > number of frames, as you suggested. > * WB layers sizes are taken from wb_skip_table[], while NB frame > sizes are calculated with speex_mode_query(). Looking better. Just make sure to remove the stuff that isn't C99-compatible (e.g. // comments). > I've

JM, I also need to know the precise delays from Speex but I used the SPEEX_GET_LOOKAHEAD control requests to determine them (plus the "speex_resampler_get_output_latency" function from the resampler). The returned values from the Speex lookahead request don't seem to match with the values you gave Alexander. Am I doing this wrong? Thanks, John Ridges speex-dev-request at

Hi Jean Marc and List, So I have started finally fiddling around with Ultra-wideband mode. It appears to be very similar in operation to Wide mode, except that when peering into the packet structure it looks like (and these are kind of questions as much as statements here): 1. update rate 0 is not used in UWB- only 1-4? 2. The total bits used for each UWB update rate seem to be as follows:

Hi, I am currently encoding 32 Khz/Qual-10/UWB encode mode, with MANUAL_ALLOC enabled ( similar to the c5x/c6x configuration). In file sb_celp.c, I noticed the scratch memory grow during recursive (UWB -> WB) calls to 'sb_encode'. 1. 'stack' was not tracked (with 'tmp_stack' as done at other palaces) after/before - auto-correlation/Levinson-Durbin scope (~line

> Oh, you're right, inband handling is different, but it's a matter of one > flag, passed to functioin. Probably not that much to keep code DRY. Well, let's first merge your code and then we'll see about possible simplifications. >> frame: 20 ms encoding >> sub-frame: 5 ms encoding (internal) >> layer: one frame of nb or sb >> sb: sub-band >>

Hello, To start with, thanks a lot for making such a great voice codec available! Having recently upgrading to speex rc1, It occurred to us that there seems to have been a regression in the quality of encoding since version beta1. We are compressing some 22khz wave files in wb mode with maximum quality / complexity in VBR, and the result was really great with speex beta1. With rc1 (or beta3),

Hello Jean-Marc and all, I recently had a talk with somebody about CELP. He said, there is this federal standard 1016 (4.8kbps) with a reference implementation of the Department of Defense (only on Sun, unfortunately, if I got this right). This one is noticed in the manual already. He also said, since there is this implementation of the DoD, nobody would voluntarily re-implement CELP. If I read

Okay, Not exactly the answer I was looking for. This sounds like a big change. I don't mind re-writing the LSP quantizer but re-training code books and breaking compatibility is not what I want to do. I am working on an optimization for an ARM cortex-A8. It is desirable to process things in 4 element blocks. Is there a simpler approach you could recommend? Vasant Shridhar

I would like to make lpcSize a multiple of 4. In the current library for narrow band mode lpcSize is currently set to 10. I would like to increase this 12 for optimization reasons. Is it a simple matter of just changing lpcSize in the structures in mode.c or are there other implications to doing this? I did try and change the value but I seem to be getting some runtime errors indicating a

Hello, In the internet draft describing the SDP parameters for speex I find this: mode: Speex encoding mode. Can be {1,2,3,4,5,6,any} defaults to 3 in narrowband, 6 in wide and ultra-wide. In the documentation I can only find the following request: SPEEX_SET_MODE There is no description though what this request does. I think the mode somehow maps to the bitrate, but I

Hi there. I am having a little trouble understanding the frame sizes chosen by the codec. testenc_uwb.c from the speex-1.0 source distribution has a framesize of 640 hardcoded and makes use of this value exclusively. However, a mode query on the actual codec returns 320 as a framesize for this mode. int tmp; speex_mode_query(&speex_uwb_mode, SPEEX_MODE_FRAME_SIZE, &tmp);

Hello Jean-Marc, > Could you try mixing the encoders and decoders (encode with one > version, > decode with the other) to see whether the problem is in the > encoder, the > decoder or both. I tested that,and the results are: The fixedpoint+blackfin encoder used together with the fixedpoint-only decoder produces an bad sounding file (for all the combinations for quality