@ below 128 kbps AAC win out MP3 hands down. However AAC @ 128 kbps or 256 kbps doesn't bring much improvement to mp3.

Is it because AAC is not as well fine tunes as mp3? I still remember the author of MPC said something about all the model and improvement in MPC could actually be made into AAC.

After all 128 Kbps AAC was "suppose" to sound better then 192 Kbps MP3......

The quality of a specific encoder depends on the possibilities of the format and of the way the encoder does format implementation.

When it's up to temporal resolution a good AAC encoder should provide a better quality at ~128 kbps than a mp3 encoder because of mp3 format restrictions. This applies for instance to harpsichord music, impulses in electronic music, or percussion instruments.
Other than that, especially at a higher bitrate, a good mp3 encoder is competetive and can even be superior when comparing two specific encoders.

For the car buffs out there, a good analogy is that MP3 is the Chevy 350 of codecs. It's old, it sucks, it's an inferior design, but it has so much research and tuning that it ends up outperforming new state-of-the-art codecs.

If an AAC encoder had as much effort put into it as LAME MP3 has, it is mostly likely that it would be significantly better.

Let's take two glass of water from two different brands. Now let's talk about which one is more transparent. Either there's something quite wrong with one of the brands, or that would be difficult.
That's the same analogy to comparing lossy encoding at high bitrates. (Either there's a specific flaw, or are likely similar)




Wrong. AAC at 96kbps was said to sound like MP3 at 128kbps.(Nowadays this depends highly on the implementation of the encoder of both formats)
The "128kbps AAC better than 192kbps MP3" sentence is not necesarily true, (for once, because 128kbps aac is usually filtered at a lower frequency than mp3 at 192kbps).

The only thing that can be said without a doubt is that an AAC file at the same bitrate than an MP3 file is *likely* going to have the the same or better quality.


Finally, replying to the question in the thread's title, AAC is a refinement of MP3, similarly how MP3 was for MP2, and this one to MP1.
Concretely, it adresses design flaws (sfb21), pre-echo (different sizes for long and short blocks than MP3), new tools like TNS (helps on preecho and post-echo) plus a few other changes, like the new MP4 container.
Obviously, the newer extensions (HE-AAC aka aacplus) have helped as well.

What about AAC patents? I heard that MP3 patents will soon expire. Isn't that the reason AAC is being pushed?

I don't see why lame shouldn't abandon MP3 and move on to AAC (in other words, ditch MP3 and develop for AAC).

Reason is that all major players now support AAC. All ipods support AAC. Anything that is rockbox'd will support AAC. I believe that even the Zune supports AAC. The only players that won't support AAC are old things like the Rio Karma, and most of those have been broken anyways.

... faac is there for the (re)taking and NO ONE appears interested...

it also doesn't help that nero has grabbed up those who were working on other AAC encoders!

oh, hi ivan!

p.s., thanks for NeroAAC!


later

your reason is all major players support aac. they support mp3 too. as well as everyone else. so why not continue development? mp3 is here to stay.

AAC is a newer codec.

It is my understanding that there are fewer problem samples than MP3. Those problem samples can never be fixed due to the psy model issues.

AAC can be gapless. (Ogg) Vorbis is gapless. MP3 is not.
Barrring a flawed encoder, AAC sounds as good as MP3, while producing smaller files from the same content.

AAC and MP3 decode with good battery life in portables. Vorbis is a little more power hungry.

IMHO the fine job the L.A.M.E. team has done with MP3 encoding improvements, and the smaller list of devices with hardware AAC support, has slowed the demise of MP3.

By the way, I was looking hard for a player that had AAC and all the features I wanted last month. There are many 'Major' players that do not support AAC. There is a nice feature search here:
http://www.anythingbutipod.com/compare/

Edit:

I think the main reason AAC has made recent inroads is because it can support DRM, which Apple has been happy to use to sell you music.

lame mp3s are currently gapless.

aac is better at low bitrates. but with the growing storage space in PCs and portables that becomes less of an advantage these days.

some people with golden ears can hear the difference between mp3 and aac at high bitrates but they are far from being the majority.

The WIKI states that MP3 is not truly gapless:

http://wiki.hydrogenaudio.org/index.php?title=Gapless

Some other formats do not officially support gapless encoding, but some implementations of encoders or decoders may handle gapless metadata.

