I recently got into a discussion about the advantages of AAC over MP3. Seeing as how 1) AAC represents so many years of work and research over MP3, 2)listening tests have shown AAC to be superior to MP3 at 64kbps and 128kbps, I thought it fair to say that AAC was superior at all bitrates. After all, the general sentiment around here is that AAC files are about 25% smaller than MP3 files of the same quality. So at the same bitrate, AAC files should be of superior quality. Of course to be absolutely sure, one would need to perform listening tests. But I felt my statement was reasonable enough to stand on its own.

Others disagreed. They say there's no way one should make such a statement without listening tests to back it up. Regarding my first point above, they wanted an explanation as to what problems MP3 had that AAC improves upon. And they dismiss my second point, saying that AAC is tuned for lower bitrates, so of course it wins at 128kbps and below. And since it's tuned for lower bitrates, it may do weird things at higher bitrates.

I say their argument is rubbish, based on guesses and speculation, but I'm wondering what people around here think. If you agree with me, please help me in explaining to them what improvement (technically) that AAC includes over MP3. Also, the discussion was focused around LC-AAC.

So, is it safe to say AAC produces better results than MP3 at all bitrates?

No.

That answer isn't helpful at all. negritot went a long way to elaborate why he believes AAC is better than MP3 at all bitrates. You should at least explain why you think it's not safe.

I could only say this:

A perfect AAC encoder is always better than perfect MP3 encoder

But there are no such things as perfect AAC encoders, or perfect MP3 encoders .

Howevever, considering level of maturity of few AAC encoders and maturity of MP3 encoders it could be said that on same bit-rate good AAC encoder is better than MP3 on most music material.


Btw, AAC is not tuned for low bit-rates - this is just plain untrue. "sweet spot" for LC AAC is around 96 kb/s for 44.1 kHz material (below which quality starts to dettoriate significantly), while the same sweet spot for MP3 is around 128 Kb/s - this is because of more efficient coding tools, not because of "tuning" - however, this absolutely do not change the high bit rate perofrmance of AAC (why would it?).

If you analyse deeply the tools, you'd notice that most of them are same as of MP3, but with improved efficiency (no quality sacrifice). Only Intensity Stereo and PNS destroy data and suits very low bitrate coding.

AAC has this extra features, KB - Sine window switching which do really improve the overall subjective quality.. provided the limitation of KB window is taken into account.. I must say Kaiser Bessel window is very good.. You can notice that inter coefficient aliasing noise is greatly reduced !

As for the promises that TNS filter, I still have some problem in finding the full capability of the specifications.. It seemed to me that under some conditions, the TNS can become unstable at the decoder.. Tonal components tend to be wrongly reconstructed resulting in "cracking noises"

The MS Stereo specs also provide for individual scalefactor bands switching.. an added improvement over MP3.. and increase coding efficiency..

The predictions under some situation can improve coding efficiency by a lot ! Clips like binaural.wav that contain a lot of tonal components sweeping from left to right are also highly stationary.. The enthropy of predictor gains of the Main Predictor can be as high as 1500 bits per stereo channels !

There is also the LTP which I had not explore yet which is supposed to be a much improved way of prediction over LC and Main Predictors..



I must say that AAC is definately superior to MP3 ! Not only there is improved coding efficiency.. there is improved audio quality which I think MP3 cannot reproduced at all bitrates ! (the KB windows..)


But I still think that the 8 short blocks of AAC is highly inefficient !!

Off-topic, but "cracking noises" looks to me as definite bug/issue of reflection coefficient quantization in encoder where you end up with improper requantized reflection coeffs in the decoder... final result is clipping in some frequency region causing nasty artifacts.

Erm, why should that be so?
IMO, LTP uses a completely trivial prediction that does not gain anything for most real world signals. There are some signals where LTP actually can be useful, that's the reason why it was standardized, but the number is limited, and in no relation to the additional workload, again IMHO.
That is the reason why we did not include LTP in compaact!, although we implemented it.

Alexander

mp3 has been openly tested more thoroughly (i.e. lame, 3.90.x) and is believed to be very high quality (--alt-preset standard)

mp4 just hasn't been tested as much, and unlike mp3 - which has a clearly superior codec (lame) - decent mp4 encoders are many and only are beginning to be tested to the degree that lame has been.

the obvious gray area is in high bitrates, which will make testing even more cumbersome.

so it would be hard to claim a general statement like "mp4 is better than mp3" and not look like ignorant and without proof.

the potential for mp4 to be greater is obvious in the specs (cue ivan's comment here "A perfect AAC encoder is always better than perfect MP3 encoder") but not realized yet.


just my .01

jstu to put in som non-developer snf just plain old hands on feelings.

i haven meet a music track that was better encodet with lame mp3 than on nero/psytell aac.
the opposite i found quite often but hhthere has also bene many track where i could notice the difference

I'using -streaming quality (sligt above 128kbits

Ooppss sorry.. I thought that MP3 too has a "anti aliasing" filter at both the encoder and decoder for improved audio quality.. I wondered how effective it is in comparison to the KB window of AAC ? I supposed that a mdct length of just 36 time domain samples and a sin window has a lot inter-coefficient spectral leakage ?

Well, I haven't really look into the working details of LTP.. but the specs allows LTP to be used for both LONG and SHORT Block(I would love to increase the coding efficiency of the short blocks !).. whereas Main and LC predictor for long block only and have to be reset every time there is a block switch.. and it after the return from a short block.. it would take another 2 -3 long blocks (Main Predictor) before the LMS algorithm (Main Predictor) becomes optimum.. In cases, where there is a lot of block switching such as dmb.wav, marc_nelson14.wav.. LC and Main Predictor isn't very efficient.. Perhaps LTP may be better even though prediction is done in the time domain ?

Maybe you can compare the coding efficiency of LTP, Main and LC predictor?

Possible.. but from my experience with Linear Prediction of time domain Speech signals, "cracking noises" occurs all the time..

In the case of AAC, it oftens occur when there is human speech with a lot of closely spaced tonal components.. such as a person singing.. The standard mode of TNS activation as proposed by ISO specs would be activated! But I think there is problem in the reconstruction of the tonal components.. Tones are very sensitive to coding errors...

the argument is with me on the Arstechnica forums.

Ivan, what about this: http://www.hydrogenaudio.org/forums/index....ndpost&p=183117

you say that you guys do tune your codecs (specifically HE-AAC), or am i misreading something?

Hmm, no, this is unfortunately only allowed in the scaleable profiles.

Menno

Yes - new major release of AAC encoder is under development and testing - it will have some completely new coding modes and tuned LC and HE core.

Really? I thought it is for LC profile ?

Wish iTunes would get "true" VBR with presets (like Nero) so I can easily rip, tag, and intergrate automatically into my collection.

Check 4.6.6.1 in 14496-3

LTP is only allowed on long blocks to keep the bitstream backwards compatible with MPEG-2 AAC.

Menno

Thanks to everyone for your comments! You've been very helpful.