A new version of the Nero Digital Audio+ package has been released on http://www.nerodigital.com/

The package can be downloaded here: http://www.nero.com/nerodigital/eng/down-ndaudio.php

Changes since previous version:

neroAacEnc.exe:
- Quality tuning for some bitrates
- Added support for 16 and 22.05 kHz samplerates for HE AAC
- Fixed HE AAC configuration problems for 5.1 files (at q=0.0)
- Temporary file handling fixed on Windows Vista
- Various speed optimisations

neroAacDec.exe:
- Small speedups
- Reduced memory usage

neroAacTag.exe
- No changes

Thanks for this. BTW, Release Notes on your download page still reflect 1.0.0.2 release. Thanks again.

Nero Digital Audio+ make me surprised.

Sounds interesting, I like encoding using your AAC codec for my mobile phone. Keep up the great work!

Thanks, glad to see there's development! Nero aac is my 2nd codec of choice. 2nd only, because I often need lossless cutting as with mp3directcut which I can't have in aac unfortunately yet...

Which bitrates? Give us some more info, please.

Thx for the update.

Thanks menno.

Unfortunately, the iTunes/iPod gapless playback issue has not yet been resolved. I downloaded the new version of the package and tested it out with a couple of segueing songs--still no gapless playback in iTunes.

Yeah, Menno, I'm sure you're probably tired of hearing about it, but what is the status of the iTunes gapless issues with Nero-encoded AAC files? Is it something you can fix, or is it something that Apple will have to address?

Any reply from you or someone else on the dev team would be greatly appreciated, if only to nip the question in the bud.

- h.

-q 0.3 gives variable bitrate average at approx. 80 kbits
-q 0.3 -lc gives 128

is it ok? if it's then would it be normal to use something like -q 0.2 -lc (should give approx 80 ) to compare it to abr -br 80000 for LC 80 kbit/s ABR vs VBR blind test?

Thank you.

Oh no, not this discussion again.

To address your question, I'm rather certain that this is normal and expected behavior, and you should use a lower quality setting to achieve ~80 kbps with the -lc switch.

Is there how to add tags with EAC or just can be add tags to the file with the comand-line?

I'm encode a lot of music with both versions [1.0.7.0 and 1.0.2.0] and all them are bit identical, just see an very apreciated increase on speed of encoding.I Will Encode from now on with this version, wasting less time to the job. This is an good improvement, I Just Want to See The Function "Tagging" in the encoder, this will be very usefull, nothing of "neroaactag.exe" with that borings comand-line, i sometimes think to stick for ogg but mp4 sound better at the range ~32 to ~112 to me.

Regarding the quality tunings, this should be all HE AAC bitrates between 56 and 72 kbps. These tunings take a lot of time, we hope to give you some more in the next release.

Regarding the iTunes gapless stuff, this is not included, I have no idea if it will be in any next version.

That's good somebody is still working on encoders
Thanks !

Nowdays, with mobile phones and streaming, he-aac became interesting option, I think.

Thanks for the update, menno. Been enjoying the new release so far.

