> I am about to upgrade my motherboard and I am looking for suggestions
> on what the minimum horsepower needed to do >= real-time encoding on
> a AMD or a Cyrix systems. !(Intel inside)
>
> What is the encoding process bounded by? I/O operations or
> computational speed?
computational speed
On
>
> I am about to upgrade my motherboard and I am looking for suggestions
> on what the minimum horsepower needed to do >= real-time encoding on
> a AMD or a Cyrix systems. !(Intel inside)
>
> What is the encoding process bounded by? I/O operations or
> computational speed?
>
>
> --
> Richar
> Computational speed, and cache size seem to be the most important
> factors. But anything you buy today will have no problem encoding
> (even with "lame -h") at faster than real time.
> My 600mhz athalon is about 5x.
It seems strange that my old Pentium 133MHz (hey, it's the best I've got at
On Fri, 5 May 2000 20:04:32 +0200, Ivo van Heel wrote:
>> Computational speed, and cache size seem to be the most important
>> factors. But anything you buy today will have no problem encoding
>> (even with "lame -h") at faster than real time.
>> My 600mhz athalon is about 5x.
>
>It seems stra
Hi all, I dont know if this has been addressed before:
Has anyone ported LAME on a dsp, like motorola 68K...
If so, how many MIPS does it require
on a typical DSP with XY memories, some
multifunctions,
single cycle MAC, some 8K of on chip memory etc?
Or any estimate?
How about the Fraunhofer co
Ivo van Heel schrieb am Fre, 05 Mai 2000:
> > Computational speed, and cache size seem to be the most important
> > factors. But anything you buy today will have no problem encoding
> > (even with "lame -h") at faster than real time.
> > My 600mhz athalon is about 5x.
>
> It seems strange that
>
> Hi all, I dont know if this has been addressed before:
> Has anyone ported LAME on a dsp, like motorola 68K...
I try to port LAME to an TI TMS320C6701 ... but I'm still getting hunderts
of linking errors ...
When I'll be successful I'll post the source into the web and contact this
list.
> If
it be possible to change all the float calculations
to table look up and speed things up?
>From: Ivo van Heel <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: [MP3 ENCODER] Hardware reccomendation
>Date: Fri, 5 May 2000 20:04:32 +0200
>
&g
> > > Computational speed, and cache size seem to be the most important
> > > factors. But anything you buy today will have no problem encoding
> > > (even with "lame -h") at faster than real time.
> > > My 600mhz athalon is about 5x.
The ~0.3x I get on my Pentium 133Mhz is with -h and CBR, bu
Sent: Saturday, May 06, 2000 7:18 AM
To: [EMAIL PROTECTED]
Subject: Re: [MP3 ENCODER] Hardware reccomendation
> > > Computational speed, and cache size seem to be the most important
> > > factors. But anything you buy today will have no problem encoding
> > > (even wit
Ivo schrieb am Sam, 06 Mai 2000:
> > > > Computational speed, and cache size seem to be the most important
> > > > factors. But anything you buy today will have no problem encoding
> > > > (even with "lame -h") at faster than real time.
> > > > My 600mhz athalon is about 5x.
>
> The ~0.3x I ge
>>So, when you get only rates around 0.3x, then there are following possibilities:
>>a)your test song is hard to encode
>>b)you use an older, slower version of LAME
>>c)your compiler does some strange things
>>d)your Pentium runs at half speed
e) your machine has no 2nd cache or p
> > The ~0.3x I get on my Pentium 133Mhz is with -h and CBR, but my surprise
> Linux, gcc 2.95.2 compiled, Pentium 166 MMX (200MHz):
> duration 6:30, rate 0.9744
> Win95, Intel4.5 compiled, Pentium 166 MMX (200MHz):
> duration 6:47, rate 0.9345
> Win95, Intel4.5 compiled, Pentium 133:
> duration 1
Allright, my (hopefully ;)) final word on my Pentium 133MHz bad MP3 encoding
performance... I just compiled the released 3.80 and it's slower (CBR) than
what I just encoded with 3.69, as you can see below:
Linux shell> lame -h track_07.wav
LAME version 3.80 (www.sulaco.org/mp3)
GPSYCHO: GPL psy
> > I am about to upgrade my motherboard and I am looking for suggestions
> > on what the minimum horsepower needed to do >= real-time encoding on
> > a AMD or a Cyrix systems. !(Intel inside)
> >
> > What is the encoding process bounded by? I/O operations or
> > computational speed?
>
> comput
> > Computational speed, and cache size seem to be the most important
Cache size and speed are the only important factor if you have cache misses,
and you own an Intel processor. Cache misses are _extremely_ expensive.
The P166 MMX and up have a better cache than the P133 and down. But my
lowly
Segher> Oh, by the way, anyone interested in better DCT's?
I made faster mdct_long and sent it to Takehiro.
--
Naoki Shibata e-mail: [EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
> > > What is the encoding process bounded by? I/O operations or
> > > computational speed?
> >
> > computational speed
> > On an embedded system with a K6-200 (without L2 cache!) and
> > gogo 2.31 there was still CPU power left for other things.
>
> ...which means you are *not* cpu bound.
My
Hi Ivo!
> Woah, that's pretty big difference, isn't it??
YES
> > b) you use an older, slower version of LAME
>
> Well, it was based on some older versions, I'm now testing it with the
> version
> I have now, which is Lame 3.69. Is there much difference in speed from
> the
> newer versions?
> "R" == Robert Hegemann <[EMAIL PROTECTED]> writes:
R> I can't remember, but I think there is a speed increase from
R> 3.69 to 3.80
Yes there is. I made a more fast/efficient huffman coding.
but another coding change (for thread safe) vailed it...
> "I" == Ivo <[EMAIL PROTECTE
> > Well, it was based on some older versions, I'm now testing it with the
> > version
> > I have now, which is Lame 3.69. Is there much difference in speed from
> > the
> > newer versions?
> I can't remember, but I think there is a speed increase from 3.69 to 3.80
Well, I noticed a speed DECREAS
> R> I can't remember, but I think there is a speed increase from
> R> 3.69 to 3.80
> Yes there is. I made a more fast/efficient huffman coding.
> but another coding change (for thread safe) vailed it...
Hmmm... I encoded the same song twice, with the same parameters and it was
encoded sl
Segher> Oh, by the way, anyone interested in better DCT's?
Naoki> I made faster mdct_long and sent it to Takehiro.
and it was merged to my tree.
maybe tomorrow, CVS tree will get it.
it's very swift :)
---
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list (
> "T" == Takehiro Tominaga <[EMAIL PROTECTED]> writes:
Segher> Oh, by the way, anyone interested in better DCT's?
Naoki> I made faster mdct_long and sent it to Takehiro.
T> and it was merged to my tree. maybe tomorrow, CVS tree will
T> get it.
T> it's very swift :)
It'
24 matches
Mail list logo
