===================================================
= NB: Over 50% of this message is QUOTED, please =
= be more selective when quoting text =
===================================================
[EMAIL PROTECTED] wrote:
>
> Hi,
>
> (Sorry I can't address you by name).
>
> Stainless Steel Rat <[EMAIL PROTECTED]> writes:
>
> > * Eric Woudenberg <[EMAIL PROTECTED]> on Mon, 06 Mar 2000
> > | On what do you base this statement? My understanding of ATRAC (based
> > | upon looking at an ATRAC decoder) is that the computational demands of
> > | encoding ATRAC are similar to those for MP3. I would expect a software
> > | ATRAC encoder to run about as fast as an MP3 encoder.
> >
> > If that were the case, then you would be able to encode MP3 streams that
> > sound as good as ATRAC 4 (which they do not) in real time on your desktop
> > (which you cannot at this time). As I mentioned previously, a Pentium II
> > running at 400MHz is capable of turning SPDIF into 128Kbps MP3 in real
> > time, if it is not doing anything else. The particular machine in question
> > is a 64Mb system with fast/wide SCSI (so, no bottleneck there), using LAME.
> > 128Kbps MP3s do not sound nearly as good as ATRAC 4, so I have to say that
> > the computational loads are not comparable.
>
> Somehow my encoding times are quite different than yours, running
> LAME/Linux on a 500MHZ PIII, I get these times for encoding a 1 minute
> 44.1khz stereo signal:
>
> Output Bitrate (kbps): 32 64 128 256 320
> User time (secs): 15 16 21 21 19
>
> At worst, this is 3 times faster than realtime. The ATRAC encoder is
> not significantly different in structure from MPEG 1 Layer I (a
> simpler encoder than MP3), so it is reasonable to expect that an ATRAC
> encoder would offer similar encoding times.
>
> Also, regarding the ATRAC ASIC, AFAIK (and please correct me if I'm
> wrong), these are microcontrollers with a DSP core for doing the ATRAC
> calculation. Please don't imagine that the ATRAC encoder operates as
> one huge logic operation of an ASIC. ATRAC encoding is still
> programmed in discrete, sequential steps, with lots of multiplies and
> adds. I would imagine the computing power (for performing ATRAC
> encoding) of the CXD-2652AR inside the MZ-R55 to be substantially less
> than a 500MHZ PIII (and it certainly runs a lot cooler!).
>
> Regards,
> Rick
I thinks the PC has a performance problem due to the 'enormous' overhead of the
OS and the fact that most encoders are programmed in C. Look, Eric uses Linux,
an OS that is very stable and runs very efficient (I've still got a 486dx2
running it.). I think, that part of the problem is there!
Cheers,
Ralph -> if the ATRAC DSP has an OS, it will probably be very very very small!
--
=======================================================================
Ralph Smeets Functional Verification Centre Of Competence - CMG
Voice: (+33) (0)4 76 58 44 46 STMicroelectronics
Fax: (+33) (0)4 76 58 40 11 5, chem de la Dhuy
Mobile: (+33) (0)6 82 66 62 70 38240 MEYLAN
E-Mail: [EMAIL PROTECTED] FRANCE
=======================================================================
"For many years, mankind lived just like the animals. And then
something happened that unleashed the powers of our imagination:
We learned to talk."
-- Stephen Hawking, later used by Pink Floyd --
=======================================================================
-----------------------------------------------------------------
To stop getting this list send a message containing just the word
"unsubscribe" to [EMAIL PROTECTED]
