similar to: delay issues in speex, integer API

Since two people have asked me to open the source code on my work-in-progress Integer Speex project, I have put it up onto my site www.openacm.org as a download in the project tree. the suggested directory structure is as follows, i.e. the speex source folder should be on the same directory level as the sphinx filder. peex-1.0.1 (ideally the folder from within the SpeexACM source archive)

There is actually a mail missing - the version with the pipedinputstream construction. attached the current source with pipedinputstream/pipedoutputstream tia, ulrich <p><p> -------------- next part -------------- A non-text attachment was scrubbed... Name: TestClient.java Type: text/x-java Size: 14939 bytes Desc: TestClient.java Url :

I there was a discussion on the vorbis list about Real Audio SureStream (tm) format. The basic idea was that they put multiple RA files with different compression levels. So when they have to switch the bit rate due to bandwidth changes, they choose from the streams they have. Since peeling is a long time away, it could be implemented with ogg vorbis multiplexing several times the same

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

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 flac-users, I'm storing my ripped CDs on FLAC until Vorbis 1.0 gets out (supposedly RSN). But I want to enter the vorbis comment just once. Since I'll use ogg bitstream for both files, I was wondering if I could use vorbiscomment or tOGGer on ogg-flac files? Is there any tool (besides de pipe) to convert ogg-flac to ogg-vorbis? Best regards, Alejandro Belluscio

Hello flac-users, I'm storing my ripped CDs on FLAC until Vorbis 1.0 gets out (supposedly RSN). But I want to enter the vorbis comment just once. Since I'll use ogg bitstream for both files, I was wondering if I could use vorbiscomment or tOGGer on ogg-flac files? Is there any tool (besides de pipe) to convert ogg-flac to ogg-vorbis? Best regards, Alejandro Belluscio

Hi list! There seem to be some oddities in using ABR. The first thing I notice is that because "abr_count" increases without bound, after a while the weight of the bitrate history will completely swamp any change in the current bitrate and the ABR adjustment will essentially stop happening. This seems to be true in any mode (not just UWB) and perhaps a solution is to cap

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 am trying to join my Linux workstation to my ADS domain. Unfortunately, I'm not having much success. net ads join hangs forever (or at least for more than 12 hours) when run. The computer account is created in the domain, but the process never completes. tdbdump secrets.tdb shows no results, and wbinfo shows users and groups from the trusted domains but not from the domain I am trying to

Hi, No, it only happens with speex_wb_mode. But like I said, it is because in wideband mode, the function sb_encoder_init is called and this function initializes the sampling rate using speex_*de*coder_ctl instead of speex_*en*coder_ctl In narrowband mode, the sampling rate is just initialized to 8000 st->sampling_rate=8000; BTW, I saw that my email was added to an existing thread instead of

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