similar to: here's the test case, possible solution

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, 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 people, Looks like Santa Claus thinks I've been a good boy this year. Here's the third in my performance patch series: d.m.l Apply after applying d.o.n and d.n.m; I don't know how much of those got applied to the CVS tree. What's inside: Request for help! Look in os.h if you're using a compiler or processor I don't use (I use gcc on K5, K7, G3). New MDCT! Now we

Sorry for starting another topic, this is actually a reply to Segher's post on Sun Oct 22 on the 'mdct question' topic. I wasn't subscribed properly and so I didn't get email confirmation and thus can't add to that thread. So Segher, if the equation is indeed what you say it is, then replacing mdct_backward with this version should work, but it doesn't. Am I applying

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

Thread-split from the vorbis-mailing list ("Vorbis determined to be as good as MPC at 128 kbps!") <p>On Sun, 30 May 2004, Segher Boessenkool wrote: [Steven So] SS>> If iTunes AAC can encode castanets with much less pre-echo at SS>> ABR 128 kbps, then hopefully there will be an imaginative SS>> (and non-patented) way of doing this in Vorbis without the SS>>

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

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

Hi, I've just tried Ogg/Vorbis for the first time, and I'm quite impressed with the results. I haven't heard any artifacts in my tests so far, even at -b 112 (but I'm not a trained listener). Thanks for the great work! Now, some (mostly minor) points: When building libvorbis on either a Linux/libc5 or a Solaris system, both with gcc, it failed with undefined references to logf()

I couldn't resist: izeof(synth_buffs) = sizeof(float)*2*2*0x120 = 4 * 4 * 0x120 = 0x1200 = 4608 -Anish > -----Original Message----- > From: Segher Boessenkool [mailto:segher@chello.nl] > Sent: Monday, July 02, 2001 6:34 PM > To: vorbis-dev@xiph.org > Subject: Re: [vorbis-dev] ogg vorbis dynamic memory allocation. > > > > > Firelight Multimedia wrote: >

On 17-sep-04, at 8:30, Jean-Marc Valin wrote: > The granulepos is only available on a per-page basis (otherwise it > would > take up too much space). You can probably see how to use it by looking > at speexdec.c The libogg library _should_ however compute this per *packet*. I know it doesn't. I know it'll be hard for it to do, esp. as how to compute it is codec-dependent.

Greetings, I thought this was supposed to be a list for educated people to discuss serious development of the ogg vorbis project. In light of that, it is amazing to see the level Mr. Segher Boessenkool drops down to in the last posts. More or less calling people insane and accusing them of being on crack and what not. I didn't want to post this on the list, for there is no reason to

Hello all, I'm having some problems with the sound quality of recent Vorbis. There is some kind of metallic echo/tremolo effect in the lower frequencies. This is on my iMac; haven't seen this problem on x86. If you need a sample, I can put one up somewhere, or mail it to someone with a good ftp server, preferably. It could be caused by the iMac sound system doing surround sound, (Dolby

Me again, this time not about patents but about wavelets. I've been doing some work on an image compression method which uses Haar wavelets plus VQ and entropy coding, and Segher Boessenkool told me in a private message that you are also doing a video codec. So I searched the archives and read a bunch of posts, but I never did find out any web address. And it's not on xiph.org either. So