Mythbusting: The iTunes MP3 encoder doesn't suck

Sometimes computing axioms get started that no-one bothers to go and check, or recheck, later on. They just get repeated parrot-style over and over until everyone believes it. A bit like religion.

One of these axioms is “The iTunes MP3 encoder sucks. Use LAME instead, it’s better.”

Well, thanks to the efforts of Sebastian Mares, who organised a mass listening test of various MP3 encoders at 128K, we now know that this is in fact, not true.

You can read the detailed results for yourself here, but the short version is that iTunes, LAME, Fraunhofer, and Helix, all perform near identically and all sound excellent. LAME was in fact the slowest of these four, although encoding speed isn’t usually an important distinction.

So the next time you want to jump through hoops to avoid using the iTunes MP3 encoder – don’t bother. It’s just as good as LAME.

MP3 128K listening test results summary

This entry was posted in Geeky stuff and tagged , , . Bookmark the permalink.

8 Responses to Mythbusting: The iTunes MP3 encoder doesn't suck

  1. Brent says:

    Lame destroys itunes. Use -V2 (new alt-preset standard).

    • stupd says:

      oh, cmon man .. the test is in 128kbps! and I suppose you know that alt-preset-standard produces at least 160kbps files!

      • Badger says:

        Too bad the link doesn’t work anymore. I wanted to see if there were any other results for more reasonable bitrates, and/or with VBR. Really, if you’re doing listening tests, or just listening to music at all in 128bps, it’s not going to matter which encoder you bother with; your music is going to sound terrible regardless. If I recall, these studies also show that iTunes performs below par with VBR.

        Unfortunately, iTunes’ mp3s suck in other ways compared to LAME encoded mp3s. For example, it doesn’t provide gap information in its tags for gapless playback. iTunes supposedly uses some hokey guesswork to try and remove the gaps, but the simple solution would be to just provide that exact information in the mp3 itself and skip the gaps.

        So, uh, congrats on your 128kbps non-suckage iTunes, though I’ll stick to superior encoders (e.g. LAME) for encodes I actually want to listen to.

  2. John Wheat says:

    I am quite satisfied with the sound quality of iTunes mp3 encoder … But … After Ripping a HUGE library to mp3 with iTunes … and then updating to (iTunes 9) … my iTunes will not: Play, or Import, any of the previously Ripped files.
    Did they upgrade the mp3 encoder to a version that is not compatible with previous versions?

  3. Oli gray says:

    Hmm I’ve been using LAME for years now to keep the flexibility of a universal format (MP3) and because I noticed that with electronic music the iTunes encoder was not as good. However, what I’m trying to find out now is does this still apply in 2010 or has Apple made improvements to their ripping algorithm in the last few years?

    This article would be useful if it weren’t for the fact that it’s based around 128kps – that’s a decidely lossy format in my opinion. I cringe when my older MP3′s start playing from 1999 ;) I use LAME at 320kbps VBR

  4. myname says:

    Wow, are you really going base your statement on subjective listeners? The test didn’t even use the same bitrate for each encoder. Of course Itune’s mp3 encoder will sound better than lame when it is set to a high bitrate. Nice try.

  5. David says:

    What the hell are you talking about? All the encoders were set to 128K, did you even read the linked article?

    And yes, I’m going to base it on “subjective listeners”, because that’s the whole point – to determine the perceived quality of the resulting compressed audio. You can’t measure that. Perceived quality is, by definition, a subjective quantity, which is why the survey uses a large number of listeners.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>