similar to: NB decode in SB

Because a wideband signal has both a narrowband part and a wideband part the first part of the wideband decode is to call the narrowband decode. In the fixed point version the signal generated from the narrowband decode is downshifted at the end. In this same version the wideband then upshifts the signal by the same amount. I would like to do away with the downshift on the narrowband side

Jean-Marc, What exactly does the speex code do to calculate the granulepos? With vorbis it's the 'count of decodable samples including this packet'. So if you had a packet that allowed you to decode 1024 samples since the beginning of playback, the granulepos is 1024, not for example 1023 which would be the *index* of the last sample assuming C-style array indicies starting at

It looks like I'll need to go further into the guts of speex to do this. I do, however, see some lines in nb_celp.c/nb_decode() that look interesting. I guess I'll play with it. I doubt that it will be terribly clean, though. Jean-Marc: Take a look at line 1195 in nb_celp.c (CVS). It reads "speex_warning ("More than to wideband layers found: corrupted

Le mar 18/11/2003 à 17:39, Allen Drennan a écrit : > Speaking of video conferencing in conjunction with Speex, we are > currently beta testing a solution we developed that offers multi-point, > multi-party video and audio using the Speex engine for voice. > > http://www.wiredred.com/downloads/ecsetup.exe > > The fair and good audio settings are Speex narrowband, high quality

Hi, 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 lowering the

Peter Saint-Andre a ?crit : > Ivo Emanuel Gon?alves wrote: >> Just a heads-up, I received confirmation that Speex is now the default >> codec for the Jabber's Jingle VoIP protocol. > > Which we hope to finalize soon for broader adoption. :) That's good to hear. Are you supporting wideband or just narrowband? Jean-Marc

> The mode/bit-rate is detected automatically by the decoder because it's > encoded in the first few bits of each frame. The encoder can change > bit-rate at any time without telling the decoder. Can you be more > precise as to what isn't clear? I think that one got me too. If mode is detected automatically by the decoder, what is the purpose of the 'mode' parameter

In a "normal" frame that doesn't have in-band signalling (which nobody seems to use anyway), the frame starts with the narrowband information. If the frame is in wideband, then this will be followed by a bit of wideband information that starts with a bit set to 1 (narrowband starts with a bit set to 0). Have a look at what the Speex decoder does. You may actually want to have similar

FYI, the Asterisk software PBX <http://www.asterisk.org/> has now incorporated my recent patches to support dynamic RTP payload types. As a consequence, its SIP implementation now supports Speex, so if you have a Speex-compatible SIP client, you can use it to make calls using Asterisk. Some caveats: - Only narrowband (8 kHz) Speex is currently supported; not wideband. (Unfortunately,

Do not forget to add the "Copying conditions" to the RFC. Check http://wiki.debian.org/NonFreeIETFDocuments That page contains a section titled "Template for RFC authors to release additional rights". To follow that guideline a section like the following should be added: x. Copying conditions The author(s) agree to grant third parties the irrevocable right to

>> Consider a device that only has enough ROM to store one set of >> quantization tables (the limitation could also be about speed, network, >> ...). If you specify MUST be able to decode, then it means that this >> device simply *cannot* implement the spec *at all*. This is bad for >> interoperability. > > For me: device which don't have all mode

Hi, The notch filter in AEC is only used to remove DC signal, and the time of convergence is not important, right? If so, I think preset value of notch_radius is too small, and it causes noticeable distortion(freq < 200hz cut). There is a picture in attachment to show signals under different radius in time-domain. By setting notch_radius to 0.999 for all sampling rates, I found better

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 complexity) and some wideband modes also work (up to ~20 kbps) at

Hi Jean-Marc and list, I'm trying to negotiate speex with SIP/SDP and get some trouble understanding the "mode" parameter: mode: Speex encoding mode. Can be {1,2,3,4,5,6,any} defaults to 3 in narrowband, 6 in wide and ultra-wide. Is mode equivalent to the "quality" parameter of speex? In this case, I don't understand why mode is not from 1 to 10... Just

Is there any way to access only the narrowband portion of a wideband stream? I'd like to be able to encode the audio only once, but allow members in a conference to have some rough selection of bandwidth, and allow them to move to a lower-bitrate stream if there is a need to do so. Thanks, Matthias -- Matthias Granberry matthias@utdallas.edu (469) 371-0596 --- >8 ---- List archives:

Hi, Is there an easy way to get the size in samples of a Speex packet, without decoding the packet? If I receive a "narrowband packet" with - Zero or more wideband frames (must be skipped apparently) - Zero or more Speex inband requests - Zero or more user inband requests - One or more narrowband frames I need to know how much samples the packet contains to calculate jitter buffer

Hi! In a message posted on May 31 Jean-Marc wrote in a topic about AEC: > - set sampling rate to 8 kHz (at least for now) Does it mean that echo cancellation algorithm won't work in wideband mode? I can't get aec to work well in my application and I am wondering whether it's not a matter of using wideband instead of (preferred?) narrowband mode? Thanks in advance for any

Hi all We are about to send an updated version of the internet draft "RTP Payload Format for the Speex Codec" to the IETF AVT working group. Before submitting we would like your input, if you have any comments or input please send them to the mailing list. If we don't get any comments in 1 week (by 22. May 2007) we will go ahead and submit it to the IETF. Of course you can comment

On Wed, 6 Dec 2006, lianghu xu wrote: > Hi Jean-Marc, > > I remember you said that the SDP tells the mode information. Right. But a decoder like speex can always be configured from information contained in the incoming stream. That makes your application more interroperable. Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 -

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