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.

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.

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.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 ?

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...

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.

>>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 ?

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

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>

>>JunonHmmm.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 >>KefPC 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)? ;)