similar to: difference with NB and WB

This is a really good point, and definitely a recurring theme on this mailing list. :) I wonder, what are some better options for handling this issue, other than to keep saying "just use 8/16/32kHz"? - Extend Speex to support other sample rates (seems unlikely..?) - Integrate a resampling algorithm into libspeex - Maintain a list of recommended resampling libraries that work well

Ok here is something I couldn't see on the description page. We need to convert to 8 bit audio right? I'm assuming narrow band is 8 KHz 8 bit. Wide band is 16 KHz 8 bit. UW band is 32 KHz 8 bit audio? George -----Original Message----- From: Tom Grandgent [mailto:tgrand@canvaslink.com] Sent: Tuesday, October 03, 2006 11:42 AM To: Bertie Coopersmith; George Ou Cc: speex-dev@xiph.org

Please consider using 16-bit 16kHz (wideband) instead. It's a huge increase in audio quality and the bitrate is still very low, especially if you take advantage of Speex features such as VBR. 8kHz seems totally inappropriate to me for desktop streaming audio, let alone 8-bit samples. Or perhaps your recording equipment is an original Sound Blaster from 1989? (Even that could record at

Hi Bernhard, 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 kind of bug and/or invalid assumption

Jean-Marc Valin (jean-marc.valin@hermes.usherb.ca) wrote: > > > I've been using Speex in my voice-over-IP program on Win32, in > > wideband (16kHz) mode. I just starting using VBR recently and > > have run into something that might be a problem within Speex: > > Are you turning on DTX in addition to VBR? Also, what version are you > using. As of 1.0, DTX is

Kirk, Speex was designed for 8kHz, 16kHz, and 32kHz sample rates. If you don't use one of these sample rates, you'll be messing up important assumptions deep within the codec. Why these sample rates? It's telecommunications tradition, rather than PC audio tradition. If you want an efficient and high quality format for voice chat, try 16kHz with VBR quality 6. You should see

Hello all, I'm testing the Speex codec for my diploma thesis on a BF-533 Blackfin under uCLinux (2005R3 RC3 release). I successfully compiled the Speex (1.1.11-svn) and I can encode/decode wav-files on my STAMP-board using the speexenc/speexdec sample apps. But I encountered that the decoded file sounds strange/noisy, when compiling with "--enable-blackfin-asm" +

On Fri, Nov 14, 2008 at 3:57 AM, Vincent Burel <vincent.burel at vb-audio.com>wrote: > > Speech compression algorithms always are tunned to particular freq, > > else they would take tons of time. That's because they use knowledge > > that speech pitch (and other params) lies in well specified regions. > > Thus if you feed algorithm with wrong freq, you'll

Hi, I make an analysis sequence on R. In some cases the function glm.nb fail to ajust the model. Its Ok. The problem is that this error stop the program. I need treat this error and not stop the program. Something like this: ... model <- glm.nb(y~x,maxit=1000) if(glm.nb fail) { teste[i] <- 0 } else { teste[i] <- anova(modelo)$"P(>|Chi|)"[2] } ... I try this: ...

Hi Reed, I've been using Speex to transmit TTS for years. It works very well with no tweaking. I use Microsoft TTS ("Microsoft Mike") with Speex at 16kHz wideband and VBR quality 6. Sometimes I forget that the sound is even coming from another computer and being compressed+decompressed. If anything, TTS seems easier for Speex to deal with than real voice. But I don't

Hi, I make a model and have compared with null model. anova(mnull,m1) Model theta Resid. df 2xlog-lik test df LR stat. Pr(chi) 1 ... 0.39 161 -577.9129 NA NA NA 2 ... 1.30 150 -475.6839 1 vs 2 11 102.229 1.11e10-16 anova(m1) Df Deviance Resid. Df Resid. Dev P(>|chi|) NULL 161 282.139 9... ... ...

> I was wondering if anyone has experimented with Speex's wideband (16kHz) > mode at lower quality settings. In particular I have been using quality 3, > and with wideband input files the resultant frequency spectrum is limited to > about an upper end around 3.5kHz (almost telephony quality bandwidth). Has > anyone tried increasing the spectral bandwidth at the expense of

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

Jean-Marc Valin wrote: > Hi, > > I just released unstable version 1.1.2 that contains more fixed-point > work. Though it's still not 100% complete, enough have been done to make > it run in real-time on ARM. In order to do that, compile with > --enable-fixed-point --enable-arm-asm. All narrowband modes work in > real-time with complexity 1 (some work with higher

Hi, I make some simulations with rnbinom and try to test with glm.nb. But in some data set the glm.nb fail. Look: pop <- rnbinom(n=1000,size=1,mu=0.05) > glm.nb(pop~1,maxit=1000) Error in while ((it <- it + 1) < limit && abs(del) > eps) { : missing value where TRUE/FALSE needed look some pop charactetistics: > summary(pop) Min. 1st Qu. Median Mean 3rd Qu.

Hi Jean-Marc, I thought at quality 3 (wideband) - wb_submode1 that the 4-8k band was not using a codebook table. From the code I can see that some sort of "lsp" encoding is performed. What exactly does this encode? (I assume lsp means line-spectral pairs) The reason I am asking is I'm comparing the "effective" spectral bandwidth of Speex against the

Tom Grandgent wrote: > Have you tried using 16kHz wideband? The sound quality is far superior to > narrowband, IMO, even if you have to turn the VBR quality down (to say, 2) > to save bandwidth. Thanks for the info Tom! Probably narrowband is hurting me, but my system is currently built on that. I want to try to get acceptable performance from narrowband if possible before trying

Ok, I figured it out. :) This seems to work: 1) Call speex_bits_read_from() once, specifying the location in memory of the compressed data, and the total length of that data. 2) Keep calling speex_decode() until speex_bits_remaining() returns 0. Then you don't have to keep track of the # of frames per packet, or the size of each compressed frame. It's done magically by the codec.

I implemented the calcPower(). It works perfectly. The example is given you in just about 6 hours. Cant paste the whole source here and need to meet someone now. Thanks all (particulary tom). I try to figure out whitch problem exists with the #define SPEEX_PREPROCESS_SET_PROB_START 14 theese days ----- Original Message ----- From: "¼Õ½Â¿ø" <ssw0725@ncsoft.net> To: "Tom

Hi, We'd like to announce the first draft for the Speex RTP profile. It was written essentially by Greg Herlein, with some help from Simon Morlat and I. We'd like to get some feedback on it before it is sent to the IETF. Basically this will allow all SIP based VoIP applications using Speex to inter-operate. For those interested, there's already Simon's LinPhone (www.linphone.org)