* LAME-encoded MP3 can be gapless with players that support the LAME Mp3 info tag.
* AAC in MP4 encoded with Nero Digital from Nero AG can be gapless with foobar2000.
* AAC in MP4 encoded with iTunes 7.0 can be gapless with iTunes 7.0 and latest foobar2000.

101 Error

Aside from the improvements to the audio, AAC generally comes in an MP4 container, and I think a major advantage there is what content, besides the audio, an MP4 can contain. This makes, for example, enhanced podcasts with slideshows and URLs possible. Unfortunately, most podcasters naturally enough wish to use the lowest common denominator--which means MP3, obviously--so there's not as many of these around as there might be.

There is no difference between MP3 and AAC regarding DRM. Both formats do not natively support DRM. That's why Apple had to specifically build a proprietary DRM extension to wrap around AAC files. There is no reason why someone couldn't do exactly the same with MP3, FLAC or Vorbis if they wanted to.

Actually, if Apple wanted to I'm sure they could release MP3s with their own DRM scheme by tomorrow. It is just a wrapper around an existing format.

What do you base this claim on?
I'll quote you some objective numbers.
Rockbox:
SVN r15250:
iRiver H140 (Coldfire CPU):
Nero AAC-LC @ 320Kbps decodes at 122.73% realtime.
Vorbis @ 350kbps decodes at 219.02% realtime.
LAME MP3 @ 320kbps decodes at 393.47% realtime.
Faster decoding time = less CPU spent filling PCM buffer = more CPU time at idle frequency (compared to full speed) = less power consumption.
Clearly in this example AAC is much less efficient than Vorbis.


Similar tests on a Sandisk Sansa (ARM CPU)
Nero AAC-LC @ 320Kbps decodes at 154.93% realtime.
LAME MP3 @ 320kbps decodes at 196.97% realtime.
Vorbis @ 350kbps decodes at 200.84% realtime.
In this example Vorbis beats MP3 and AAC.

I'm sure Rockbox's decoder implementations aren't the end-all of this argument - but they are objective numbers, and they clearly dispute your assertion.

Please see these references. A brief trip through Google will give you more.

http://www.hydrogenaudio.org/forums/index....st&p=163707

http://iaudiophile.net/forums/showthread.php?t=1730

http://www.anythingbutipod.com/forum/showthread.php?t=2891


OGG Vorbis is a fine codec IMHO. It just takes more CPU/battery power to decode.

It looks like I was mistaken about the DRM aspects. I could not find the references I remembered.
Interestingly, this seems the more likely reason for Apple to choose AAC.

http://daringfireball.net/2007/04/some_facts_about_aac

This article has a few wrong (or not totally exact) facts, but overall, yes, AAC licensing is cheaper than MP3.

Regarding the original question, AAC provides:

*increased compression efficiency
*better time resolution (=>better handling of transcients)
*correct multichannel support

Why isn't there much difference between a good AAC encoder and a good MP3 encoder at 128kbps and higher? Simply because MP3 already sounds acceptable at this bitrate, and in higher bitrates, once you reach transparency, you can't be more transparent than transparent.

I am not sure what they base their numbers on but I can give you cold hard battery life tests for both Lame mp3 files and iTunes AAC files on a 5G 60GB iPod, 16GB iPod touch, 30GB Halo 3 Zune, and a 4GB Creative Zen. The only player that suffered from a slight decrease in battery playback time was the Creative. It is ranked at 25 hours of audio playback and it got that with a -V 5 mp3 but it was able to achieve an average of about 23 hours with a 128kbps VBR iTunes AAC. All other models went passed their advertised battery times with Lame mp3 playback time equaling that of AAC playback time. So even though your numbers show the realtime decoding to be less efficient, I think battery playback time is a better indication as that is all the consumer cares about. It doesn't matter if a encoder requires more power to run as long as the player can still maintain its battery playback time. As you said, Rockbox isn't the end all and we all know that Rockbox's efficiency on some players is hit or miss.

AAC is not accepted by all my major mp3 player, my zen for example doesnt play it. yes it can if you use the worse apple encoder but if you want to use the netter nero enoder i and many other people cant play it.

Thats why i like mp3, every player plays it without problems. AAC could be nice, but is way off from being a real standard.

No. It is one:

ISO/IEC 13818-7:1997

Such a nice idea about AAC!!!

AAC is standard like MP3. AAC is like MP3 part 2. MPEG is pushing their new standard ( AAC !!! )

I agree that DRM support was one of the key elements that Apple required in order to launch the iTunes store. The fact that AAC works very well doesn't hurt one bit, either; it is my preferred lossy format overall simply because I hear fewer artifacts on the whole.

