BladeEnc Encoding Speed

The speed comparison between BladeEnc and some other popular encoders that
used to be on this page was so old and outdated that I decided to remove it.

Instead I have written a piece below on the subject which I hope you might
find interesting and enlightening. At the end I make a general speed comparison
(no numbers) which you can skip to if you don't wanna read all this.

Some background and the importance of encoding speed

The speed of the encoder used to be of great concern for people a few years ago. The reason was simply that both the mp3 encoders and computers were much slower back then, making it sometimes take many hours to get a record encoded (I remember it taking around 20 hours to encode one hour of music using good old mpegEnc on my Pentium 133 ;). This was very frustrating, especially when you wanted to encode all your records (and friends records) to mp3, forcing you to leave your computer on during the night to get the encoding done and then wake up next morning to discover that it was only halfway through the first record! A lot of sites were comparing the speed of the different encoders and joy spread throughout the community when a new, faster encoder was released.

However, since then a lot of things have happened. Modern encoders have much faster algorithms, new compilers produce faster code and todays computers are much faster than what we used to have. Today it only takes me around an hour to encode a record using the latest version of BladeEnc on my 350 MHz K6-2, which must be considered a low-end system by todays standards. This is more than acceptable. I can easily have the computer encode 5-6 complete records during the night if I want to. Having faster encoding would of course be nice, but personally I don't care so much. I'm much more interested in quality. If it takes me 60 or 100 minutes to encode an album doesn't matter so much since I only do it once. But I'm going to listen to it maybe hundreds of times through the years.

What has happened though is that thanks to this progress, new possibilities and needs have appeared. It's for example now possible to encode in realtime on most decent desktop computers, making it possible to for example do realtime mp3 netcasting or recording radio to the harddrive in mp3 format or use mp3 encoding in online conferencing systems. For all of these areas speed is once again an important factor, making it interesting to push the envelope a bit further. The faster mp3 encoding we have, the more people can use these kinds of technologies and the less they slow down our systems when we use them.

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.