similar to: Bug: speexdec on non-speex file = segfault

Hi! Speexdec "clips" playback of files on fast Windows machines when invoking it in decode-and-play mode by only supplying a filename for the source file - the end of the sound playback gets chopped off. I have traced it to the line reading: if (fout && strlen(outFile)==0) WIN_Audio_close (); <p>...which should probably read... if (strlen(outFile)==0)

Hi, I got my hands on the LCA 2003 CD today and I tried to listen to it on my powerbook running Linux. Instead of getting speech, I got an earfull of noise! Attempting the same experiment on an i386 with the same CD produced understandable speech. It seems that the output routine in speexdec converts the output data to little endian short format, which is incorrect on the ppc architecture. The

When I use speexenc appplication to encode a wav file and then speexdec to decode it the decoded wav is bigger than the original, why this happens? Thanks. Miguel Gomes <p> -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2786 bytes Desc: winmail.dat Url :

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

Re: [speex-dev] Error in compiling Speexdec code (Speex-1.1.5 code)onWindows usingVC++6.0Actually one thing i should point out if you do decide to go this route.... currently my demuxer builds a seek table, which could potentially be a bit of a memory hog on a small device... though when i get around to adding the networking code, i will have to use my bisection seek code, so the use of the seek

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

Jean-Marc Valin wrote: > Thanks for the fix. I applied to CVS. It'll be included in the 1.0.1 > version I plan to release soon. Great! Any ETA on the 1.0.1 version? I am just on the verge of releasing a product containing Speex, but might stall for a month or two if significant updates are imminent. With the start of summer vacation in Denmark the whole country pretty much grinds to

according to my little knowledge about automake, its not possible to put variables in _SOURCES. so something like speexdec_SOURCES = speexdec.c wav_io.c $(WIN32_OBJ) is not possible. but than i looked into wave_out.c and the entire source is surrounded by #if defined WIN32 || defined _WIN32 so it will just disappear than build on linux. j On Fri, 2004-02-13 at 07:59, Jean-Marc Valin wrote: >

Hello! The question is: "Does Speex support multiple channels?" Speex is reported to encode only mono and stereo signals. But I found 'nb_channel' defined in <speex_header.h> among the Public Attributes. Does this mean that it is also possible to store more than two channels in one single speex-file? Maybe it will be possible in the next future...? TIA -- Mch --- >8

Hi, just to let you know that unstable version 1.1.1 is out. It includes the latest fixed-point changes which can be enabled with --enable-fixed-point (as configure option) or -DENABLE_FIXED_POINT (for win32). The port is not complete, but most of the floating-point operations have been converted. Please give it a try and report any difference with previous versions (both for float and

This portion of the RFC is gramatically incorrect and confusing: The RTP payload MUST be padded to provide an integer number of octets as the payload length. These padding bits MUST be all zero. This padding is only required for the last frame in the packet, and only to ensure the packet contents ends on an octet boundary. <p> -- Ben Greear <greearb@candelatech.com>

> I had a similar question ... is the endian-ness of the encoded > speex file, system dependent? or is it always little endian? If it's > always little endian (like the header seems to be) then big endian > machines (or java) will need to map everything to bigendian before > decoding ... Well, wav's are considered little endian but for raw files, there's a

Hmm, what these instructions do? (I know nothing about ARMs; I have some knowlege about x86 assemblers and programming). Cant we use pure standard C++ or Java? Does Speex work with fixedpoint math? (As far as I know Java on 6600 has no builtin floatingpoint, there is emulation class somewhere on the net, but it is probably painfully slow.) I do not know if this processor has builtin

> Am I right with the assumption, that currently you have to enable > processor specific optimizations with compile/configure options? > > How difficult would it be to add support for runtime CPU detection? > Is this a feature you might consider adding? Pretty complicated because of some annoying decisions taken by the gcc team. The problem is that gcc won't let you use

Hi, I just did some experiments and it seems like the high system CPU time is not due to one specific part of the code, but rather to the extreme inefficiency of float emulation under Linux. I was expecting float emulation to run something like 30 times slower than integer, but it looks like its more like 3000 times slower. This means that all of the float operations must be removed for the code

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,

-------------- next part -------------- A non-text attachment was scrubbed... Name: speex.mingw.patch__charset_ISO-8859-15 Type: text/x-patch Size: 1490 bytes Desc: speex.mingw.patch__charset_ISO-8859-15 Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20040212/51b4c2a9/speex.mingw-0001.bin

Hello, Can somebody tell me something about the status of the fixed point code at this moment ? I did some tests today with the latest CVS version of speex, but enabling -DFIXED_POINT results in distorted sound in my test application. Is the fixed point code supposed to work properly at this moment ? Regards, /Ico -- :wq ^X^Cy^K^X^C^C^C --- >8 ---- List archives:

Hi, I encoded file in a ipaq 1940, pocket pc 2003, processor Samsung s3c241(similar to ARM), 266 Mhz. I would like to know your opinion for the quality output if this is right to entered parameters. File original: http://padawan.ing.puc.cl/chavezorig.wav File encoded: http://padawan.ing.puc.cl/chavezq1.wav The parameters for encoded are: state = speex_encoder_init(&speex_nb_mode); int tmp=0;

> Date: Fri, 05 Dec 2003 13:22:53 -0500 > From: Jean-Marc Valin <Jean-Marc.Valin@USherbrooke.ca> > > I think I see what you mean, though I haven't been able to listen to > your wma file (not everyone has a wma decoder). The problem probably > only lies in the VBR tuning for wideband which hasn't received much work > yet. One way to check that is to encode in