In the business climate that existed in 2001 (and largely exists today) there would be no iTunes store without DRM - the labels simply were not going to take that risk. So while we all might frown upon DRM (well, HA people especially) it would be difficult to argue that the iTunes store has not had a HUGE impact upon legitimate media downloads. It singlehandedly created the market that exists today.

Without the success of iTunes, there would be no Amazon MP3 store and no possibility of the DRM-free AAC files Apple is now offering.

DRM is now fading as a "necessary" element for legitimate music downloads, as Steve Jobs predicted a year ago; getting rid of DRM would only help Apple. In the future we might view DRM as only a stepping stone on the path towards a new system of media distribution and renumeration.

The iTunes AAC encoder can definitely hold its own. Look at some of the past listening tests, the iTunes AAC encoder either scored slightly better than or equal to the Nero AAC encoder. The more recent listening tests show that Nero AAC is slightly ahead of iTunes AAC which is also ahead of Lame mp3. So I don't see a need in complaining about the iTunes AAC encoder when it is in fact high quality unless you conducted your own blind ABX tests and showed that iTunes AAC was terrible at everything it encoded and that Nero AAC/Lame mp3 were better.

Dont know about that i am more into mp3. But on the zen forums they were saying nero has much better aac encoder then apples, apple wasnt that bad only nero was better. Thats why everybody there want to play nero implementation. But you can have 1 offcial standard but if there are 2 or more implementations ..... i can understand why not every player support it. It would be nice if every player would support. If aac would sound that much better then for example Lame 398b6 on 200kps avg vbr.

just to throw it out there, it doesn't take a set of "golden ears" to discern the difference between these formats at higher bitrates... my first ABX test (which, unfortunately, I never documented) was between iTunes AAC and LAME mp3 at 256kbps (back in early 2005), and I could almost immediately hear a difference between the two, as well as pick out which file was which format. it only takes a couple listening tests to learn how to pick these indicators out (cymbal/high-hat distortion, flattened/tinny snare sounds, etc.). that is, unless I have a set of those prized "golden ears" you're talking about and just don't realize it.

Why the laughing?

