Nero is the only retail product supporting AAC+. Does anyone think it has any chance of ever being supported by the broader consumer market? Like portable audio players and car CD players?

*dons flamewar* Who needs it at least at ~80 kbps and above?

Point taken. So then let me add to my question, will we ever see VBR AAC supported in the general consumer market?

IMO, AAC+ is likely to have more support in mobile phone.

I found some test about codecs and their battery consumtion. (ex:iriver battery test)
I really want to know about AAC+ energy consumtion. How much different when compare to Ogg, WMA, AAC or MP3? Anyone have information on this?

Even without audio playing capability, smart phones are hardly survive a day. It would be great if AAC+ is battery friendly.

Nero is one of them. There are a lot of other companies supporting HE AAC:
- In the encoding front you can find companies like like RealNetworks, Helix, Sorenson, Coding Technologies among other initiatives.
- In the Steaming front you have Nullsoft (Winamp), Yahoo!, XM Satellite Radio, Digital Radio Mondiale, and many other players like Foobar2000, etc...
- In the hardware arena you have Siemens, Motorola, O2, Nokia, all the 3GPP members, Apple in a near future, etc...

HE AAC has also been approved as a mandatory compression format for the ROM zone of DVD-Audio by the DVD Forum in June 2004.

Do not worry, HE AAC will be the MP3 format of the future. When? soon, very soon. One of the most important reasons is that most cell phones will have a lot of memory or flash card support and they will be able to play AAC+ and even AAC++ audio thus taking most of the market share of the current portable audio solutions.

The revolution for internet radio is only just getting off the ground now (or at least soon) I think. That's another area where it will eventually dominate I think.

By the way, I'm confused. I know Nero supports HE-ACC, but ACC+ v1 and v2 aren't just HE-ACC, correct? ACC+ is HE-ACC plus a few other tricks, like SBR and what not. So technically Nero does not actually support ACC+ (yet).

AAC+ and HE-AAC are exactly the same thing.

Hopefully XM radio will start streaming in AAC+. If they did, I'd subscribe again in a heartbeat. The content is incomparable.

This a basic abstract about the AAC family:

