similar to: At last : Speex without floating point

I see there are still some floating point operations left in the codec init(ialization) code. Changing that code to fixed point is not only difficult (due to the trigonometric functions etc) but may also degrade the precision. Here is an idea whereby we can easily precompute (record) all those values on a powerful processor and then use (replay) them on an embedded processor / DSP. The only

The resampler will convert raw audio from one sample rate to another. You are starting with Speex-encoded audio frames. So, what you need to do is: 1. Run the media frames through the Speex decoder (look at Speexdec or testenc_uwb). This will give you raw audio with a 32 KHz sample rate. 2. Use the resampler to convert the audio from 32 KHz to 8 KHz sample rate. 3. Run the 8KHz audio

Hi List, Now I will send to you more specific what I am trying to do. I have one Asterisk Channel where receives Midia Frames in the codecs format: Speex UltraWideBand and Speex NarrowBand. When I use Speex NarrowBand the Asterisk is able to convert this frame to G711. But when I use Speex UltraWideBand the Asterisk don't convert it. Then I need in my Asterisk Channel Source include the Speex

Hi there. I noticed that the speex.org website does not appear to give a table of what bitrates you can expect when using the SPEEX codec in CBR (quality) mode. I have created a table for all modes, giving the bitrate for two cases. a) all coded frames saved consecutively in bitstream b) all coded frames saved with byte alignment You can see there is significant padding loss at some (lower)

If you're on the new Makefile system, you will want to update your Makefile.rules. The patch below provides some important fixes for parallel builds and dependencies. It also adds some new features like the -local targets. For example, you can now build "all-local" to build the local directory without recursing into subdirectories. See the comments below for details of the change.

Hi, I found this list of Speex bitrates in the mail archive. http://www.xiph.org/archives/speex-dev/200306/0004.html Can somebody confirm that this list is correct? I am wondering about the following: - On the Speex website it says: "Speex is based on CELP and is designed to compress voice at bitrates ranging from 2 to 44 kbps." while the bitrates listed here are e.g. 84400 for

Final Step: REPLY to this message to CONFIRM your subscription to: internet.com Daily (HTML) InternetNews Business Report (HTML) NewsLinx (HTML) boston.internet.com (HTML) dc.internet.com (HTML) SiliconValley (HTML) Flash Kit (HTML) JavaScript.com (HTML) SMW News (HTML) ScriptSearch Daily (HTML) WebReference Update (HTML) Webdeveloper Weekly (HTML) ASPnews (HTML) ISP-Planet (HTML) ECommerce-Guide

Hi Peter, Have you considered resampling the raw 44.1kHz stereo source files using a program such as http://audacity.sourceforge.net/, say to 16kHz mono or 32kHz mono, and then using the wideband or ultrawideband speex modes to encode the result? Alternatively, if you want to programmatically do the resampling yourself, you could try the new resampling API in the svn head of speex, or the GPL

There's a field in the SDP description for narrowband/wideband/ultrawideband. Jean-Marc lianghu xu wrote: > if the new draft in the manual is used. I don't find how to tell the > decoder which mode(NB/WB/UWB) is used > in the encoder. The RTP header don't contain the mode field and I don't > find the mode information in the > coded frame either. > >

________________________________ Hi David, Thank you very much for your reply. Since I need to resample the audio in the program itself, I decided to try out the resampling API in speex. But now, I have another problem. The resampled sound is very much distorted and clicks appear quite often. (I have attached the source code I used for testing it below). The test data I had was a file sampled

Hi, a while back I wrote that the llvm makefiles didn't create the correct kind of file for use on darwin with -load. Since then, both the shared library and makefile system have been overhauled significantly. So I checked again - as updated from CVS, the current makefiles don't build the right object type on darwin. If you follow the advice of 'Writing an LLVM Pass" tutorial,

Here my comments: Page 3: To be compliant with this specification, implementations MUST support 8 kHz sampling rate (narrowband)" and SHOULD support 8 kbps bitrate. The sampling rate MUST be 8, 16 or 32 kHz. There is a type above after (narrowband), there is a " extra character. I don't understand what is the motivation to specify "SHOULD support 8 kbps

On Wed, 16 May 2007, Jean-Marc Valin wrote: >>> The main idea is that Speex supports many bit-rates, but for one reason >>> or another, some modes may be left out in implementations (e.g. for RAM >>> or network reasons). What we're saying here is that you should make an >>> effoft to at least support (and offer) the 8 kbps mode to maximise >>>

Yep, it sounds like a good solution, and it works for me - thanks! -mike On Mon, 10 Jan 2005 20:40:34 -0800, Reid Spencer <reid at x10sys.com> wrote: > Michael, > > I've implemented a LOADABLE_MODULE feature in the makefiles: > > http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050110/023147.html > > The approach taken is almost what you described

Hi list, I am researcher in VoIP Applications and my challenge now is convert one RTP data frame that is in 32KHz to other RTP data frame in 32KHz. Do someone help me about it? Very thanks, Thiago. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20090316/fbbaf566/attachment.htm

comment inline. On Wed, 16 May 2007, Jean-Marc Valin wrote: >> Page 3: >> >> To be compliant with this specification, implementations MUST support >> 8 kHz sampling rate (narrowband)" and SHOULD support 8 kbps bitrate. >> The sampling rate MUST be 8, 16 or 32 kHz. >> >> There is a type above after (narrowband), there is a " extra

Michael, I've implemented a LOADABLE_MODULE feature in the makefiles: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20050110/023147.html The approach taken is almost what you described below. However, I want to retain the distinction between a "regular" shared library and one that can be dlopened. So, if you specify SHARED_LIBRARY=1 you get a regular shared library

> Page 3: > > To be compliant with this specification, implementations MUST support > 8 kHz sampling rate (narrowband)" and SHOULD support 8 kbps bitrate. > The sampling rate MUST be 8, 16 or 32 kHz. > > There is a type above after (narrowband), there is a " extra character. > > I don't understand what is the motivation to specify "SHOULD

>> The main idea is that Speex supports many bit-rates, but for one reason >> or another, some modes may be left out in implementations (e.g. for RAM >> or network reasons). What we're saying here is that you should make an >> effoft to at least support (and offer) the 8 kbps mode to maximise >> compatibility. > > I understood this. But as you may know: the

I realize that hearing tests are far superior for calibrating codec internals, particularly the perceptual enhancement. The tester is for finding gross mistakes like overflows. The test program includes code to subsample the 32Khz source down to 8 and 18 Khz. I've broadend the tests to try all the possibilities like VBR, perceptual enhancement, complexity and quality. The results are