Mac Forum / Programming / Mac Programming / January 2005

With all due respect, Mike, I ain't buying that. Perhaps in part because
I've seen *ZERO* evidence of any such capability, even on "top of the
line" Wintel boxes running at multiple GHz clockrates.

Uh-uh... I ain't buying THAT one, either. When I gave up on "internet
radio", it was mainly because the sound quality was so abysmally
horrible that I couldn't stand to listen to it for more than a couple of
minutes. And *NONE* of the applications involved knew MP3 from
marshmallows. Every single one of them used its own (proprietary, no
less) streaming codec that made whatever was playing sound like a
tin-=can-and-string telephone in an echo chamber.  

I don't do iTunes (or any of the other "iWhatever" perversions), so I
have no clue what you're talking about when you mention the "Radio
playlist", but you're going to have a damn hard time convincing me that
*ANY* machine or program is capable of doing MP3 compression quick
enough to be used as a realtime stream source without hideous mangling
on the receiving end of things.

I'm thinking we both need to step back and take a look at what we're
each calling "realtime" - For the record, I'm saying that realtime means
"the encoding happens in a span of time only slightly longer than it
would take to simply play the raw data".

For instance, if I push an AIFF file that takes 3:26 to play into an
encoder that wants to be considered "realtime", that encoder's going to
have to spit out a finished MP3 file damn close to 3:26 (give or take
5-10 seconds to allow for filesystem access overhead and the like) after
I hand it the data.

If it doesn't, it's NOT what I'd consider calling a realtime encoder,
regardless of how fast it might be.

In other words, if I shove a file into the encoder, I'll be able to play
the output - straight from the encoder - without ever knowing there was
an encoding step involved. (unless, of course, my ears are sharp enough
to pick up on any artifacts that the encoding produces)

I'm still not buying.

As of *RIGHT THIS INSTANT*, I've got an AIFF file being packed down into
MP3 in the background. It's about 2/3 done, and has already been "in
progress" for *AT LEAST* 10 times the playback duration of the source
file, if not more, and I expect that by the time it finishes, the total
"time to compress" will be in the neighborhood of 15-20 times the
playback duration of the piece. This is on a G4/300. Trying to stream it
out to somebody "realtime" would not only be insanity, but stark-raving
madness at the receiving end - a second or three of sound, followed by
lots of dead air, followed by a few seconds of sound, followed by lots
of dead air, lather, rinse, repeat...

That's assuming the networking code can "get a word in edgewise" to
actually send the data over the wire...

No clue about iTunes and its performance, but the MP3 encoder plugin
that I use is the quickest thing I've personally encountered for making
MP3s on a Mac.

I suspect that they're all pretty similar, since last time I looked into
the concept, there was only one "core" MP3 encoder that could be had -
legally, anyway - and it didn't come in source-code form that would
allow tweaking - It was a handful of ".h" files and a precompiled
library for <platform X> that you bought a license (and god, what a high
price-tag...) to be able to call into. NO "tweaking", "unrolling", or
other optimization possible. Basically, a "black box" that you pumped
the raw audio data and a couple of "compress it this much and put the
result here" parameters into, and waited for it to spit out MP3
compressed data.

Which should mean that, unless things have changed radically (which I
think highly unlikely due to the whole patent issue) most, if not all,
MP3 encoders are effectively running the same core code, with any speed
differences attributable solely to the following:

o hardware type (Some boxes don't do "circular shift left", aka "cshl",
natively ferinstance, which means that code that's heavy on that
operation has to "fake it", usually at a major speed penalty - Others
have a native cshl machine-language  instruction that makes it possible
for the same code runing on that hardware to beat the pants off the
machine that lacks a native "cshl")

o clock speed (It should go without saying that an 800 MHz processor is
going to get the job done quicker than a 300)

o compression amount (More compression = more time doing the
compressing).