similar to: spx1.1.10 speexenc compile

Hi Mon, I added 'misc.h' to the #includes in speexenc.c and commented out the declaration of 'le_int' in 'wav_io.h'. Then, it compiles and works fine. John Mo Win wrote: > Hi all, > > Been trying to compile speex 1.1.10's speexenc for win32 using Visual > C++ 6.0 but came up with some errors (abt 33 of them, syntax errors). I > just traced them to

OK, that was a stupid error in the le_int prototype. It's fixed in svn now. Jean-Marc Le mercredi 28 septembre 2005 ? 11:53 +1000, Jean-Marc Valin a ?crit : > OK, it seems like I screwed up the wav header code between 1.1.8 and > 1.1.9. Everything seems fine (playing to soundcard also works), except > that the length reported for the wav is too short, which is why it stops >

On Fri, Apr 4, 2008 at 12:19 AM, Jean-Marc Valin <jean-marc.valin at usherbrooke.ca> wrote: > Jahn, Ray (R.) a ?crit : > > > Dear Speex codec community: > > > > I am working on conversion of voice files. I could not figure out how to use speexdec.exe 1.2.3 in piped mode in order to avoid the creation of the potentially large intermediate *.wav or *.pcm files. Any

Hi, I just started using speex recently and I've been having problem with Speex ver. 1.1.10 decoder. I used Speex to encode a wav file to spx then decode it back to wav file to see the voice quality that results from different speex options. Somehow, I couldn't get the original wav file back. I used both Speex ver 1.1.6 and ver 1.1.10 to both encode and decode, despite the same output

Dear Jean-Marc and Peter: Thank you both very much for your time and advice. I did not realize that Lame MP3 code has a -r option (without reading its code). I have tried the suggested command lines verbatim with the added -r option, along with other combination of option settings. I could not figure out how to eliminate the distortion in the result, like voice turning either high or low

Hi, I have problems compiling speex 1.2rc1: > /opt/studio/SOS11/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I. - > I.. -I../include -I../include -I.. -I/opt/csw/include -I/opt/csw/ > include -xO3 -xarch=v8 -I/opt/csw/include -c skeleton.c > /bin/bash ../libtool --mode=link /opt/studio/SOS11/SUNWspro/bin/cc - > xO3 -xarch=v8 -I/opt/csw/include -xarch=v8 -L/opt/csw/lib -o

Hi Jean-Marc, Am 17.04.2009 um 13:35 schrieb Jean-Marc Valin: > It should be using getopt1.c when getopt isn't available.c. Can you > check why it doesn't? In any case, that's only required for the Ogg > tools, not for the library. config.log says ac_cv_func_getopt_long=no ac_cv_header_getopt_h=no ac_cv_lib_gnugetopt_getopt_long=no LIBOBJS='

hi, used speexenc (speex v.1.1.6) and checked the output .spx file... the header turned out to be different from what i expected based on the manual... was expecting it to start with Speex{3 spaces] but it starts with OggS... etc. The section 'Ogg File Format' in the manual says that the speex header is supposed to contain speex_string[Speex ], speex_version etc. but the 1st few bytes

The following patch (based off of the current CVS tree) is necessary to compile Speex on IRIX (or any other system that doesn't include getopt_long in the system libraries). I would suggest further that src/getopt_win.h be renamed to getopt_long.h since it's not just Windows that lacks getopt_long. Michael Index: configure.in

Hi all, Speex currently decides endianness at configure-time. This causes the ppc half of Mac universal binaries to have some endianness problems. Most notably, the header built by speex_packet_to_header() has incorrect byte-ordering. This Apple developer page describes the incantation that can be used to build universal binaries on Mac. It also highlights the configure-time versus compile-time

Hi As per the Linphone, Readme.arm I tried to compile the speex. -------------------------------------readme.arm-------------------------------------------------- ........... Cross compiling speex for ARM: ******************************** First you need to remove ogg headers from your build system to avoid a dirty conflict between your build machine binaries and the arm binaries. They

Hi, Speex-dev I've been able to get Speex to compile on SM400M(MIPSII) with problems. ------ Rebuild All started: Project: speexenc, Configuration: Debug SM400M (MIPSII) ------ Deleting intermediate and output files for project 'speexenc', configuration 'Debug|SM400M (MIPSII)' Compiling... getopt.c getopt1.c skeleton.c speexenc.c .\speexenc.c(501) : warning

Well, I don't quite understand why AC_C_BIGENDIAN and the solution you're proposing is likely to break other big endian machines (the ones that don't have __BIG_ENDIAN__). Can you send a patch that addresses that (i.e. still uses AC_C_BIGENDIAN when it works)? Jean-Marc Peter Grayson a ?crit : > Hi all, > > Speex currently decides endianness at configure-time. This causes

Hi All, Been playing around with the dev version of speex on linux and ran into a small problem due to the fact that the include files have been moved off to a speex subdir. This small patch fixes it. I also think that the SPEEX_VERSION variable should be just VERSION afaict so this adds that as well. Cheers, Pete -------------- next part -------------- A non-text attachment was scrubbed...

It's working fine now... Thanks for your help --- Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca> wrote: > OK, that was a stupid error in the le_int prototype. > It's fixed in svn > now. > > Jean-Marc > > Le mercredi 28 septembre 2005 ? 11:53 +1000, > Jean-Marc Valin a ?crit : > > OK, it seems like I screwed up the wav header code > between

Hello, I have problems to compile speexenc 1.1.4, ihave the following errors <p>speexenc.obj : error LNK2001: unresolved external symbol _speex_preprocess speexenc.obj : error LNK2001: unresolved external symbol _speex_preprocess_ctl speexenc.obj : error LNK2001: unresolved external symbol _speex_preprocess_state_init Debug/speexenc.exe : fatal error LNK1120: 3 unresolved externals Error

Hi. Le duodi 2 frimaire, an CCXIV, Wesley J. Landaker a ?crit?: > speexenc always crashes on amd64; here is an example, and lots of info: I tracked this bug a bit further than you. Here is the origin of the crash: op.packet = (unsigned char *)speex_header_to_packet(&header, (int*)&(op.bytes)); (from speexenc.c) op.bytes is a long, not an int, it is wrong to pass it as an int,

I am transcoding mp3 to wave using ffmpeg I am then piping it to speexenc for speex encoding but the speex file size is 496 bytes after the command ends https://lists.ubuntu.com/archives/ubuntu-users/2010-March/212927.html https://lists.ubuntu.com/archives/ubuntu-users/2010-March/212949.html https://lists.ubuntu.com/archives/ubuntu-users/2010-March/212954.html what am I doing wrong? bellow is

this is not really a development question, but i didn't find another mailing list to ask it. any idea why size of wav file doubles when it is encoded to speex and back to wav: $ ls -ls testi.wav 40 -rw-r--r-- 1 foo foo 40674 May 4 14:38 testi.wav $ speexenc --denoise --agc --quality 10 testi.wav testi.spx Encoding 8000 Hz audio using narrowband mode (mono) $ ls -ls testi.spx 20

Good day, a quick bug while encoding speexes in speexenc. While reading a .wav in function read_samples, size can get to negative values, as long as fread is able to go forward with reading the file. This can happen with Protools-generated wavs, where they put additional information after the "data" fourcc. I created a very quick hack by adding: int tentative_read =