similar to: Decoding raw problem on OS X with 1.03

> If I decode to .wav, it works fine. However, if I decode to .raw, it > does not work (the decoded file when viewed on GoldWave on Windows > appears to be all noise. I've tried 16-bit, signed, unsigned, big > endian and little endian, mono and stereo PCM - none make a difference > - the decoded file always appears to be noise). Can you try manually swapping the bytes on

I noticed a little while back that Andrew@teledesign.co.uk posted he was going to port the speex onto a TI DSP. Any news on this or similar developements? --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'speex-dev-request@xiph.org' containing only the word 'unsubscribe' in

Wade, We have already done Altivec support for most of Speex. The patch is waiting on Jean-Marc adding the RunTime / Compile Time options so it doesn't crash systems that don't support Altivec such as G3's or early G4's. Aron Rosenberg SightSpeed www.sightspeed.com <p>At 09:20 PM 3/29/2004, Wade Williams wrote: >On Mar 29, 2004, at 5:05 PM, Jean-Marc Valin

On Mar 29, 2004, at 5:05 PM, Jean-Marc Valin wrote: > Can you try manually swapping the bytes on the raw output and see if > you > get something useful (I think by default wav is always little endian > while raw is native endian)? Well, my apologies. Apparently I got confused when trying all the different formats and somehow skipped little endian. The decoded raw file is in

Hello Jean-Marc and all, I recently had a talk with somebody about CELP. He said, there is this federal standard 1016 (4.8kbps) with a reference implementation of the Department of Defense (only on Sun, unfortunately, if I got this right). This one is noticed in the manual already. He also said, since there is this implementation of the DoD, nobody would voluntarily re-implement CELP. If I read

Hi there, I've just started to work with the great speex encoder on ARM9-based embedded platform. This is my configuration: CPU: Cirrus Logic EP9315 @ 200 MHz (ARM920T) o.s.: Linux 2.6.9-rc2-ep93xx GCC: gcc version 3.3.3 (DENX ELDK 3.1 3.3.3-10) without MaverickCrunch support ogg library: 1.0 speex command line configuration: ./configure --enable-fixed-point --enable-arm4-asm The code is

Hello, HawkVoice doesn't have a 6.3kbps codec for CELP, it has a 4.5kbps CELP codec and I do not believe it is being used by TeamSpeak. The 6.4kbps CELP being used in TeamSpeak, to which you are referring I believe comes from Lernout & Hauspie's LHACM.ACM file which it appears you are redistributing (I assume TeamSpeak has a license and permission to do this). The only people I

Without seeing some examples of your Speex implementation, it would be difficult to comment. I can tell you that you need to make that the conversion between floating point and fixed is done properly. This seems to be a common problem. Also, I am confident that TeamSpeak is using LHACM.ACM and distributing it. While HawkVoice is being distributed, it doesn't appear to be used at all.

Am Dienstag, 13. Mai 2003 03:22 schrieb Allen Drennan: > Hello, > > HawkVoice doesn't have a 6.3kbps codec for CELP, it has a 4.5kbps CELP > codec and I do not believe it is being used by TeamSpeak. The 6.4kbps CELP > being used in TeamSpeak, to which you are referring I believe comes from > Lernout & Hauspie's LHACM.ACM file which it appears you are redistributing

Hello kind developers, I am planning on creating a steganographic extension for speex/CELP. Since speex/CELP is lossy, there should be quite many bits that one can use for hiding data. I'm familiar with the principles of CELP (two filter loops, one for pitch, the other for formants, let the raw speech frame run through those filter loops, take residue signal, map it on a codebook entry,

> I am planning on creating a steganographic extension for speex/CELP. > Since speex/CELP is lossy, there should be quite many bits that one > can use for hiding data. Quite the opposite. Speex uses very few bits, so every bit you corrupt is likely to be heard. You would need to use "fractions of bits" at a time. Even then, it may be hard to hide data efficiently (so it's

Jean-Marc, I am building a tool for producing the highest possible quality Internet interviews for "podcasting" applications. The goal is to produce a perfect recording of an interview or conference -- and giving the participants a glitch-free experience is secondary. My approach, therefore, is to build a Windows "wave" file asynchronously by using a streaming

I've been following this kist for a while now and I suppose I had better introduce myself. This is going to be rather a long message, but that can't be avoided. My name is Andrew Baker and I work for a company called TeleDesign. We are based in the UK. http//www.teledesign.co.uk I have lots of experience with telecomms, a fair bit with VoIP, quite a bit (but rather less recent) with

Hello, Jean-Marc Valin schrieb: >>I am planning on creating a steganographic extension for speex/CELP. >>Since speex/CELP is lossy, there should be quite many bits that one >>can use for hiding data. > > Quite the opposite. Speex uses very few bits, so every bit you corrupt > is likely to be heard. You would need to use "fractions of bits" at a > time.

I downloaded speex-1.2beta3-win32 binaries, and used the speexenc.exe and speexdec to process the file male.wav download from http://speex.org/samples I used both the narrowband and ultra-wideband mode: >speexenc -n --quality 3 male.wav n3.spx Encoding 8000 Hz audio using narrowband mode (mono) >speexdec n3.spx n3.wav Decoding 8000 Hz audio using narrowband mode (mono) Encoded with Speex

thanks for the support.i am a masters student who is doing thesis to work on the CELP algorithm specifically calculating the time,space complexities of the algorithm.so i jus need your help i.e if u can show me the site or forward the material where i can get the time the calculated time complexity of your Speex CELP algorithm and i can pick it from there.PLEASE Send instant messages to your

Hello! I should have asked this earlier, but... :) We're returning to voice processing in our app now, in which we're trying to achieve n-way full duplex voice in a 3d environment. Since Speex is a single voice stream CODEC, we've been looking at having each client upload its stream to the servers, which multiplex several spatially nearby active channels back down to the

Dear Jean-Mark, I am using your really amazing speex codec with success for a year in my narrow-band, cryptographic voip application (it is in testing phase only). In literature, I have found some so called "IP Over Voice" (IOV, IPOV) theory, which utilizes a CELP codec in inverse, transmitting any random digital data as CELP synthetized voice though any voice transmitter channels (CB

(This is almost out of topic but anyway...) It is surprising how little research effort have been put into psy-acou models for CELP. The basic problem lies in that it is not easy to alter the LP model without distroying the minimum-phase property (ie. the stability of the predictor). That leaves us with psy-acou modelling of the noise-part only. However, my own research is in constrained

Hi, Speex Fans, I collected the speex raw file from flash server and tried to decode it with samepldec.c ( I modified the code the file input) as below. speex rate=8khz, one framesize=10 bytes in the client, When I ran the decoding program, it kept displaying the error below and the file genertaed is corrupt too. Please help point out what is wrong. I also attach the raw speex file. Thanks,