similar to: Results of Automated Batch Tests

The results are at www.rational.co.za/speex.csv Each of the 11 quality settings is tested 3 times (narrow, wide and ultra wide band). Strangely narrow band quality 11 outperforms all wide band tests, but it can be due to my subsampling or some other inaudible effect like delaying. You can import it into Excel and sort it by SNR or other value. Divide the bits by 24 to get the bps. The

Sounds like a great idea, except for the part about only running on linux/cygwin. What would you need in order to make it cross-platform, as libspeex is? "Nic Roets" <speex@rational.co.za> wrote: > > I'm working on a patch that will batch test most of the code in > libspeex. Here's the process (Feel free to suggest changes) : > 1. Download the

I was also wondering if there is a standard set of input sequences people are using to test Speex. I haven't stumbled upon it/them yet. > -----Original Message----- > From: owner-speex-dev@xiph.org [mailto:owner-speex-dev@xiph.org]On > Behalf Of Jean-Marc Valin > Sent: Tuesday, February 25, 2003 7:24 PM > To: speex > Subject: Re: [speex-dev] Quality > > > > I

> I was wondering if the developers were using anything to "objectively" test > the quality of the speex vocoder. For instance PSQM or one of the many > derivatives. Mean Opinion Scoring seems an expensive route. > > Is there some open source software to use for this? Well, I haven't found and open-source perceptual testing software, so I've relied so far

Le mer 26/02/2003 à 15:43, Rick Kane a écrit : > I was also wondering if there is a standard set of input sequences people > are using to test Speex. I haven't stumbled upon it/them yet. I've got a few samples at: http://www.speex.org/audio/samples/ Jean-Marc > > -----Original Message----- > > From: owner-speex-dev@xiph.org [mailto:owner-speex-dev@xiph.org]On

Hi Jim, First of all - thanks, turning the highpass filter off was what I needed, and the waveforms match now. But, when i did the PESQ tests again I found an interesting result : version 1.0.5 still got a slightly better average score, but the standard deviation on version 1.2 beta1 was much smaller. The cause for that is this - on some samples versions 1.0.5 and 1.2beta2 produced a single

Hi Aviv, Does the audio sound bad? You can try turning off the highpass filter (which was not in 1.0.5). This code is from ti/testenc-TI-C5x.c in the source tree: /* Turn this off if you want to measure SNR (on by default) */ tmp=0; speex_encoder_ctl(st, SPEEX_SET_HIGHPASS, &tmp); speex_decoder_ctl(dec, SPEEX_SET_HIGHPASS, &tmp); - Jim ----- Original Message ----- From:

Hello Jean-Marc, **Resending.. not sure why subject got removed earlier** Below are the results that show test_unit_dft passes, but test_unit_mdct fails (only for nfft=480, 960, 1920) Note: Tested on BeagleboneBlack(Cortex-A8) fixed point on branch [1] ./test_unit_dft nfft=32 inverse=0,snr = 88.394372 nfft=32 inverse=1,snr = 93.896470 nfft=128 inverse=0,snr = 89.185895 nfft=128 inverse=1,snr =

Hi, Can you apply this change to the MDCT test and run it again. See if more (all) sizes pass. Given the results, I strongly suspect an overflow. Jean-Marc On 08/05/15 01:21 PM, Viswanath Puttagunta wrote: > Hello Jean-Marc, > > Below are the results that show test_unit_dft passes, but > test_unit_mdct fails (only for nfft=480, 960, 1920) > Note: Tested on

Hello Jean-Marc, Yep, that was it.. with your patch, test_unit_mdct passes for all nfft. So, what you do you suggest the next step here is? Regards, Vish On 8 May 2015 at 12:30, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi, > > Can you apply this change to the MDCT test and run it again. See if more > (all) sizes pass. Given the results, I strongly suspect an

Hello Jean-Marc, Below are the results that show test_unit_dft passes, but test_unit_mdct fails (only for nfft=480, 960, 1920) Note: Tested on BeagleboneBlack(Cortex-A8) fixed point on branch [1] ./test_unit_dft nfft=32 inverse=0,snr = 88.394372 nfft=32 inverse=1,snr = 93.896470 nfft=128 inverse=0,snr = 89.185895 nfft=128 inverse=1,snr = 93.537021 nfft=256 inverse=0,snr = 88.353151 nfft=256

On Wed, Feb 5, 2014 at 11:05 AM, Marcello Caramma (mcaramma) <mcaramma at cisco.com> wrote: > Hi, > > Apologies if this is a known issue, but running make on revision e3187444692195957eb66989622c7b1ad8448b06 fails one of the tests when using fixed point configuration (floating point is ok) on my linux x86. > Note that libopus1.1, as extracted from the tar ball, is OK. > >

Hi, I have been using speex version 1.0.5 on a text-to-speech program. Recently I upgraded to version 1.2beta1 and noticed that the waveform the I got after encoding and decoding on the new versions (beta1,beta2) is much more different than the original than on version 1.0.5. I also ran a PESQ comparison test on 700 voice samples and got better results in the older version (I used quality 9, and

Hi, Apologies if this is a known issue, but running make on revision e3187444692195957eb66989622c7b1ad8448b06 fails one of the tests when using fixed point configuration (floating point is ok) on my linux x86. Note that libopus1.1, as extracted from the tar ball, is OK. Specifically, the tests that fail are in celt/tests/test_unit_mdct: nfft=32 inverse=0,snr = 85.341197 nfft=32 inverse=1,snr =

Hello, I'm building packages for Slackware and I've just tried to upgrade Slackware 13.37's CELT package to version 0.11.3, which apparently was released last year, but I've omitted it because it was not announced on the site. Anyway, now that I try build with the following configuration in my SlackBuild script: CFLAGS=$SLKCFLAGS -O2 \ CXXFLAGS=$SLKCFLAGS -O2 \

I quote from "Principles of Digital Audio" by Ken C. Pohlmann: "Because perceptual coders tailor the coded signal to the ear's acuity, they similarly tailor the required response of the playback system itself. Live music does not pass through amplifiers and loudspeakers, it goes directly to the ear. But recorded music must pass through the playback signal chain. Much of the

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

I commend you to (a) the recent article by Doug Bates on "Fitting nonlinear mixed models in R" pp. 27-30 in the latest issue of "R News" available from "www.r-project.org" -> Newsletter and (b) Doug's book with Pinheiro (2000) Mixed-Effects Models in S and S-PLUS (Springer). I suggest you try the same analysis using in "lmer", library(lme4), and

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

Hi all, I'm new to the group. I'm looking at the speex code with an eye towards maybe helping out with either codec optimization or fixed-point implementation, The SNR calculation in testenc.c and testenc_uwb.c doesn't make sense to me. The code is { float enoise=0, esig=0, snr; for (i=0;i<FRAME_SIZE;i++) {