similar to: Performance increase?

Segher Boessenkool wrote: >> I noticed that you changed all constant floating point numbers >> from double notation (e.g. 3.0) to float notation (3.0f) in the latest >> version >> of Speex (in subversion). >> Did that give any performance increase (because of elimination of the >> float to double and double to float conversions)? > > > It does, with

I'm using speex to encode wav files. How does the --bitrate n option (use bit-rate n or lower) afects the quality and time of the encoding? If I don't use that option how speex determines the bitrate to use in encoding? Thanks in advance Miguel Gomes -----Mensagem original----- De: owner-speex-dev@xiph.org em nome de Chris Flerackers Enviada: qui 18-03-2004

Some thoughts for the new year: 1) MDCT is good for image coding 2) image coding and audio coding are two very different things 3) combine 1 and 2 4) if a psycho model is good, after leaving out what it tells you you can without hurting quality, applying the same model should yield the same results as you got before 5) from 4: decode -> encode -> decode should result in (almost) the

Hi all, [For the uninitiated: a "peeler" is a program that transforms a Vorbis stream into a smaller, (somewhat) lower quality Vorbis stream, and does so quickly, by just throwing out some data.] After having prototyped several peelers that aim to peel to a certain filesize, or to a certain quality, with mixed success, I've now taken a different route: a peeler that aims for the

Hi all, [For the uninitiated: a "peeler" is a program that transforms a Vorbis stream into a smaller, (somewhat) lower quality Vorbis stream, and does so quickly, by just throwing out some data.] After having prototyped several peelers that aim to peel to a certain filesize, or to a certain quality, with mixed success, I've now taken a different route: a peeler that aims for the

what are the main fields where optimisation will take place to improve the CPU use when decoding Ogg Vorbis files? -- Venlig hilsen/Kind regards Thomas Kirk ARKENA thomas@arkena.com http://www.arkena.com "I was drunk last night, crawled home across the lawn. By accident I put the car key in the door lock. The house started up. So I figured what the hell, and drove it around the block a

Hiya, Just downloaded beta3, and I actually got it to compile without too much hassle. Great job! Still, some problems: -- (easy): the -V option to ogg123 is broken, --version works. -- make profile doesn't work (in vorbis-tools), need to pass in some -pg -static or something like it (doesn't exactly work, -static is swallowed by libtool; read some docs, needs to be -all-static

Hiya, Here is the sources to my "rehuff" program. ./rehuff in.ogg out.ogg does a lossless recoding of a vorbis stream. (It generates optimal huffman codes for the particular stream). This code is meant for developers only, until someone is kind enough to provide good build and configure support for it. I won't. And no installation help questions please. There is a little patch

Hi all, Yes, it's true. A new version of rehuff, the tool that losslessly compresses Vorbis files: one that is easy to compile, and that works with newer-than-two-years-ago streams, too! On 1.0 streams, you get about 3% size reduction, and the headers get _much_ smaller (which helps for fast-start network streams). Building it should be easy (you might have to add some -I and -L for

Hi all, Yes, it's true. A new version of rehuff, the tool that losslessly compresses Vorbis files: one that is easy to compile, and that works with newer-than-two-years-ago streams, too! On 1.0 streams, you get about 3% size reduction, and the headers get _much_ smaller (which helps for fast-start network streams). Building it should be easy (you might have to add some -I and -L for

No offense, Segher, but the output quality of this thing is awful. =) I'll disregard the fact that, at least with *my* compiler, the source tarball I downloaded reduces every packet to zero bytes, which isn't terribly interesting. I decided to set the byte reduction to something constant: I started by dividing each packet's size by 2 just to see what would happen. The resulting ogg

I saw some mail go by a bit ago about doubles-vs-floats, but I seem to have lost it. I'm interested in rewriting the mdct code using Altivec on MacOS X. Altivec doesn't support doubles, though -- the only floating point vector type is single precision floats. Vorbis currently has doubles everywhere -- is this really necessary? Doubles are supposedly faster than floats in the PPC

I notice that the user is not able to set their own CFLAGS or LDFLAGS in the ao, ogg, vorbis, and voribs-tools projects. Is there a reason for this? I understand the fact that these modules want to set extremely high optimization flags, and that most users won't know what these are offhand, but there are times when it is useful for the user to specify their own CFLAGS/LDFLAGS. For example,

Hi, I just downloaded http://www.speex.org/download/speex-1.1.4.tar.gz and tried to build it but the file denoise.c seems to be missing from the archive. Can you fix this or is it better to get everything from cvs? Another question, when will a stable version of 1.1 be released. I'm interested in the preprocess features but I would also like a stable encoder/decoder :-) Best regards, Chris

Hello all, Finally I succeeded in uploading the test case I promised. It's at http://home.wanadoo.nl/segher/test1.wav.bz2 (It is a wav, the headers are a bit inconsistent, but encoder_example will be ok with it, as it just skips them). I did some thinking, and a possible solution is decreasing the ATH_Bark_dB[] for the lower frequencies. As the comments say, it's not really an ATH, but

Hi, I wonder if there is specific requirement or restriction for the decoder in order to be consider "Vorbis" compliant (or let's say, to be a "correct" vorbis decoder). I am experimenting with integerized libvorbis and the decoder delivers the audio data as following, (and compare with the floating point version below). $ tail audioout-int.txt 0290670 025e 085c 02cf 0895

I thought this might be interesting to you, it's an extract from the latest streaming media newsletter, I was intrested to note that MS are claiming cd quality audio at 48kbps whichi is obviously very low, I didn't think much of it at first because nobody uses MS codecs for audio anyway! However (a bit I missed off this quote by the look of it) I then read mention of portable audio players

> Note however that you'd still have to dlopen the library since can't > just do: if (call_is_allowed) > speex_encode_int(...); > > because then it won't link. Yeah, I understand that. I wonder if there's a way to "weak-link" against libraries on Linux/GNU-ld-so? The idea is that a symbol lookup/relocation isn't performed until the call is

Hi all, The decoder is down 30% execution time, identical bit output. Didn't get the mdct yet; 1024 point mdct is a bit much to brute-force, and I'm not going to hand-unroll the whole thing either (the machine- unrolled version produced a 1.5M executable; understandably, it wasn't very fast. Still waiting for processors with 1.5M L1 code caches ;-) Slowest parts now are: -- mdct --

Hello all, Please try this "patch". It changes the way the noise floor is used for quantization in a not-so-subtle way. At the very end of _vp_compute_mask, add the lines: for(i=0;i<n;i++) flr[i]=.01f*sqrt(flr[i]); The .01 is there to ensure the current codebooks will work. We will really need different, newly-trained codebooks with this change; then the