Nero AAC Codec Version 1.5.1.0 released

[menno]

We just released a new version of our command line AAC encoder, decoder and MPEG-4 tagger applications on our website.
The download can be found here: http://www.nero.com/enu/downloads-nerodigital-nero-aac-codec.php

Release notes for version 1.5.1.0:

neroAacEnc:
- Improved encoding of sample rates higher than 48kHz
- Solved compatibility issues with some hardware devices
- Write iTunes compatible gapless data
- Enabled preserving of very quiet high frequencies at high bitrates
- Write the encoder settings to metadata
- Executable size reduction

neroAacDec:
- Improved error handling
- Speed up

neroAacTag:
- Support 3GPP tags
- Support Sony Memory Stick tags
- Improved cover art support
- Improved support for files with multiple tags in different formats (ND,iTunes,3GPP,Sony Memory Stick)
- Writes iTunes tags by default, added switch to enable ND tags

[Dark Shikari]

Nice!

I know a lot of companies that I work with that are interested in commercial licensing of the NeroAAC executable (since FAAC is so bad), but the last one I know that contacted you (a multi-billion dollar company) took a month to get a response and was told that Nero doesn't license the encoder anymore... is this true? It seems really unfortunate, as it's a very good encoder and, unlike Apple's, available on Linux.

[menno]

Nice!

I know a lot of companies that I work with that are interested in commercial licensing of the NeroAAC executable (since FAAC is so bad), but the last one I know that contacted you (a multi-billion dollar company) took a month to get a response and was told that Nero doesn't license the encoder anymore... is this true? It seems really unfortunate, as it's a very good encoder and, unlike Apple's, available on Linux.

We definitely still license our codec. It's not our main business, though. At the moment we are mostly interested in big deals, since smaller deals have relative high overhead. But this idea seems to be changing and it might be possible soon to also do smaller deals.
If you know anyone who is interested, feel free to contact me and I will forward those people to the right person.

[Dark Shikari]

We definitely still license our codec. It's not our main business, though. At the moment we are mostly interested in big deals, since smaller deals have relative high overhead. But this idea seems to be changing and it might be possible soon to also do smaller deals.
If you know anyone who is interested, feel free to contact me and I will forward those people to the right person.The main problem is probably that everyone who wants to license it is looking for licenses for 10, 100, 500 servers for running an x264 + AAC transcode farm. To make good money off that you'd probably have to come up with a licensing model that makes more sense (since normally one would probably do a few dollars per unit I would assume).

Give me an email address and I'll toss it to everyone who asks about Nero in the future (and to whoever is on my list who asked in the past).

[tebasuna51]

Thanks for the new version.

Also thank to add stdout to neroAacDec, like was suggested in this forum:

* Nero AAC Decoder ...
* Package build date: Dec 17 2009
* Package version: 1.5.1.0

Usage: neroAacdec.exe -if <input file> -of <output file> [-chapter <number>]
Specify - to decode to stdout

[LoRd_MuldeR]

Is there any chance that the Nero AAC encoder will flush STDOUT after printing progress information? :)

This would allow GUI's to update the progress in real-time...

[Keiyakusha]

- Enabled preserving of very quiet high frequencies at high bitrates
Wow, thanks for that. Cutting high frequencies even with q1 was the only thing I disliked in this encoder.
But maybe it's possible to make some control for this? Like in FAAC.

[madshi]

Thanks for adding stdout to the decoder! Now the decoder supports stdout, but not stdin. And the encoder supports stdin, but not stdout.

Things still on my wish list (most important first):

(1) Add stdin support for decoder.
(2) Add stdout support for encoder.
(3) (Optionally?) decode to higher bitdepth than 16bit.

FWIW, the Nero DirectShow Audio decoder decodes AAC to 24bit. Why does the command line decoder only output 16bit?

[roozhou]

(2) Add stdout support for encoder.


MP4 to stdout? Are you joking?

[madshi]

Why? Does MP4 not support streaming? If MP4 can't be written serially, I'd suggest writing raw AAC data to stdout. That would be fine with me, too.