Why to stay at 128 kbs? For me itunes and nero at 100-110 kbit/s are already at thershold of transparency (while MP3 V5 isn't)
Is there any test that indicates that LAME MP3 is on par with AAC top encoders at 128 kbps? V5 doesn't produce 128 kbit/s. It's more. For loud music the bitrate goes up to 135-145 kbit/s.

It will be very usefull to form a new public test with LAME V5 and Nero/Itunes at 100/135 kbit/s. I think AAC at approx. 100 kbit/s is on par with LAME V5 approx. 135 kbit/s as here (2 personal tests) http://www.hydrogenaudio.org/forums/index....showtopic=54967

iTunes AAC at 128kbps also doesn't produce files at 128kbps, it will often produce files at around 130-140kbps. You can't directly compare 100kbps VBR Nero AAC with -V 5 Lame mp3. If Lame sounds better then it is because of the extra 30kbps it uses to encode the songs. You need files that are around the same bitrate in order to conduct a proper listening test.

Just to give you an example, iTunes AAC at 96kbps is often used as a low anchor for 128kbps listening tests. It is used as a high anchor for HE-AAC tests though.

Rockbox's eficiency on some players isn't hit and miss.
On every device with known hardware, Rockbox is more efficient than the original firmware.
Rockbox consumes more power than stock firmware on PortalPlayer 502x based devices only because the hardware is undocumented and there are probably devices turned on by mistake,


Let me attempt to illustrate how the decoding speed numbers I posted are indicators of battery playback time:

Battery playback time is strongly correlated to CPU usage on modern DAPs.
We'll use the Sandisk Sansa as an example again, (I already used its numbers when showing Vorbis is not always less efficient.)
Rockbox and the Sansa original firmware both dynamically scale the speed of the CPU based on need. The more CPU intensive the codec, the more often the CPU is running at full clock speed.
Rockbox draws 34ma idle, 36ma during playback with the CPU clocked slow, 56ma during playback with the CPU clocked high.
MPC and FLAC both playback with the CPU almost always at the slowest speed.
MP3, Vorbis? About 50% of the time the CPU is clocked fast.

Sansa's firmware draws 36ma idle, and dips and spikes similar to Rockbox during MP3 playback, as the CPU runs faster and slower.

Point being - the difficulty of decoding a codec can make a large difference in power consumption, and this battery life.
MPC playback on this sansa would consume just about 36ma average, MP3 46ma average, APE (-fast) 56ma average.
From this you can directly compute playback time - and the various battery benchmark pages on the Rockbox wiki have shown this correlation.




I just showed you objective numbers of a situation where Vorbis does not take more CPU/battery to decode.
Stop making blanket claims on this.

I understand that your numbers can show battery playback times. However that is only if you use RockBox and we all know the general population won't RockBox their hardware. The general audio population doesn't even know about hydrogenaudio either. They will be using their default firmware on their devices. Hence, I tested my Creative Zen (4GB), 16GB iPod touch, 5G 60GB iPod, and Halo 3 30GB Zune. All of them (with the exception of the Zen) were able to get the same times when playing AAC and mp3. I am not saying that my results are perfect or what the whole world should go off of them, neither are yours.

Your results show one thing yet my results show another. I even went so far to test my iPods with iTunes Store DRM content and compared it to 128kbps VBR iTunes AAC content. Cnet did their tests and showed that on average, players got about 80% of their advertised battery playback times with DRM content (whether it was AAC or WMA). I found that my iPod's battery playback times did not decrease with the use of DRM AAC content.

So AAC can last just as long (or sometimes longer) as mp3 on devices using their normal firmware. The only exception was my Zen but then again, people who use that device recommend using only mp3 as the Zen's battery playback time will decrease if you use anything else (like AAC, WMA, etc.).

edit: grammar

http://wiki.hydrogenaudio.org/index.php?title=Vorbis

I see your data Soap. I see far more data indicating that OGG Vorbis is CPU intensive and results in shorter playback times than AAC or MP3. Perhaps the WIKI and all the other resources are mistaken. I am as yet unconvinced given the body of evidence.




by xiphmont (80732) on Monday August 14 2000, @09:35AM (#857490) Homepage

http://features.slashdot.org/article.pl?sid=00/08/14/1034209

This reminds me of Carl Rove's math.

All I was arguing against was blanket statements.
Also notice the architectures of the hardware I quoted. There has been less effort to do ASM optimization on x86, and lots of effort since 2000's reference decoder to optimize on embedded processors. Many of your references are dated.

itunes aac and lame mp3 were tied at 128kbps in this test. if most people couldn't hear the difference at 128kbps, it is unlikely they would at higher bitrates.

And this isn't a blanket statement?

People please, let's keep this thread on topic.

Actually, AAC is like MP4 Part 3. (Sorry; could not resist.)

We are all about smart***. Yes, mpeg 4 p3 or mpeg2 7. Whatever.
That's why I said is like . Please, interprete my message correctly. I am informed about AAC and have read that wiki and some others articles too many times before. All I want to say that AAC is standard pushed by the same MPEG that standarized mp3.

Yes, but that's not to say that each decoder in rockbox is optimized to the same extent. I remember last year in the rockbox forums when people were asking about AAC not playing in realtime, and the answer was that there was no devs interested to optimize FAAD because none of them used AAC.

From the subversion commits page on rockbox.org, the last commit that tried to optimize FAAD was by Magnus Holmgren on 24 Sep 2006 19:00. No i'm not knocking rockbox, I use it and have bought my last three DAP's based on the fact they run rockbox. I'm just saying it's unfair to test efficiency based on rockbox because not all decoders are optimized to the same extent and not all architectures perform the same.

EDIT: Grammar

well, in that case if those of us "golden-eared" folk are those who don't fall within said majority, then I have to admit you made a good call (since I'd give LAME CBR @ 128kbps about a 3/5, quality-wise)... though now I'm feeling inspired to do another ABX test @ 256kbps to see if my ears still tell me the same thing they did three years ago.

as for my original comment, I remembered after posting it that I had used iTunes to encode the mp3 versions of the files I was listening to, not LAME, so there's a good chance that was part of the problem.

Most companies will optimize a codec until it hits a certain runtime target and then stop. The numbers you get reflect this, not some underlying reality of how each codec performs in some mythical state where the format alone and not the implementation determines performance.



Sure, but the opposite is also true.



What data? The runtime of the iAudio firmware and a comment from Monty about an obsolete decoder thats not even used on portables? How is that any more or less valid then what Soap has?

Furthermore, since you have no idea about the respective quality of these decoders, how can you even draw a conclusion from this data at all? IMO this entire argument is nonsense. You can't pick a random decoder and decide if the format is faster or slower based on a single data point.