Another interesting area is embedded devices. Getting mp3 encoding capabilities into household stereo equipment or walkmans (replacing tapes and minidiscs) can in the long run give us cheaper, easier, less energy wasting and less error prone gadgets (mp3 encoders/players needs no moving parts). Encoding speed is vital for acceptance in this kind of equipment. The faster the encoding, the cheaper and slower processor can be used, keeping down price, power consumption and heat generation.
 
 

Speed comparisons today and yesterday.

It used to be easy for me to do speed comparisons on BladeEnc and the competition. I compiled a binary and timed it under windows on my Pentium 133 at home and Pentium 225MMX at work, using the same old wav every time. When a new version of a competing encoder came out, I downloaded and timed that too, keeping the speed comparison table up to date. The tests gave clear and authoritative results and showed the users what they could expect.

Today it's much harder for a number of reasons:

First of all, BladeEnc and its most aggressive competitors (LAME, Gogo etc) are all available on a number of platforms and operating systems. These systems are so different from each other so what is an optimization on one of them might end up to slow it all down on another one. Different encoders might therefore rank differently on different architectures.

Secondly, neither BladeEnc or LAME are distributed as binaries due to the patent issues. Therefore there is no authoritative source for the latest build, which has resulted in there being a large number of binaries floating around, compiled with different compilers and compiler settings which makes a huge difference.  There is therefore no way for me to say how fast the version of BladeEnc that you have downloaded is, I can only make comparisons with the binaries I have produced, which might be faster or slower than whatever you have compiled or downloaded. I know there are people out there that are using versions of BladeEnc that is everything from half as fast to 30% faster than what I have.

A third problem is the increased amount of architectural differences in the PC market. When I started with BladeEnc, nearly everyone had a Pentium, or if they were lucky a Pentium MMX or maybe even a Pentium II. Alternatives from Cyrix and AMD existed, but were very uncommon. I therefore only had to make a few tests on a few systems to get a quite correct picture. Today it's much worse. We have many more processor architectures in active use (Pentium, Pentium MMX, Pentium II, Pentium III, Celeron, K6-2, K6-3, Duron and Athlon) using various kinds of CPU instruction extensions (MMX, 3DNow!, KNI etc), different bus speeds (60-133 MHz, with 200 and 266 MHz comming soon), very different memory technologies (can you say RAMBUS?) etc etc. Encoders that have been heavily optimized for one of them, might actually face a substantial slowdown on other architectures, so what should I use as a reference platform?

These are the main reasons I'm not putting up a new real speed comparison.
 

Speed vs Quality

People should be aware that different mp3 encoders produce very varying sound quality (see the quality section for more details). Some encoders are much faster than the rest (Gogo and Xing), a benefit which partly has been achived by sacrificing quality for speed.

BladeEnc has always had a focus on quality and has never done this sacrifice and neither have LAME or Fraunhofer's encoders as far as I know (they might have a quick option for fast low quality encoding though and some frontends/applications might have it enabled or disabled by default, so watch out!).

However, you can't make general assumptions on speed vs quality. The slower encoders doesn't automatically produce better quality and a faster encoder might also generate better quality.
 

How does BladeEnc compare to the competition?

If you ask different people how BladeEnc compares in speed to other encoders you get very different answers. The reason for this is simply that people tend to make their speed comparisons before they decide for an encoder and then never looks at the competition any more, but things keeps on changing.

When BladeEnc first was released it was the fast alternative to mpegEnc, the only free high bitrate encoder at the moment. BladeEnc then made rapid improvements in speed until it two months later became THE fastest mp3 encoder on the market. That only lasted a short while until Xing released their extremely fast (more than 8 times faster) mp3 encoder (which considered quality a secondary priority). BladeEnc still remained the fastest high quality encoder for a while, but Xing's speed spurred the competition while I started to loose interest (it was fast enough for me and the patent troubles started) and got very busy at work, making BladeEnc progress slowly.

During this time LAME, a new Open Source mp3 encoder, made rapid progress and ended up being more than three times faster than BladeEnc while still not sacrificing quality. During this time BladeEnc started to lose its reputation as the fast high quality encoder.

Recently though we have made rapid improvements with BladeEnc. Speed has increased drastically over the last versions, mainly thanks to Andre's optimizations and architectural changes.
 

The Situation Today

The fastest encoders like Xing and Gogo are still much faster than BladeEnc, but they have to some extent compromised quality for speed.

Compared to other high quality encoders, BladeEnc scores quite well. On my AMD K6-2 running Red Hat Linux 6.2 and using EGCS 2.91.66 to compile I get an encoding speed between 0.80 and 1.12 times realtime depending on the bitrate (high bitrate encoding is faster). Using the same setup, LAME scores between 1.46 and 1.70 times realtime, making it approximately 80% faster.