On Fri, Oct 15, 1999 at 02:16:58PM +0200, Jan Peman wrote:
[...]
> > to encode, just call lame from a shell script or via system(3).
> >should be trivial, eh?
> This might be hard to do, if they are implementing Lame in a DSP/embedded
> application.
> Don't know if this is the case for the German
On Fri, Oct 15, 1999 at 12:25:12PM +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
Hi!
> > Some time ago Mark initiated a discussion about Lame's license. At the
> > moment Lame is fully GPL which involves some problems.
> > If Lame is compiled as a DLL then the LGPL applies.
> > If Lame is compiled as a standalone program then GPL applies.
> Why not run as standalone?
Becaus
Hello!
On Thu, Oct 14, 1999 at 08:35:29PM +0200, Gabriel Bouvigne wrote:
> I personnally would be happy to see Lame in some commercial products, as
> long as credit to Lame is given. I'd also like that the Lame engine release
> number used would be mentionned, also it's not a necessity.
> To my m
> 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
> 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 compile
> 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
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)
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 bit
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 id
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 actua
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 outpu
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 identifiable sections of that work are not derived from t
> 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
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 n
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
> 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
17 matches
Mail list logo