The reason for asking for stdout support is that automation tools might have a need to post process the encoded data. E.g. you may want to mux the newly encoded audio track into a container together with a video track. If there's no stdout support in the encoder, you have to first encode to a file, then read from the file, then do the final muxing. Makes everything more complicated and slower...

[roozhou]

Why? Does MP4 not support streaming? If MP4 can't be written serially, I'd suggest writing raw AAC data to stdout. That would be fine with me, too.

The reason for asking for stdout support is that automation tools might have a need to post process the encoded data. E.g. you may want to mux the newly encoded audio track into a container together with a video track. If there's no stdout support in the encoder, you have to first encode to a file, then read from the file, then do the final muxing. Makes everything more complicated and slower...

Is there any tool capable of reading adts from stdin and mux it to another container? And compared to an encoded aac stream, an encoded H264 stream is much much bigger. But people are still using x264.exe to write video only intermediate file and mux it with audio later.

[zn]

what format it is better to feed to neroaacenc? pcm wav: 32 bit float, 32 bit int, 24 bit int or 16 bit int - what it is using "internally"?

[madshi]

Is there any tool capable of reading adts from stdin and mux it to another container?
In case you don't know, I'm the author of the tool "eac3to". Obviously, whatever I'm asking for here, is to improve eac3to's AAC support. Ok, I have to admit that I don't know if eac3to will ever support muxing of audio tracks into a container, currently it doesn't. But maybe one day it will. And that will not be possible with AAC if the Nero AAC encoder does not support stdout.

[Rudde]

