Hi all
On 15-Oct-99 Greg Maxwell wrote:
Are you aware you can use lame for image compression? :)
compression.. Check out http://linuxpower.cx/~greg/mp3crap/ for some
examples of this kind of perversion..
This is so perverse it's actually neat. :)
Anyone tried the reverse? Image compression on
Duh.. I see, M/S is define with addition/subtraction not multiplication.
So, is there a downloadably doc that describes intensity mode, are
decoders a good source of info?
There is a few lines (only a few) about it in the iso docs. If you don't
have them yet, they are available on
The opther point is that you can't trust your compiler using its maximum
optimization level. It sometimes produces weired results, and you always
have to check the accuracy when, as an example, you're using egcs with -O9.
Horsecocky. If EGCS is producing bogus code, that's a bug in your C,
On Fri, 15 Oct 1999, Gabriel Bouvigne wrote:
With modern compilers, you don't generally need to bother with replacing
for (i = 0; i len; ++i)
sum += array[i];
with
for (p = array, endp = array + len; p endp; ++p)
sum += *p;
Any compiler worth its salt will do
From: Gabriel Bouvigne [mailto:[EMAIL PROTECTED]]
The following loop is faster than array, both on hppa
processors using g++,
pentium, celeron and pIII using both egcs and msvc++:
for (i=len, p=(array+i); i--; )
sum+=*--p;
Descending loops with pointer use have always shown to
Patrick De Smet wrote:
I was also looking into this kind of thing to change the lame code all
over the place (i.e. inside the subbandfiltering).
(Part of) Reason for speed up I believe is you can save/replace the 'i'
"cmp value + bne/beq" assembler with only "bne/beq" (branch equal or
On Thu, 14 Oct 1999, Mark Taylor wrote:
Encoding with ./lame -mj -b 96 -h -g applaud.wav ap2.mp3
on RedHat 6.1
The re-synth on frame 16 granule 1 looks seriously wrong.
Thanks for finding that. it is a bug in frame analyzer code and
shouldn't effect the output.
Mark
On Fri, 15 Oct 1999 [EMAIL PROTECTED] wrote:
Hi all
On 15-Oct-99 Greg Maxwell wrote:
Are you aware you can use lame for image compression? :)
compression.. Check out http://linuxpower.cx/~greg/mp3crap/ for some
examples of this kind of perversion..
This is so perverse it's actually
At 12:25 PM 10/15/99 +0200, Gerhard Wesp wrote:
On Thu, Oct 14, 1999 at 06:27:01PM +0200, Nils Faerber wrote:
First of all since all parts of Lame are GPL the usage of header files
included ofr use of Lame as any sort of DLL for other programs will force
let me cite the gpl:
``If
Hi all,
I found an interesting paper on psychomodel 1 which may contain some
useable ideas: (it also comes with C source)
ftp://ftp.icsi.berkeley.edu/pub/real/kyrill/PsychoMpegOne.tar.Z
They discuss using formula for values instead of tables and thus (this
is the good
On Fri, 15 Oct 1999 10:59:39 +0100 (WEST), Patrick De Smet wrote:
Descending loops with pointer use have always shown to be faster than
arrays. I use them a lot in image processing.
Descending loops allow the compiler to replace the loop index
comparison with a BNZ (branch if not zero)
Horsecocky. If EGCS is producing bogus code, that's a bug in your C, in
EGCS
or in your headers. I'd wager in the C. In the past nearly six years of
developing Ogg, I've found one gcc bug, no egcs bugs, two Linux libc
header
bugs and one libc bug. Each one was exactly that-- A bug, not
When did the pointer in a register go away? Are you telling me that
the register keyword dosen't do anything in modern compilers?
Forgive me if this is old hat. Most of my work is in the embedded
world of 8-bit uCs.
In modern compilers, the register keyword is an indication. The compiler
Compilers sometimes have bugs, and gcc and egcs have some (even some in
common). That's why there are some new release, no?
I'm talking about real bugs.
OK. I was fairly sure we were actually agreeing, and we were.
BTW, in case LAME folks don't know about it yet (this is a major bug and
14 matches
Mail list logo
