similar to: Sphinx work-in-progress sourcecode

Hmm, the delay caused by the filters in the speex UWB mode seems to be 509 samples. I used the GoldWave editor to determine the offset. I have always been confused by the SNR output in the testenc source code. It did not make sense because it uses a 640 (=FRAME_SIZE) offset for its SNR calculations. After changing the calculation method, the SNR readings are much better. I may decide to adjust my

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++) {

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

Hey. The problems with Levinson -type algorithms and integrization are well known. Older codecs have usually solved the problem by using Schur decomposition for inversion of the autocorrelation matrix instead of Levinson. Another solution sometimes used is to use double precision - in this case you probably could code some pseudo-64bit implementation (using only 32bit commands), but that

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. I have now replaced all steps up to including the estimation of the LPC filter coefficients with integer code. That is about a quarter of the total work completed, I would say. One problem that i

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, 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 \

When built with --with-fft=gpl-fftw3, libspeexdsp is not linked with libfftw3, while it uses symbols from it. This means every object linked with libspeexdsp should also be linked with libfftw3, but it is not something reflected in the pkgconfig file. Instead, link libspeexdsp with libfftw3 when --with-fft=gpl-fftw3, and remove explicit link with libfftw3 in objects build by the speex Makefile.

Hello. I want to compile trunk speex. ./configure --prefix=/opt/speex --enable-option-checking --disable-silent-rules --disable-maintainer-mode \ --enable-shared=yes --enable-static=yes --enable-fast-install=yes --enable-dependency-tracking \ --enable-libtool-lock --enable-valgrind --enable-sse --enable-binaries --enable-vbr \ --disable-fixed-point-debug --enable-vorbis-psy --with-pic

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

Hello All, I would be very interested to have your ideas to port the vorbis lib ( part of lib at least) on a DSP TMS320C5409 (running @ 90Mhz). I have reviewed messages and URLs related to: - 'ivdev' Integerized Vorbis Project - Ogg-on-a-Chip Project This is very interesting. In my case I think the best approach would be , in order to shorten porting work & time, to recompile the

Hi, there ! I'm pretty sure that the following text (and attached picture) explains the reason for the gain of high frequencies. when quantizing a vector scalar by scalar by simply rounding each scalar to the nearest level, the quantization-error-vector and the original signal-vector can be assumed to be orthogonal (average case) This is a problem when we want to preserve the energy level

Hi, This question is related to the bwplot issue I reported yesterday. I have a 3 factors (2x3x2) dataset that I collapsed into a 2 factors dataset (3x2 = sizexModality). For size==small, I have 2 observations per subject (Snr), for the other sizes only 1. I reckoned that aov (and underneath, lm) might handle this as it should, since the subjects are idendified, when I do > aov(

I'm trying to get these cleaned up and landed, but I'm running into some trouble with this patch. Using commit a08b29d88e3c (July 21) of Ne10, I'm seeing test failures for 60-point FFTs: nfft=60 inverse=0,snr = -3.312408 ** poor snr: -3.312408 ** nfft=60 inverse=1,snr = -16.079597 ** poor snr: -16.079597 ** All other sizes tested appear to work fine (84 to 140 dB of SNR). This