Hi Greg,
Hello!
you wrote on Sat, Oct 16 1999:
You said yourself "They have a bad encoder that is coupled via DLL
into their program".. Sounds like they dont want to spend the $$ on
a good encoder, so they want to use lame to enhance their product.
And even if, what's the big deal with it?
From: Takehiro Tominaga [EMAIL PROTECTED]
"E" == Erik de Castro Lopo [EMAIL PROTECTED] writes:
E How much double precision floating point code does LAME use?
IMHO, double precision is over spec for MP3 encoder/decoder. For
example, mpg123 uses only float(single precision).
An
Hi !
I had some problems with a piece of software ( the Main Actor 3.04
video sequencer for Win made by www.mainconcept.de )
I reported them a bunch of bugs and problem and got some useless chat
as response. And in their last mail , they claim MPEG does not support
44100 Hz as sampling rate
PLease check a table in loop.c:
struct scalefac_struct sfBandIndex[6] =
{
...
{ /* Table B.2.c: 24 kHz */
{0,6,12,18,24,30,36,44,54,66,80,96,114,136,162,194,232,278,330,394,464,540,576},
332 !!!
Hi all, (A bunch of stuff on FFTs)
Has anyone done any speed comparisons between
- the FHT based code lame has now (which is damn fine)
- "fastest fourier transform in the west" fftw (www.fftw.org)
- pentium optimized fft - djbfft
From: Richard A. Smith [mailto:[EMAIL PROTECTED]]
On Sat, 16 Oct 1999 22:54:32 +0100, Mathew Hendry wrote:
With gcc, using array notation is usually faster
(particularly, I found,
when the dataset exceeds the level 2 cache size - couldn't figure out
why...)
Perhaps we should examine
On Fri, 15 Oct 1999, Richard A. Smith wrote:
Also as reply to: Gabriel Bouvigne - France
[...]
I think this is true (for a single pointer loop, for multiple/too many
pointers I think Takehiro is right, see earlier postings; pointers
can no longer be alloc'ed to registers, so memory is needed
On Mon, 18 Oct 1999 [EMAIL PROTECTED] wrote:
Hi all, (A bunch of stuff on FFTs)
Has anyone done any speed comparisons between
- the FHT based code lame has now (which is damn fine)
- "fastest fourier transform in the west" fftw (www.fftw.org)
- pentium
On Sat, 16 Oct 1999, Mathew Hendry wrote:
As a suggestion keep the subject relevant so that people can filter if
they
want.
Sorry, copied from answer in other thread (toolame1d):
http://www.oreilly.com/catalog/hpc2/toc.html
Quite a good page:
On Mon, 18 Oct 1999, DAVID BALAZIC wrote:
From: Takehiro Tominaga [EMAIL PROTECTED]
[...]
An input file (like .wav file) has only 16 bit precision and dynamic
range(this value is selected from human hearing ability). And the
IEEE768 says single precision has 24 bit precision.
Current
On Mon, 18 Oct 1999 12:16:32 +0100, Mathew Hendry wrote:
From: Richard A. Smith [mailto:[EMAIL PROTECTED]]
Perhaps we should examine the compiler assembly output of the 2 test
cases.
/* "array" version */
L19:
addl (%ecx,%edx,4),%eax
subl $1,%edx
jnc L19
L17:
From: Richard A. Smith [mailto:[EMAIL PROTECTED]]
On Mon, 18 Oct 1999 12:16:32 +0100, Mathew Hendry wrote:
int
sum_array_ar(int *array, long len) {
I just noticed that you pass array into the function in pointer
notation but then use it as an array inside the funtion. I have a C
From: Richard A. Smith [mailto:[EMAIL PROTECTED]]
Well there's the answer. The pointer version has an extra addl
instruction. Does this hold true for an array of floats as well?
Yes.
_sum_array_ar:
movl 4(%esp),%edx
fldz
movl 8(%esp),%eax
decl %eax
Hi Greg,
you wrote on Sun, Oct 17 1999:
zillions of front-ends for encoders, I don't understand, what makes
this particular program so unique, that it can't be GPL'd.
I'm glad to have some backup here.. Sometimes I feel like a crazed nut,
crying out on a soapbox about issues no ones cares
Has anyone taken a close look to the three spreading functions
in Lame? For me it looks like they are buggy, but correct me
if I'm wrong.
Here is how I would patch them.
Robert
*** lame3.34/psymodel.c Tue Oct 12 23:14:57 1999
--- lame3.34.w2/psymodel.c Mon Oct 18 21:27:27 1999
From: [EMAIL PROTECTED]
Has anyone done any speed comparisons between
- the FHT based code lame has now (which is damn fine)
- "fastest fourier transform in the west" fftw (www.fftw.org)
According to the benchmarks on fftw.org (unbiased, I'm sure) FFTW is about
twice
I don't have a time to look the whole source, but I mention one point...
"M" == Mathew Hendry [EMAIL PROTECTED] writes:
- pentium optimized fft - djbfft
M http://pobox.com/~djb/djbfft.html
(gives out-of-order output,that i'm not too sure how to grok)
M A header is supplied
!if(j!=3Di) temp1 =3D (cbval[j] - cbval[i])/.33;
!else temp1 =3D 0;
as im too lazy to look at the context, i dont know if this is frequently
executed code... but, do most compilers optimize /.33 into *3.030303...?
i checked with gcc on sparc, and it apparently only
18 matches
Mail list logo