I get this (http://upload.rudde.us/uploads/1262328461.log) error after one encode and a restart. I have tryed to reinstall megui and take in nero audio again but still don't work.

[hajj_3]

a 64bit version would be nice.

[audyovydeo]

I've just noticed this :


*******************************************
* *
* Nero AAC Encoder *
* Copyright 2009 Nero AG *
* All Rights Reserved Worldwide *
* *
* Package build date: Dec 29 2009 *
* Package version: 1.5.3.0 *
* *
* See -help for a complete list of available parameters. *
* *
*******************************************

while decoder and tagger keep the 1.5.1.0 version.

Nothing in the changelogs. What's the diff ??

cheers
a/v

[nurbs]

Fixes a crash on some old CPUs. Check Hydrogenaudio for details.

[kypec]

Also I noticed this tiny improvement mentioned in changelog.txt
- Speed up for LC profile (~7%)

[kypec]

Has anybody else experienced inconsistent bitrate results when using -q parameter values around 0.31?
Please see my post here (http://forum.doom9.org/showpost.php?p=1385864&postcount=7) about further details.

Note: just downloaded latest version of NeroAAC package and was quite excited about changelog:2010-02-18 - Version 1.5.4.0

- neroAacEnc:
- Fixed very rare error

Unfortunately, after tests I must conclude that very rare error mentioned here doesn't solve my issues with q=0.31 weird bitrate. :(

[tebasuna51]

This is the boundary between HE (q=0.31) and LC (q=0.32) automatic encode, and is know there are changes in bitrate.
For Nero developers is OK, assume the difference.

[D3C0D3R]

We just released a new version of our command line AAC encoder, decoder and MPEG-4 tagger applications on our website.

Thanx, for one of the best AAC encoder, and very simple for begginers.

This is the boundary between HE (q=0.31) and LC (q=0.32) automatic encode, and is know there are changes in bitrate.
For Nero developers is OK, assume the difference.

try neroaacenc -he -q 0.35

what difference between he and lc in practice?
but, imho he better lc at same bitrates.

[nurbs]

what difference between he and lc in practice?
but, imho he better lc at same bitrates.

Not necessarily. HE-AAC uses SBR to reproduce the high frequencies instead of encoding them like LC-AAC usually does. Some people can hear that SBR is used, even at high bitrates. At the same time the benefit of using it is becoming smaller to nonexistent at higher bitrates where you can just as well encode the whole file as LC. I think there were double blind tests (at Hydrogenaudio maybe?) that show the points I mentioned.
Therefor the Nero encoder and I guess others as well default to LC/HE depending on the bitrate/quality settings that are used. IIRC Nero uses LC for q > 0.3 or bitrate > 80 kbps (for stereo).

Then there is also the fact that LC-AAC has better compatibility and lower CPU requirements to decode. Any AAC decoder can decode the LC part of the file, but when you decode a HE file on a LC decoder the high frequencies don't get replicated which results in worse sound quality.

This is the boundary between HE (q=0.31) and LC (q=0.32) automatic encode, and is know there are changes in bitrate.
The boundary between HE and LC in the Nero encoder is q=0.30 and q=0.31. The mediainfo logs in the linked post confirm that.

[tebasuna51]

You are right, maybe is a change in recent versions.

[kypec]

The boundary between HE and LC in the Nero encoder is q=0.30 and q=0.31. The mediainfo logs in the linked post confirm that.
I understand there must be one distinct value of Q where encoder decides between modes to use - HE vs LC. Let us assume it is 0.30: if Q<=0.30 use HE mode, otherwise (Q>0.30) use LC mode. So far so good.
What I don't understand is why the encoder performs worse for 0.31 (higher bitrate was used) than for 0.32 yet the mode internally chosen is the same i.e. LC? Obviously higher Q means higher quality with less data being discarded due to weaker psy optimizations and so on.
Or is there really only one acceptable solution for those who don't want to use -he / -lc switches explicitly

use q<=0.30 if you want to be sure HE will be used
use q>=0.32 if you want to be sure LC with guaranteed monotonicity will be used
do not use 0.30<q<0.32 because you'll get inefficient LC with higher bitrate

[nurbs]

You are right, maybe is a change in recent versions.
It has always been like that IIRC.

do not use 0.30<q<0.32 because you'll get inneficient LC with higher bitrate
I can't agree with the inefficient. While it's true that 0.31 leads to higher bitrates than 0.32 it hasn't been shown yet that the file 0.31 produces is worse quality than a file encoded with the same bitrate (or higher q leading to a similar bitrate) would be.
Of course it is possible, but I don't think you can conclude that without further tests.

[menno]

The q values are mapped so that over a big set of files there will always be an increase in bitrate with increasing q value. Due to the fact that HE and LC are different codecs, it is possible that on single files there might be a higher bitrate when using HE over LC, it may even be so much higher that increasing the LC -q parameter by 0.01 will not overcome the difference (which is basically what you're doing when comparing 0.30 to 0.31).

[nurbs]

Yes, but we are comparing 0.31 with 0.32 where the former usually leads to a much higher bitrate while both produce LC-AAC.

[menno]

That's also not impossible for specific files, different parameters are used internally for different -q values and these don't always have the same effect. On a bigger set of files there should be an increase in bitrate, we can't guarantee this for every single file.

[kypec]

Thank you very much for your exhaustive comments, menno. I think I'm starting to have a clue how -q works internally. Well, it seems I just happen to have an audio file which doesn't fall right in the average statistical set.:p

[D3C0D3R]

nurbs
thanx for explaining.

HE-AAC uses SBR to reproduce the high frequencies instead of encoding them like LC-AAC usually does.
looks like Psy-RDO/Psy-trellis in x264. same scheme - detects high freq in picture & replace it by pseudorandom noise or packed by simpler rules.
but in x264 i didnt like it beacause it significantly raise quants/bitrate, but in nero it like not costs any bitrate.
i've recently buy much better acoustic & want recompare he / lc. so i have 2 more questions

for what range of frequencies applies SBR?
depends this range from Q?

[SeeMoreDigital]

for what range of frequencies applies SBR?
depends this range from Q?You may find the following PDF a useful read: -

http://www.telos-systems.com/techtalk/aacplus/aacPlus_overview.pdf

[shon3i]

for what range of frequencies applies SBR?
depends this range from Q? Over 11khz for SBR and over 14khz for DSBR

looks like Psy-RDO/Psy-trellis in x264. same scheme - detects high freq in picture & replace it by pseudorandom noise or packed by simpler rulesWith little difference that SBR need "special" decoder, and some hw decoders are realy terible.

[menno]

Over 11khz for SBR and over 14khz for DSBR

Not true at all. It depends on selected bitrate or quality in the Nero encoder.

[menno]

nurbs
looks like Psy-RDO/Psy-trellis in x264. same scheme - detects high freq in picture & replace it by pseudorandom noise or packed by simpler rules.


Not important for your questions, but I don't think they can be compared. From the little I read about it, it looks more like Psy-RDO/Psy-trellis is like adding a psychoacoustic model to an audio encoder that didn't have one before. Both require no change of decoder, which SBR does.

[Keiyakusha]

to my understanding SBR for audio is something like when you take 60fps video, record some info about state of the frames (which will be SBR) then drop every second frame and encode the result. After that decoder will reconstruct every second frame but it will also use previously collected info - SBR.

So its not like that, no?

[shon3i]

Not true at all. It depends on selected bitrate or quality in the Nero encoder.
But why decoder (FAAD) always decode LC part up to 11khz.

[menno]

But why decoder (FAAD) always decode LC part up to 11khz.

For 44.1kHz the LC AAC samplerate will be 22.05kHz, so the maximum frequency in the LC AAC part will be 11kHz (Nyquist). That doesn't say anything about the range over which SBR is functioning, that could still be 8kHz to 16kHz (for example).

[shon3i]

For 44.1kHz the LC AAC samplerate will be 22.05kHz, so the maximum frequency in the LC AAC part will be 11kHz (Nyquist). That doesn't say anything about the range over which SBR is functioning, that could still be 8kHz to 16kHz (for example).
Aha i understand now, but I thought that LC part stay untoched, what is the advantage of DSBR then?

[LoRd_MuldeR]

Aha i understand now, but I thought that LC part stay untoched, what is the advantage of DSBR then?

As far as I know, SBR reduces the samplerate to the half before encoding, which will also reduce the maximum frequency that can be stored to the half, i.e. SBR will kill the highest frequencies.

The only purpose of SBR is to make the audio easier to compress, which is helpful at ultra-low bitrates. It works with AAC (called HE-ACC), MP3 (called mp3PRO) and probably others.

At playback-time a SBR-enabled decoder will "re-construct" the missing high frequencies after decoding. This will double the samplerate and thus restore the original samplerate, as before it was halved.

A decoder that is not SBR-enabled will still decode the file (of course), but play the audio as-is (at the halved samplerate). Consequently all the high frequencies will be missing in that case.

(It should be clear that the re-constructed high frequencies will never be identical to the original. So while being helpful at ultra-low bitrates, SBR shouldn't be used at higher bitrates)

to my understanding SBR for audio is something like when you take 60fps video, record some info about state of the frames (which will be SBR) then drop every second frame and encode the result. After that decoder will reconstruct every second frame but it will also use previously collected info - SBR.

I'd assume a SBR-like technology for video would low-pass (smooth, denoise) the video before encoding to make it more compressible and later re-add "fake" noise (grain, detail) after decoding.

[skromnibog]

The SBR part of a codec gathers information about high frequencies, stores guidance information about them and uses them on decoding to reconstruct high frequencies from low frequencies, since there is almost always some correlation between low and high frequencies.
Because of this an encoder where SBR is added, can only compress low frequencies and rely on SBR for high frequencies.
At low bitrates too much bits would be spent on high frequencies using only LC and humans are more sensitive to low frequencies. When bitrate is increased low frequency part has enough bits and there is enough left for high frequencies. When there is enough bits left for high frequencies, it is better to use LC for them as SBR is not accurate enough and doesn't have a possibility to use those extra available bits.

[D3C0D3R]

I'd assume a SBR-like technology for video would low-pass (smooth, denoise) the video before encoding to make it more compressible and later re-add "fake" noise (grain, detail) after decoding.

It's more likes PNS technique.

I think Keiyakusha example is closer because SBR inputs time domain data and improve resolution.

[D3C0D3R]

I've done some tests HE in 1.51 and compare it with 1.33.
Sample: 2ch, 44.1 khz.
So at ~28 kbps HE chockes with short bitrate, and at 20-22 he chockes finally. But hev2 keeps some quality to 15 kbps after than it chokes to.It corresponds q=0.07-0.10
At 30-50 kbps he better than lc corresponds q=0.1-0.2
at 50-60 lc has audibly better hi-freq, but at all lc is worse. at 70 lc is better. It corresponds q=0.2-0.25

All this long-known results and no special interest.

BUT further increase bitrate give me interesting results.

at 90 kbps lc still beats he.
but at 110 kbps he surprisingly has good quality comparable with lc (IMHO). i cant explain that maybe DBSR turns on, but at this bitrate hi-freq in he is good. :confused:

Next
I used that bitrate he has almost linear dependence from q (v. 1.33). on this formula bitrate=~q*250
or on every q+=0.1 we have approx 25 kbps until we reach the saturation point.

but in 1.51 when changeover from q=0.35 to q=0.50
i discover serious bitrate jump. :confused:

and 1.33 at q=0.4 has better hi-freq than 1.51 at q=0.35 at same bitrates.

1.51 1.33 bitrate
====================
0.30 0.32 86
0.35 0.40 105
0.40 0.50 127
0.50 0.75 180
1 1 200

200 kbps is saturate point for my sample.

I've think that is much more changes in nero than in changelog. Long story short that is more questions than answers.

[LoRd_MuldeR]

I think Keiyakusha example is closer because SBR inputs time domain data and improve resolution.

SBR works in frequency domain: It halves the number of samples per second in the time domain. But the actual result is in frequency domain: By halving the samples per second, you also half the maximum frequency that can be retained, i.e. all the higher frequencies are killed. For example when we have a typical 44100 samples/second track, then them maximum frequency that can be retained is 22.05 Hz. As SBR would down sample this to 22050 samples/second, now the maximum frequency that can be retain is 11.025 Hz. This is Nyquist's Theorem.

So after all, SBR is restricting (low-passing) the frequencies. Doing this with Video would mean low-passing the spatial frequencies, i.e. DCT'ing the video and zeroing out all the higher AC coefficients.

[D3C0D3R]

Doing this with Video would mean low-passing the spatial frequencies

yep, but very little type of video-denoisers works directly in freq-domain (fft3dfilter)

Sbr restore hi-freq using mid-freq i.e. works in freq-domain
In video we add grain completly different way (no FFT,DCT using). So i suppose that technique is more like Perceptual Noise Substitution. It replaces coding of noise-like parts of a signal by generating noise on the decoder side.

At all reducing fps is some kind of lowpassing too :)
MoComp not works in freq-domian too, but this is not random method unlike adding the noise.

[b66pak]

@menno do you plan to add support for aac (mpeg4 adts) output to stdout?
_

[LoRd_MuldeR]

Is there any chance that the Nero AAC encoder will flush STDOUT [STDERR] after printing progress information? :)

This would allow GUI's to update the progress in real-time...

It's been a log time (about one year) and I never got an answer on this.

So just in case any of the Nero developers is still around, may I ask if this is ever going to be fixed in a future release?

[lych_necross]

It's been a log time (about one year) and I never got an answer on this.

So just in case any of the Nero developers is still around, may I ask if this is ever going to be fixed in a future release?
You should ask that over at http://www.hydrogenaudio.org/forums/

Several Nero AAC devs hang out there.

EDIT: I asked this question over there. So far, no response (will update here if anyone does).

[menno]

It's been a log time (about one year) and I never got an answer on this.

So just in case any of the Nero developers is still around, may I ask if this is ever going to be fixed in a future release?

Yes this should be easy to add for the next version.

[LoRd_MuldeR]

Yes this should be easy to add for the next version.

Cool :cool:

I know that developers hate the question, but is there any schedule for another release yet?

(BTW: Would it be possible to print out also the percentage done in addition to the number of seconds already processed?)