The End of the Beginning|
[ No. 24 - October 1998 ]
Welcome to the end of the beginning! This column marks two years of
pithy FezGuy Internet audio opinions, resources and educational
amusements. In the past two years music on the Web has finally begun
to sound like more than an afterthought. The quality of streamed audio
files is improving and tools to digitize and compress music are
becoming easier and (somewhat) more efficient. To mark this auspicious
occasion, let's take a look at a next generation MP3 encoder from Xing
We'll encode a WAV file (created in Cool Edit from an analog output of
a portable DAT player) at different bitrates and play it back. (See
column #3 at <www.fezguys.com>)
This will be a subjective listening
test. We've elected to use common or garden-variety tiny little
powered computer speakers. Our exhaustive demographic research says
that's what most people use. They are Labtec CS-150's and are indeed
both tiny and little.
Because this encoder is still in the beta stage and is Windows only
(c'mon people!), we'll do our subjective processing and listening test
on a Windows NT machine with dual 200mHz Pentium processors and a
crappy little 13" color monitor (it brings new meaning to the term
"lo-rez") we found in the closet. We'll perform these tests in the
secret underground FezLab at Grok House, somewhere on the Central
The Xing MP3 Encoder can be purchased securely and downloaded at:
<www.xingtech.com/products/mp3encoder/> for $19.95. The Xing website
is slightly confusing. They must still be integrating this new suite
of tools. While looking for links to the MP3 software, we kept finding
ourselves at their MPEG 2 or LBR (Low Bit Rate) products.
The Xing MP3 Encoder is based on the XingMPEG Encoder engine and
features a stylish GUI. What the hell do we mean by these terms? Just
this: the "engine" or "back end" (no jokes please) is the actual
program (comprised of lines of code) that instructs an application to
perform the tasks you assign it through the onscreen window or "front
end", which is called a "GUI" (for Graphical User Interface). Example:
The play, stop, and pause buttons on your computer's CD control panel
is the GUI for playing the audio on the CD. Yeah, yeah, we
know... jargon in, jargon out.
After downloading the app to our desktop we double click on the
installation icon. This installs the app in the Start Menu of Windows
98. Remember to read the release notes. Release notes tend to be
dense and boring conflict alerts but not here. There's actually some
useful information (such as tips and suggestions on how to use the Xing
product in place of the perfectly good, yet slower,
Fraunhoffer-Gesselschaft MPEG codec).
Upon launching the app we get our first look at the GUI. It's simple
to read and easy to use. There's a Progress Bar that shows how many
jobs are started, how long is left to go and what percentage of the
file is encoded. There is helpful little context-based text help line
at the bottom of the window. The documentation is clear and well
We'll now encode a 3 min. 35 sec. song that, as a WAV file, takes up
36.2MB of disk space. We'll compare the length of time it takes to
encode files at different bitrates. These files are aimed at streaming
over regular telephone modems. Remember: the higher the bitrate, the
better the audio quality. The tradeoff is needing a faster modem.
First we encode our WAV file in stereo with a 44kHz sampling rate and
compressed to stream in mono at 16kbps (for 28.8k or faster modems).
This shrinks the file size from 36.2MB all the way down to an alarming
420k. Using our Rube Goldberg, real-world testbed the encoding process
takes 32 seconds to go from that huge WAV file to the tiny little
compressed MP3 file. Subjective playback judgement: it sounds fine.
It sounds like what you'd expect when so much of the original file has
been stripped out. The music is sonically legible and recognizable.
Then we encode our WAV file in mono with a 22kHz sampling rate and
compressed to stream at 32kbps (for 56k or faster modems) This shrinks
the file size from 36.2MB all the way down to a still-amazing 840k.
Continuing the use of our Rube Goldberg, real-world testbed the
encoding process takes 18 seconds (mostly due to the WAV file being
sampled at 22kHz). Subjective playback judgement: it sounds very nice,
with somewhat more high end and clarity then the 16kbps file.
Note: we had to resample the WAV file (which took 5 minutes) at 22kHz.
The GUI setting for streaming at 32kbps called for a 44.1kHz sampling
rate, stereo. We used the backend of the encoder to encode with the
sample rate setting to 22kHz, mono, because the end result of the
44.1kHz, stereo encoded file sounded truly horrible. It was completely
unuseable. It's great that we can modify parameters but having to do
it from within the engine is a problem. Most users do not want to
bother with using the MS-DOS command shell backend component of an
application. After all... what is the GUI for?
The GUI lets us enter a 44.1kHz input WAV file and (as it should)
handles the "downsampling" (literally: making the file smaller) from
the backend for you. The problem arises during the downsampling.
Using the 44.1kHz sampling rate, stereo, we end up with swooshy, poor
quality sound. If you downsample first (using Cool Edit) and then
compress with the backend of the Xing MP3 Encoder everything sounds
fine. Still, it feels like something is not right within the product.
As it is a first release, we'll give them some slack and assume they're
working out the bugs. The backend is great. Xing has always been
about great hardcore backend technology. Can we say that?
Continuing an already idiosyncratic pattern, this GUI wouldn't let us
encode at higher bitrates such as 64kbps, 112kbps, 192kbps and
320kbps. For the purposes of this particular column (concerning
streaming over telephone modems) it wasn't necessary. However, if they
are listed, why not have them available?
Random Observations During Operation of Product: We like that if you
cancel a job you can choose which file(s) you might want to
(re)encode. Also: it's good that the seek bar at the bottom of the
play window let us play back encoded files at random spots. It would
be nice if you could choose the way that the app names target files.
This would enable multiple encodes at different bitrates in the same
batch. A time saving bonus!
In summary, the backend is solid and it's fast, like they claim it is,
but the GUI needs some work. Hopefully Xing will address the above
issues in future releases. As we said, Xing's reputation has been
great backend technology. Given that, our results are not surprising.
If it's not a priority for them to put some resources into GUI
improvements then perhaps they might partner with an organization that
can. Here's a radical concept: perhaps they could make an evaluation
version freely available on the Internet. Users would provide valuable
(and free) feedback. Use your users!
Is it worth it? Yes. Overall the product is very nice...and
damn!...it's fast. We like that. It's worth twenty bucks.
Xing MP3 Encoder backend - Four Fezzes.
Xing MP3 Encoder GUI - Two Fezzes.
The Line At The Bottom: Internet audio products are improving rapidly.
The quality of the audio when compressed at low bitrates is getting
better all the time. It would be good for interface designers to
involve some regular layman in the design process. Designers could get
some valuable perspective into how a musician or music-lover actually
thinks and interacts with computers and software.
Next month we'll check out RealAudio's new G2 Encoder and compare the
results with their previous 3.1 suite of tools. And just for laughs,
we'll also compare the results with our MP3 experience, such as with the
above-mentioned Xing product! Woo!
The FezGuys welcome your comments.