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 Technology.

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 California coastline.

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 written.

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.