AAC = MPEG2 AAC ~= MP3 + TNS + TP (It is not an upgrade of MP3 since it is not backward compatible but uses all MP3's features in a better way).

MPEG4 AAC = MPEG2 AAC + LTP + PNS
There are several profliles depending on the decoding/encoding complexity, required power, delay, bandwith characteristics, error resilience characteristics, etc... The most used profile in the PC arena is the AAC LC (Low Complexity) = MPEG4 AAC without LTP.

HE-AAC = SBR + AAC LC
Coding Technologies, developers of SBR, named this coding aacPlus™, also known as AAC+, HE-AAC, AACP, AAC-LC+SBR, etc... SBR technology was prevously introduced in the MP3pro codec.

HE-AAC v2= PS + HE-AAC
Coding Technologies, developers of the MPEG Parametric Stereo, named this coding aacPlus™ v2 as a new revision of the previous release. It is also known as AAC++, EAAC+, Enhanced HE-AAC, EAACP, HE-AAC+PS, etc... Recently it was standarized by ISO as HE-AAC v2.

S-AAC...(Just guessing, not yet released but in Reference Model 0 stage)
Since MPEG is focusing in multichannel, the next standard will be something based in the Spatial Audio Coding tool standarized as MPEG Surround, that allows to do someting similar to PS but aimed to 5.1ch or 7.1ch content. This could be named as S-AAC, AAC Surround or AACS, Surround HE-AAC, [Put your favorite name here]. There isn't an official name for it yet.

Terms and acronyms:

AAC Advanced Audio Coding, developed by Dolby Laboratories.

TNS Temporal Noise Shaping is a tool designed to control the location, in time, of the quantization noise by transmission of filtering coefficients.

TP Temporal Prediction is a tool designed to enhance compressibility of stationnary signals.

LTP Long Term Prediction is once again a prediction tool. This one requires less computation power but it is far more complex than the one used in MPEG-2 AAC, while providing comparable coding performance.

PNS Perceptual Noise Substitution, allows to replace coding of noise-like parts of the signal by some noise generated on the decoder side, so the decoding result is not deterministic among multiple decoding processes of the same encoded data.

SBR Spectral Band Replication is a tool that creates associated higher frequency content based on the lower frequencies and coding it as statistical information: level, distribution and ranges. Each of these parameters is encoded separately, taking account of their distinctive characteristics. It involves reconstruction of a noise-like frequency spectrum by employing a noise generator with some statistical information (level, distribution, ranges), so the decoding result is not deterministic among multiple decoding processes of the same encoded data. Both ideas are based on the principle that the human brain tends to consider high frequencies to be either harmonic phenomena associated with lower frequencies or noise, and is thus less sensitive to the exact content of high frequencies in audio signals.

PS Parametric Stereo, the stereo image information is separated from the mono signal being represented as a small amount of high quality parametric stereo information. The scheme relies on dissecting the incoming audio signal into three ‘objects’ that are a common constituent of all audio signals: transients, sinusoids and noise The stereo information is efficiently parameterized. Each of these objects is encoded separately, taking account of their distinctive characteristics. Like PNS and SBR the decoding result is not deterministic among multiple decoding processes of the same encoded data.

SAC Spatial Audio Coding exploits inter-channel differences in level, phase and coherence to capture the spatial image of a multi-channel audio signal relative to a transmitted downmix signal. It encodes each of these cues separately taking account of their distinctive characteristics such that the cues, and the transmitted signal, can be decoded to synthesize a high quality multi-channel representation allowing higher compression than separate channel coding.

I hope this clarifies a little all the confusion about the AAC codec family and the technology it uses.

Regards,
Oki

Edit: typo and added details.

My friend, MX Satellite Radio is broadcasting in AAC+ since quite some time. In the XM Satellite Radio FAQ you can read this:

"XM searched the world for the best sound quality technologies and found them in customized CT-aacPlus audio encoding with Neural Audio optimization, which provides superior sound quality remarkably close to Compact Disc."

and

"The key to XM's outstanding sound quality is CT-aacPlus, a third-generation audio encoding technology."

Hurry up!!!

Regards,
Oki

Thanks for the in-depth reply Oki!

That's the satellilte broadcast, not the internet stream. Why don't you pay attention to what I am talking about before trying to correct me?

Wow, I took it as Oki was trying to help you....what's the big deal if he didn't understand EXACTLY what you were saying....?

The big deal is excessive "sensitivity."

I'd still like to know what codec AOL is using to broadcast 72 XM stations to its subscribers. AOL is secretive but the fact that they too have inked a deal with Coding Technologies makes me suspect they'll shift all Radio@AOL to this AAC+. The problems with keeping steady volume levels (it is a beta) when there's lots of bass makes me suspect that SBR is in there. I've converted my laptop to an AOL/XM stream radio using the fat AOL client and a direct USB cable to my JVC receiver. It sounds awesome.
As to Coding Technologies AAC+, I think it's the shiznit. I use it for music on my Pocket PC (encoded at 80 kbps using Magix MP3 Maker Deluxe 10) and I do think play time is longer than with MP3s or Ogg. But, I'd have to put MP3s on the CF microdrive if I wanted adequate variety and that certainly uses more juice than running off the 2 Gb Sandisk SD card.

What software do you use for playback? I tried most of the 3rd party players but ended up just using WMP with MP3 (LAME APS).

BetaPlayer, but the new incarnation redubbed TCPMP works fine, too.

I can give you the computational complexity of several decoding implementations on a ADSP-218x DSP:
MP3: 36 MIPS
AAC: 48 MIPS
HE-AAC: 48 MIPS
HE-AAC v2: 66 MIPS
This can give you an approximate idea about the diffenrence between these algorithms. But remember that the power consumtion of the processor is not the only thing you have as a load of your baterry; you have a memory, an analog amplifier, a display, etc... so the global difference in power consumtion of a portable audio device should be less than the difference in computational complexity when playing back different kind of audio codings.The big load on a battery is the OS, the display controller (now they even have 3D accelerated functions based in OpenGL), the screen and the radio module. Playing AAC+ or MP3 should not be much different when considering the life of the battery.

Regards,
Oki

I found the link. The free version sounds awful. I guess it's 24 kbps WMA. Will the pay version really sound better than 64 kbps WMA that is available directly from XM online?

That sounds very wrong.

For once, HE AAC should consume much more CPU power than pure LC AAC, as besides the LC part, it has the SBR part to decode.

And HE AAC v2 should consume a little less than HE AAC, since the decoding is done in one channel, and only later the spatialization information is applied to the stream.

For further proof, I point you at this FhG page:
http://www.iis.fraunhofer.de/amm/techinf/a..._dsp/index.html

A stereo LC AAC decoder requires as little as one DSP56300 @ 25MHz
A HE AAC decoder, OTOH, requires one DSP 56300 @ 80 MHz (and more SRAM)

SBR and PS algorithms were developed by Coding Technologies and your link points to a competitor. A competitor such as FhG will not give you good numbers on their technology (Remember that Coding Technologies was a spin off of FhG) since they do not have the latest developments on SBR implemented in their products. Just look at the link you give, you can see that FhG does not have enough experience in HE-AAC since they only have one implementation of HE-AAC compared to 8 implementations of the AAC-LC algorithm. Simply their SBR know-how is not mature enough. I will explain why my numbers are closer to the reality than those from FhG:

FhG is giving you the computational complexity of High Quality SBR, this makes HE-AAC 30% more complex than AAC-LC but Coding Technologies released a Low Power SBR algorithm with 30% less computational complexity. Subjective quality test results demostrated that there was no statistical difference between HQ-SBR and LP-SBR when they are incorporated into AAC decoders and CT implementations use CT's latest and more advanced method, being chosen as a standard by 3GPP. That leaves AAC-LC and HE-AAC (using the new LP-SBR algorithm) at the same level of complexity.

Why does HE-AAC v2 need more computational power? Because Parametric Stereo needs the HQ-SBR tool and it can not be implemented with the LP-SBR. The huge difference in power consumtion comes from this fact.

Note that implementations on different platforms are not proportional and you always have to take into account the processor you are going to use before evaluating the difference in complexity. In the page you are giving, If you take the ADSP21060, you would conclude that MP3 decoding requires the same speed than AAC-LC decoding, 40MHz.

Regards,
Oki

Edit: typo

That's interesting, Oki. Isn't it likely that CT has developed optimizations for SSE extensions on Intel chips, though? I'm a Mozillian and I've been amazed by the Firefox speed improvements achievable by builders like mmoy who optimize for chip features, cut cycles and so on. I've been wondering if that's part of what CT's deal with AOL involves. AAC+ surely is less taxing than a VBR Ogg file, don't you think?
As to the question about how XM on AOL sounds ... it certainly beats any 64 kbps WMA by a wide margin. I noticed that shifting DAC processing from my 1.5 mhz Celeron notebook to my new JVC receiver by connecting with USB cable eliminated breakups and distortion.

Improving power consumption in the PC arena is not important, most computers can play HE-AAC and HE-AAC v2 without any problem, using less than a mere 2-3% of the resources. CT should focus on improving HE-AAC v2 on several DSPs or researching on a Low Power Parametric Stereo algorithm, 3GPP members would be very welcome.I will use real values for estimating the power consumtion of AAC compared to OGG:
Rio Karma has a 3.7V 1600mAh battery and it can handle 16 hours of MP3 and 11 Hours of ogg, that means that the relative difference in power consumption is (Tmp3/Togg - 1) x 100 % = 45% But the power load of MP3 decoding is not that much, most of the power is taken by the hard drive. An ARM7 needs about 10MHz to decode MP3 and about 180Mhz for OGG (for this purpose Rio Karma has 2 x ARM7 processors running at 90MHz) this is 18 times more power for ogg than for MP3!!!! If we do some calculations, it means that Wmp3 = 1 /37 Wtotal. That means that the MP3 decoding uses only Wmp3 = 10mW and OGG needs 180mW!!! This numbers make perfect sense because iPod Shuffle with a 3.7V 220mAh battery provides 12 hours of MP3 or AAC audio (note that the power requirements are the same for AAC than for MP3). The power consumption is about the same because, for the iPod shuffle, Wtotal = 67mW. Maybe the decoding process is taking 1/4 or less of the total, giving numbers very close to those from the very efficient ARM7 processor.

Concluding,
1st: Wogg ~= 18 x Waac;
2nd: Waac ~= Wmp3 in the newest implementations.

In the same way you can expect similar improvements in HE-AAC decoders in the near future, and we will see that HE-AAC decoders require the same power than MP3 decoders.
The page you give is a perfect example of what I try to say, compare the 14.75h of MP3 playback with the 9.5 hours of OGG using the same hardware. The conclusion is similar to the Rio Karma one.


Regards,
Oki

Edit: typo

LOL. They are not competitors, they have worked as partners since CT spun off! Guess who made the underlying MP3 and AAC encoders in MP3pro and HE AAC? If FhG really regarded CT as a fierce competitor, they would tell them to screw off and go find another encoder.



So you make conclusions of their experience based on how many DSPs they develop to? And later you think twice and decide the fact is that FhG is using another variant of SBR than CT? Bleh.



This is bullshit. Their SBR know-how is just as good as CT's. Why wouldn't CT want a partner as powerful and influential as FhG? Sure, FhG would make more profit in selling DSP implementations. But CT would have their IP licensing income guaranteed.



Got proof of that? That is really hard to swallow based on most people's experience.



Duh, that's precisely why I only mentioned the 53600 on my post.

>An ARM7 needs about 10MHz to decode MP3
>ADSP-218x DSP MP3: 36 MIPS

The ADSP is a cisc processor - (ARM is risc?), and is able to handle 3 operations per instruction cycle (a multiply, add and move for example) - all instructions are done within a single instruction cycle (unlike an intel processor, perhaps even the ARM because of the limited risc instructions).

So why is a DSP processor (which is good at maths) taking 36MHz (which is really 36*3 on the ADSP or 108MHz) to decode something a 10MHZ arm processor can decode? Something doesn't seem right...

The answer is very simple: different implementations of the same algorithm give different performances and if they are implemented them in different hardware platforms then they are not comparable at all. You can find some info about both implementations here:

ADSP-218x DSP MP3: 36 MIPS solution by Nuntius
ARM7 MP3 Soution by Spirit DSP

Best regards
Oki

edit: links added

CT used the FhG algorithms as the core codec because of an obvious reason: it was a well known code for CT engineers since they were very involved in the developement of those implementations when they were part of FhG.
CT has better relations with far more powerful companies like Philips and Matsushita. FhG and CT are competitors, I never said that they were fierce competitors, that sounds like if they were enemies!!!! They will always be partners because of licensing issues, but nothing more than that. You can see that they are not that close, we have an example of that in the response for the call for proposal on MPEG Surround. FhG and CT were not together, One joined with Agere and the other one with Philips.


As I said before, CT already has bigger partners like Philips but the situation is not related to partnerships. The scene is very simple, the LP-SBR technique developed by CT is too recent to be already assimilated by the rest of the partners of the MPEG like FhG, Ahead, etc, remember that it is even newer than aaPlus v2, not yet supported by any FhG embedded implementations. But it is a question of time, I am completely sure that FhG and many others will incorporate LP-SBR decoding in their hardware solutions in a near future, and MPEG Parametric Stereo as well.


It is not that hard, you just have to read the papers from the Audio Engineering Society or the information about embedded aacPlus v2 decoder implementations from Coding Technologies. Find the Subjective quality test results between HQ-SBR and LP-SBR here.

Regards,
Oki

Edit: fast typing error, Ateme replaced by Agere (thanks to Gabriel and Ivan ).

If this number really makes sense, flash memory players [no hard drive] would offer ~18x less battery life than MP3. This is insane! From what I read by some people, battery life dropped by ~30% (depending on the model) which could, of course, be really annoying.

Mind you that Ahead (today Nero) had LP-SBR implementation for quite some time - almost as long as the regular HP-SBR implementation, definitely more than one year

If I remember correctly - but I might be wrong, LP-SBR patents are coming from another company?

HE-AAC v2 like we call it is also supported by Nero - we will release the encoder very soon - and people from HA were seeing it long time ago during the first beta tests.

Sorry, not yet Ateme

I think the right word is Agere

Hopefully we will see your embedded technology in portable devices in a near future, It will be a big step forward for Nero.
You are almost right, LP-SBR was initially developed by Matsushita Electric Industrial (Panasonic) but implemented along with CT and NEC. Technology and intellectual property for low-power SBR was contributed by all three companies but Coding Technologies is the licensing agent for LP-SBR in HE-AAC according to CT, NEC and MEI joint press release.
Soon when? We all are waiting for your solution to be released.

Regards,
Oki

Actually ShowTime Mobile will be a first Nero product where this technology is widely deployed. Should have a good impact on a battery life


Thanks, now it is much more clear.


I cannot promise the exact date, but after the quite some time, the things are being finalized - The new encoder is under heavy internal tests now, and being optimized for performance - it will bring improvements, as far as the very low bit rate goes, and also it will have Parametric Stereo.

Portable Audio devices with hard drives use a cache for storing the music when playing, so the HD is not working 100% of the time, only a little fraction of the time when filling the memory with the HD data, so similar conclusions could be achieved for flash memory players.

The impact in battery life when moving from MP3 to OGG is not 18 times because there are other modules that load the battery. A typical power amplifier in a portable device takes around 0.6W from the battery and the display driver and panel is taking similar values and you always need a memory driver/bus. Some manufacturers are removing displays but you could never remove the basic modules. This fixed power consumption makes negligible the difference in battery life between MP3 and AAC decoding in the iPod Shuffle.

Basically, bigger fixed consumption means a lot less difference in battery life impact between different decoding algorithms.

Regards,
Oki

Thank you Oki for your contribution in this thread.
It has been very informational.

You are welcome.

I am sorry. XM Satellite Radio is broadcasting in HE-AAC and XM Radio Online is streaming in WMA v2.

Performing more than one instruction per cycle is called superscalar, not CISC. CISC CPU's can generally take more than one cycle to finish an instruction (but the instruction can be a complex one), RISC CPU's contains fewer, simpler instructions and will always only use one cycle per instruction.

Both the RISC and CISC terms are irrelevant in modern CPU's, as the instruction set is not the real machinecode anymore.

Anyway, comparing MIPS and Megaherz is dangerous

This is misleading.

HE AAC targets different audience than MP3. It will never replace MP3 at the segment where vast majority of people use MP3 - for transparent or near transparent encoding. HE isn't designed to achieve transparency, but to improve quality at low bitrates. These two codecs don't play in the same league.

Same holds for HE AAC vs. normal AAC.

I remember the quality and speed of the very first MP3 reference encoder, it took me 4 minutes to compress 40 seconds. MP3 technology has improved a lot in speed and quality and I am sure that AAC and the rest of the related technologies such as SBR, PS and SAC will evolve as MP3 did once.

If you extrapolate the recent improvements in quality of the HE-AAC encoders and taking into account that MP3 improved a lot, I am sure that HE-AAC @ 64kbps will have the same quality than MP3 @ 128kbps, the most used bitrate in MP3. It is true that MP3 is now used in a wide range of bitrates, mostly from 96 to 192kbps, but HE-AAC v2 (including HE-AAC for medium btrates) and AAC-LC cover the whole range and even more, since it supports multichannel audio, low bitrates, error resilence, etc...

Anyway, you are completely right when pointing that HE-AAC can never be considered transparent, even with high bit rates. But there are a lot of people over there considering that 96Kbps MP3 or 80Kbps WMA is more than enough. Those will always have 48kbps HE-AAC.

And do not forget streaming...

Regards,
Oki

It already does. For internet radio, 64 kbps HE-AAC is much better than 128 kbps WMA.

Oki said MP3 though, not WMA, and there is a fairly big difference between the two in my humble opinion. Honestly, WMA isn't all that hard to beat no matter the bitrate. I agree with Oki though. With enough time, 64k HE-AAC will probably be as good as 128k MP3. I'm really looking forward to testing Nero's HE-ACC+PS encoder when it arrives, and I'm especially looking forward to radio stations moving away from MP3Pro, especially for orchestral stuff.

Thank you Oki, this is one of the most valuable thread of HA I've ever read. Thank you very much...

But, about the future of AAC, I doubt it will replace MP3 any day, at least it's not as soon as you think

AAC will play great part in mobile devices, streaming... but in other sectors, where low bit-rate is not critical, AAC maybe won't have its future brighter, hopefully some lossless codec will...

Thank you FrzzMan, but IMHO I am far from being a guru, just an average signal processing lover.

In a furure where AAC (and family) and 5.1ch will be the standard in DVB, DAV, DVD2 (HD-DVD or Blu-ray) and 3G telephones; In a world where all the consumer devices support this encoding, who is going to use the "old" MP3 format with their inherent disadvantages when you have more quality for the same file size? MP3 will be supported just for backward compatibility.

For HQ audio you can always use AAC with a high bitrate and for lossless compression you will have MPEG ALS and SLS, the MPEG standards in lossless audio. Remember that all of them share the same container: MP4 for even more compatibility.

Regards,
Oki

Winamp 5.1 supports aac+ (HE-AAC) It was "leaked" (if you can call it that as people were downloading it from winamps site.) There are a number or online radio stations streaming using this method, so the support is growing.

Anyway...

Winamp 5.1 beta 3 (recalled -- unauthorized on filehippo.com )
provides AACPlus Encoder v. 1.1 from Coding Technologies. Options are for AAC+ versions 1 and 2 at rates from 8 to 128 kbps and 32,000 and 44,100 hz.

I just ripped directly to AAC+ my first files using the new Winamp. I was surprised that Winamp gives them the AAC suffix, but I prefer that to MP4 which may be mistaken for video. They played fine with XMPlay on PC and BetaPlayer on Pocket PC.
It's hella faster and easier than EAC to FLAC, retaining WAV, then using Magix MP3 Maker 10 Deluxe to convert from WAV -- that program recognizes no lossless. But, EAC gets tag information from freedb rather than Gracenote, so that provides opportunities for two sources of inaccurate, idiotically arranged ID3 information which can then be time-consumingly revised.
It would be mighty nice if somebody figured how to direct EAC to use the Coding Technologies encoder in Winamp 5.1 .

That was a lot of information about AAC - but I am still not sure what to use if I want to compress music with a quality similar to lame -alt-preset standard ?

I understand that you can't give an exact answer but an approximation would be great.

Is HE-AAC optimized for low bitrates?

Another question, are any of all these formats incompatible with iTunes/iPods? Or do they lose quality when used with iTunes/iPods (possible they might have some non-standard »magic addition»), that is, they play but it does not sound as good as it could?

An equivalent quality can be achieved with a good HE-AAC encoder (Winamp's pluging from Coding Technologies or Helix are the best so far). HE-AAC v2 is good too if you are listening to the music in a noisy environment or at low level. Guruboolez has done several tests with different encoders here. If you need more quality, iTunes AAC-LC encoder is a valid option but at a lot more bitrate than HE-AAC.

It depends on what are you considering low bitrates. The "sweet-point" (you can consider that the point where quality/bitrate is maximum) of HE-AAC is achieved at a lower bitrate than AAC-LC and at a higher bitrate than HE-AAC v2. It all depends on your needs and requirements.

iPod can play only AAC-LC. HE-AAC v1 and v2 are not yet supported but they will be supported very soon. Maybe you can play an HE-AAC encoded file but it will sound VERY bad since it is not decoding the SBR spectrum or the parametric stereo.

Regards,
Oki

He asked about similar quality to lame --preset standard.
I think that current HE-AAC do not reach this quality. In this case AAC-LC should be used instead.

But is HE-AAC really a hifi-format like mp3 at higher bit rates can be? If it's optimized for streaming I guess avoiding stuttering is prioritized to transparency, isn't it?