The Huffman Coding
At the end of the perceptual
coding process, a second compression process is run. However, this second
round is not a perceptual coding, but rather a more traditional compression of
all the bits in the file, taken together as a whole. To use a loose analogy,
you might think of this second run, called the "
Huffman coding," as being similar to zip or other standard compression
mechanisms (in other words, the Huffman run is completely lossless, unlike the
perceptual coding techniques). Huffman coding is extremely fast, as it
utilizes a look-up table for spotting possible bit substitutions. In other
words, it doesn't have to "figure anything out" in order to do its
job.
The chief benefit of the
Huffman compression run is that it compensates for those areas where the
perceptual masking is less efficient. For example, a passage of music that
contains many sounds happening at once (i.e., a "
polyphonous" passage) will benefit greatly from the masking filter.
However, a musical phrase consisting only of a single, sustained note will
not. However, this passage can be compressed very efficiently with more
traditional means, due to its high level of redundancy. On average, an
additional 20% of the total
file size can be shaved during the Huffman coding.
Raw Power
If you've surmised from all of
this that encoding and decoding MP3 must require a lot of
CPU cycles, you're right. In fact, unless you're into raytracing or encryption
cracking, encoding MP3 is one of the few things an average computer user can
do on a regular basis that consumes all of the horsepower you can throw
at it. Note, however, that the encoding process is far more intensive than
decoding (playing). Since you're likely to be decoding much more frequently
than you will be encoding, this is intentional, and is in fact one of the
design precepts of the MP3 system (and even more so of next-generation formats
such as AAC and VQF).
Creating an MP3 file, as
previously described, is a hugely complex task, taking many disparate factors
into consideration. The task is one of pure, intensive mathematics. While the
computer industry is notorious for hawking more processing power to consumers
than they really need, this is one area where you will definitely benefit from
the fastest CPU (or CPUs) you can get your hands on, if you plan to do a lot
of encoding.
It's impossible to recommend
any particular processor speed, for several reasons:
- People have very different
encoding needs and thresholds of what constitutes acceptable speed.
- Encoders, as you'll see in
Chapter 5, vary radically from one to the next in terms of their
overall efficiency.
- Any mention of specific
processor speeds would surely be out-of-date by the time you read this.
- There's more to the equation
than just the speed of the CPU. While MHz may be a good measure of CPU
speed when comparing processors from the same family, it's not a good
performance measurement between systems. The difference in size of the
chip's on-board cache may have a big impact on encoding speeds, as do
floating-point optimizations, so one must be careful to note such
differences when benchmarking.
In any case, it's easy enough
to set up batch jobs with most encoders, so you can always let 'er rip while
you go out to lunch, or even overnight. Unless you're really stuck with an old
clunker of a machine (a CPU manufactured prior to 1996, for example) and your
needs aren't intensive, don't even think about running out to get a new
computer just to pump up your encoding speed. You'll be better off making sure
you have an adequate complement of
RAM, a fast and accurate
DAE-capable