similar to: Speex Resampler Usage

Hi List, Now I will send to you more specific what I am trying to do. I have one Asterisk Channel where receives Midia Frames in the codecs format: Speex UltraWideBand and Speex NarrowBand. When I use Speex NarrowBand the Asterisk is able to convert this frame to G711. But when I use Speex UltraWideBand the Asterisk don't convert it. Then I need in my Asterisk Channel Source include the Speex

________________________________ Hi David, Thank you very much for your reply. Since I need to resample the audio in the program itself, I decided to try out the resampling API in speex. But now, I have another problem. The resampled sound is very much distorted and clicks appear quite often. (I have attached the source code I used for testing it below). The test data I had was a file sampled

Hi Jean-Marc, I reported this bug a couple of months ago and either it got lost or I just didn't make my case very well. Let me see if I can explain why "speex_resampler_process_interleaved_int" and "speex_resampler_process_interleaved_float" in the resampler have a problem. If you call "speex_resampler_process_interleaved_int" with a small

Hi, I've noticed that the opus-tools is using a really old version of Speex's resampler code - a version that I've seen fail in the wild first-hand under low resource circumstances. I've actually submitted patches for some issues in the Speex resampler a while ago (and IIRC they were accepted): http://lists.xiph.org/pipermail/speex-dev/2009-November/007541.html ,

The resampler will convert raw audio from one sample rate to another. You are starting with Speex-encoded audio frames. So, what you need to do is: 1. Run the media frames through the Speex decoder (look at Speexdec or testenc_uwb). This will give you raw audio with a 32 KHz sample rate. 2. Use the resampler to convert the audio from 32 KHz to 8 KHz sample rate. 3. Run the 8KHz audio

Hi, I just built a sample application with speex resampler in linux and I tried to resample 8K sine wave tone mono to 48k using speex_resample_process_int. I am using a tool called EAQUAL for audio quality. I find the quality of Speex resampler to be decreasing when I increase the quality q of the resampler init function. Can some one give me pointers regarding this?? As per the API, if the

Hi, *"That's in general not very reliable. You can get PEAQ to say all sorts of silly things." Can you provide me links for any more effective tools other than PEAQ? Which is more reliable for Speex resampler? * *"strongly suspect that it's just not compensating for the delay introduced by the resampler. Because higher quality means higher delay, you'd find that PEAQ

Hi everyone, I recently began using libspeex 1.2 Beta 1 on Windows using MS Visual C++. I have gotten a decoder and an encoder to work fine from the excellent sample code posted at the website. But I face a problem. I am working on using Speex in a program to play and create audio books encoded using Speex (currently testing it only; for these tests, I do not use Ogg to save the encoded

Alexander Chemeris wrote: > Hi, > > Here are some questions from user point of view. :) > > On 5/29/08, Thorvald Natvig <thorvald at natvig.com> wrote: > >> I've done listening tests when converting wb_male.wav to 44.1, 48 and 8khz, >> and there aren't any obvious artifacts. I also did a 16=>16 test, and the >> results are delayed by 10ms

Attached is a snapshot of work-in-progress of a FFT based resampler. At the moment it works in floating point only, and only basic quality inspection has been done. Some benchmarks comparing the filter-based resampler at Q3 with the FFT resampler with overlap = in_len / 2, using 20ms chunks of data. (-O3 -ffast-math, FFTW3, gcc 4.3.0 on x86_64) 16=>48: 59us vs 19us 16=>44.1: 204us vs

Hi, I just started to examine the DIV32_16 function (Blackfin ASM version), and wondered why the return value of the function inside 'fixed_bfin.h' is of type 'spx_word16_t', but the local variable 'res' which is returned by this function is of type 'spx_word32_t'. Is this a trick of optimization or a bug? (Same question for PDIV32_16 and MAX16, too!) best

There is a bug in "speex_resampler_process_interleaved_int" and "speex_resampler_process_interleaved_float" in the resampler. It seems that when "speex_resampler_process_int" is called for the first channel, "in_len" is set to the actual number of samples used (when output limited), which you would think would be OK to use for all the subsequent calls

Hi, I tried to figure out what the problem is -- but it seems to be totally different from what I expected. My status at the moment is: - computing results for "generic" and "Blackfin ASM" versions of the DIV32_16 function are the same, there is no "algorithmic bug" - Instead, there seems some sort of memory corruption: When I comment out the DIV32_16 function

Hi Jean-Marc, Thanks for taking a look. I've added an example program in the patches that changes the rate frequently. You can run test-resample2 >test.raw and open in audacity or so to look at the spectrum etc. I've attached a before/after screenshot. In theory, depending on the current phase and the rate changes that are applied, the error can be audible as a pop when changing

Hi all, I have a couple of questions about the speex resampler: 1. Can a resampler state be used to process frames belonging to several audio streams? I would guess that there is information about the audio streams stored in the state so the answer is no, but it would be good to have some confirmation. 2. What is the best way to reset a resampler state? speex_resampler_reset_mem appears

Ok. I did some quality tests. First off; never do quality tests with ints. I had serious problems interpreting my results until it dawned on me that the signal differences were just 0 or 1. So, after a lot of scratching my head, these are done comparing the result from the _float versions (which is how both resamplers work internally anyway). What I did was this: Load speex_wb.wav as one

Colin, If you're using stereo audio with the resampler, there is a bug that can occur under certain situations (and maybe that's what's been happening to you). Check out: http://lists.xiph.org/pipermail/speex-dev/2009-August/007406.html With that patch, I've used the resampler extensively in many situations without any problems. John Ridges On 12/3/2010 1:00 PM,

Hi Jean-Marc, didn't get a reply to my last post (see below) -- do you have no idea what happens here? After some more tests, I disabled the DIV32_16 Blackfin optimizations and now get good quality on the Blackfin. But when I have overdrive on the input, things become very bad -- I'm not sure if this is really a filter stability issue like I wrote some weeks ago. I use the speex

Hi, Here's an updated resampler patch against current SVN. It includes SSE and SSE2 optimizations (the latter if included by _USE_SSE2). Best regards, Thorvald -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: speex-resampler-update.diff Url: http://lists.xiph.org/pipermail/speex-dev/attachments/20080426/e055077f/attachment-0001.txt

Hi, These patches improve the resampler set_rate function. The first 2 patches do some cleanups in the GCD calculation and avoid an overflow when calculating the new phase. This patch could probably be simplified if we allowed 64bits operations in speexdsp. The 3rd patch avoid rounding errors in the phase calculation. The problem is that the new rate is calculated with the reduced rate, which