This may be slightly OT but this codec sounds too amazing at 64 kbps for there not to be any flash DAPs on the market that support it (and I don't mean mobile phones)! Does anyone know if these will ever make an appearance and, if so, do you have an approximate timeframe?

The problem is the CPU power required to decode HE-AAC. It's much higher than LC-AAC and MP3.

>>The problem is the CPU power required to decode HE-AAC. It's much higher than LC-AAC and MP3.
Seems that you are wrong.
If I remeber correctly, decoding he stream with the same bitrate is a bit more power consuming, but decoding 128Kbit mp3 or aac requires more power than any he aac stream...
Menno, can you comment this ?

That's incorrect. Increasing bitrates don't impact power consumption as much as the usage of SBR. Have a look here. Of course these are only four processor examples, which aren't representative for every available AAC decoder, but they're a good starting point to see how much processor power is needed as soon as SBR comes into play.

Edit: I forgot to add that these are full-power examples. They don't apply to the SBR low-power profile.

Well, I did some decoding speed test, which should imply how power consuming the decoding process is, and I got the following result. All encoding/decoding tests are done with nero aac encoder v1.0.7.0 and foobar2000 v0.9.4.2

AAC LC Q=0.40 decoding speed ~190x realtime
AAC LC + SBR Q=0.25 decoding speed ~90x realtime
AAC LC + SBR + PS Q=0.15 decoding speed ~80x realtime

To get a more accurate test I should probably have used the same bit-rate and forced the different modes but I'm in a hurry and I'll do it later if necessary. Anyway from this simple test, it looks like SBR really _is_ taking a lot of cpu cycles unless the actual bit-rate has a huge impact on decoding speed.

/Kef

<edit>
I did the same test again but now at the same bitrate (64kbps) and the results are the same
</edit>

>>Junon
Hmmm.
Yep, the page you provided, show that there is no practical difference between mp3 and aac and there is a significant one (almost >2 times) between he aac and lc aac.
This means, that memory and registers reading/writing times became unimportant and I was wrong
>>Kef
PC encoding/decoding times are not representative in this case, because sometimes even the whole song can be loaded in L2 processor cache (this is not, what really happen, of course)...

Ah yes, the power conundrum. Are mobile phone CPUs more powerful, robust and further along than that of DAPs (it would appear the answer is yes)? If so, is that because managing communication is a more processor-intensive task than simply playing back media files (I think I answered my own question)? ;)

Thanls to menno (& Ivan?).
I wish there were an enthusiast who can code a player for HE-AAC on the Nokia N800 Internet Tablet ***sigh***

Any quality improvement for LC-AAC?

And really just about any system, device, phone, PDA, gadget, etc under the sun running Windows Mobile/PPC supports full HE-AACv2 with a free program called "TCPMP."

I installed it personally on 3 of my friends' phones, along with every PALM and PocketPC and Smartphone I ever owned or even came across (with permission ). Decodes wonderfully on even the lowest processors these things have (the decrepit 2001 200mhz ARM processor is no exception).

No, the format is really very, very well supported. It's a darn shame people just don't realize *what* it's actually supported on.

a) Which AAC plugin are you using?

b) Can you report about a specific PDA from your experience which has a good sound quality and good battery life when using LC-AAC?

Thanks...I tested it and sounds better, quite better, and the speed nothing to say very faster.

Are there any plans to tune HE-AAC v2 as well?

a) The Rarewares one.
b) I've used the Asus, the non-VGA dell with 2100mAh battery, some audiovox one, etc.

They pretty much all last a good long time as long as you keep them on powersave mode and assign a button to turn off the lcd touchscreen ("screen toggle" in TCPMP).

They even have dynamic equalizers, support all your playlists, bassboost and 3D audio on some models (Asus, Dell x50), etc.

Hope I could help But I guess all this "PPC device" stuff is besides the point--that this stuff is really widely supported wherever Windows Mobile is (even Palm and phones use this now, and they all run TCPMP).

Yes, thanks a lot.

I'm experiencing a problem with this release. I feed a mono PCM file to it, and the encoder (SSE2 version) outputs a stereo file.
This is my commandline, if it matters:

I tried quality-managed mode and single pass mode, but it keeps outputting a stereo file which doesn't really make sense. Is this a known problem I don't know a workaround for, or a recent bug? Can I do something on my end to fix it? Thanks in advance.

try adding -he to the commandline. it might be automatically using HEv2(which is in a way, stereo)

Yes, tried that as well, didn't work. Have you tried replicating it?

Nevermind, Ivan and Garf have answered that in another thread. The issue had something to do with the mono file being decoded to two channels since decoders don't know if it was encoded with parametric stereo (which I personally find rather strange). Oh well.

Problems for developers:

http://www.vuplayer.com/forums/viewtopic.php?t=384