View Full Version : Nero AAC Codec 1.3.3.0
madshi
9th October 2008, 07:15
Why doesn't ffmpeg output MS channel order?
I think they're working on these things at the moment. Right now every ffmpeg decoder outputs in its own native channel order. But that's probably about to change soon, as far as I've read on the ffmpeg news list...
menno
9th October 2008, 15:22
Ok, good to know. This channel reordering option will not be added to NeroAACEnc. When accepting WAV as input I don't think it's unreasonable to just expect MS channel ordering.
madshi
9th October 2008, 17:06
Actually a WAV file with incorrect channel ordering is plain broken IMHO. Things may be different with raw/PCM data. But with WAV the channel order is clearly specified.
LigH
9th October 2008, 19:39
There is a difference between the usual channel order in AC3 and the one in WAV and AAC. I guess ffmpeg just keeps the order from the AC3 source and passes that into the WAV file. If I remember right, the MUX file wizard in BeLight uses the same order for WAV and AAC, but a different for AC3 (in case someone uses BeSweet to encode AC3). This information might help constructing a "mixer" parameter for SoX to get a reordering in the middle of the pipe...
tebasuna51
10th October 2008, 03:52
Seems sox don't accept the incomplete wav header send by ffmpeg (worse than the old neroaacenc):
ffmpeg -i test.ac3 -acodec pcm_s16le -ac 6 -f wav -ar 48000 - | sox -t wav - -t wav - remix 2 4 3 1 5 6 | neroAacEnc -ignorelength -if - -of audio.mp4
...
\sox wav: Length in output .wav header will be wrong since can't seek to fix it
av_interleaved_write_frame(): Error while opening file
We need a intermediate wav file to do the conversion properly:
ffmpeg -i test.ac3 -acodec pcm_s16le -ac 6 -f wav -ar 48000 z1.wav
sox -t wav z1.wav -t wav - remix 2 4 3 1 5 6 | neroAacEnc -ignorelength -if - -of audio.mp4
BTW, Windows users only need:
eac3to test.ac3 audio.mp4
(neroaacenc at same folder than eac3to, libav decoder used like ffmpeg).
Kurtnoise
10th October 2008, 08:17
for *nix users, there is still the mkfifo trick that should work too...
Selur
10th October 2008, 08:28
@tebasuna51: eac3to depends on some directshow filters, so at least for me it's not an alternative to use ffmpeg+neroaacenc
@Kurtnoue13: care the explain further? (link? details?)
sox wav: Length in output .wav header will be wrong since can't seek to fix it
seems like we are back at the problem, that ffmpeg outputs 'broken' headers :[
madshi
10th October 2008, 08:44
@tebasuna51: eac3to depends on some directshow filters, so at least for me it's not an alternative to use ffmpeg+neroaacenc
eac3to doesn't depend on DirectShow filters. eac3to uses some DirectShow filters if they are available, because some of them provide better quality compared to libav/ffmpeg. But if those DirectShow filters are not available, eac3to can get along just fine, too, by using the libav library distributed with eac3to.
tebasuna51
10th October 2008, 13:15
@tebasuna51: eac3to depends on some directshow filters, so at least for me it's not an alternative to use ffmpeg+neroaacenc
Like madshi say you, don't need directshow filters, the -libav (avcodec.dll, avutil-49.dll) included is the same than use ffmpeg but better:
- Correct channel mapping
- Don't lose precission (32/24 bitdepth instead 16)
- Don't apply Dialog Normalization
- Don't apply Dynamic Range Compression (BTW the -drc_scale parameter in ffmpeg don't work for me in Sherpya-r14277)
seems like we are back at the problem, that ffmpeg outputs 'broken' headers :[
There are two fields in wav header (RiffLength = FileLength - 8, and DataLength) that can't be know when begin the decode of VBR streams, then the problem can be at the soft than accept STDIN but abort if these fields aren't correct.
This last NeroAacEnc version work fine now with the parameter -ignorelength. Is a Sox problem.
LiFe
11th October 2008, 05:16
If you want to convert AC3 to AAC, and you're having trouble with directshow filters, or you have to use an intermediate wav anyway, just use Azid. I convert all my AC3 to wav using Azid set to Maximum (peak volume set to 100%, no DRC or normalisation), then I convert all the wav to AAC using SNG front end. Let me know if you want more details.
Selur
12th October 2008, 14:19
can one pipe into and outoff azid ?
buzzqw
12th October 2008, 14:30
azid don't accept or output to pipe :(
BHH
tebasuna51
12th October 2008, 16:18
To use azid and neroaacenc you can use BeSweet/BeLight.
If you have:
NeroAacEnc.exe at BeSweet folder and
BeSweet v1.5b31 by DSPguru.
Using azid.dll v1.9 (b922) by Midas (midas@egon.gyaloglo.hu).
Using bsn.dll replacement by Dimzon & Kurtnoise, (http://kurtnoise.free.fr/index.php?dir=BeLight/&file=bsn_20070513.zip) Build May 14 2007, 00:00:26
the command line needed is:
BeSweet -core( -input 6a321.ac3 -output 6a321.m4a ) -azid( --maximize ) -bsn( -vbr 0.35 -6chnew )
Selur
12th October 2008, 23:59
@tebasuna: want to use the method under Linux&Windows so besweet isn't really an option,.. :) (or is besweet also available under Linux)
tebasuna51
13th October 2008, 02:40
I only found windows version of azid, there are also linux versions?
Maybe you need wait to ffmpeg mods.
I try one year ago (http://forum.doom9.org/showthread.php?p=1043590#post1043590) but without luck.
hubblec4
13th October 2008, 08:45
Hello
I found a small mistake.
I had encoded an AC3-file with neroaacenc q=0.37
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
Dateigröße : 245 MiB
Duration : 1h 55min
Gesamte Bitrate : 297 Kbps
Kodierungsdatum : UTC 2008-10-12 10:18:53
Tagging-Datum : UTC 2008-10-12 10:31:58
Verwendetes Programm : Nero AAC codec / 1.3.3.0
cdec : ndaudio 1.3.3.0 / -q 0.37
Audio
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : Nein
Codec ID : 40
Duration : 1h 55min
Bitraten-Modus : Variable
Bitrate : 295 Kbps
Maximum bit rate : 354 Kbps
Kanäle : 6 Kanäle
Channel positions : Front: L C R, Rear: L R, LFE
Samplingrate : 48,0 KHz
Auflösung : 16 bits
Stream size : 244 MiB (99%)
Kodierungsdatum : UTC 2008-10-12 10:18:53
Tagging-Datum : UTC 2008-10-12 10:31:58
and the same AC3 wit neroaacenc q=0.35
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
Dateigröße : 248 MiB
Duration : 1h 55min
Gesamte Bitrate : 301 Kbps
Kodierungsdatum : UTC 2008-10-12 10:37:29
Tagging-Datum : UTC 2008-10-12 10:50:29
Verwendetes Programm : Nero AAC codec / 1.3.3.0
cdec : ndaudio 1.3.3.0 / -q 0.35
Audio
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : Nein
Codec ID : 40
Duration : 1h 55min
Bitraten-Modus : Variable
Bitrate : 299 Kbps
Maximum bit rate : 358 Kbps
Kanäle : 6 Kanäle
Channel positions : Front: L C R, Rear: L R, LFE
Samplingrate : 48,0 KHz
Auflösung : 16 bits
Stream size : 247 MiB (99%)
Kodierungsdatum : UTC 2008-10-12 10:37:29
Tagging-Datum : UTC 2008-10-12 10:50:29
Why is the 0.37.mp4 smaller as the 0.35.mp4?
hubbble
LigH
13th October 2008, 14:25
I only found windows version of azid, there are also linux versions?
I am quite sure -- no. Both EXE and DLL were closed-source. Midas seems to be M.I.A.
skromnibog
13th October 2008, 17:58
I found a small mistake.
I had encoded an AC3-file with neroaacenc q=0.37
and the same AC3 wit neroaacenc q=0.35
Why is the 0.37.mp4 smaller as the 0.35.mp4?
This is normal behavior. It happens because different psychoacoustics is used for q0.35 and q0.37. Some jumps like this might occur at some q values for some files. When decoding big set of files, average bitrate should increase, but is not guaranteed.
hubblec4
14th October 2008, 17:52
This is normal behavior. It happens because different psychoacoustics is used for q0.35 and q0.37. Some jumps like this might occur at some q values for some files. When decoding big set of files, average bitrate should increase, but is not guaranteed.
ok. and which mp4-file sounds better? (0.35 or 0.37)
i thought a higher -q makes a bigger file with better sound??
hubble
nautilus7
14th October 2008, 20:15
He didn't say this. He said that because of the way the aac compression works and because the q values your are comparing are so close, this can happen. It's in the range of "statistical error". If you encode a lot of files, thoses with q 0,37 would have bigger size summed together than those with q 0,35.
skromnibog
15th October 2008, 11:36
and which mp4-file sounds better? (0.35 or 0.37)
That depends on a person. At q values where jump occurs and different psychoacoustic parameters are used, it is up to a listener to determine which q value is better for him/her. Listen to some of your favorite music at 0.35 and 0.37 and choose the one that sounds better to you. Of course don't do it just on one sample, because results may vary depending on a sample used.
In general, every user is encouraged to use the q value that suits him/her and if quality is good enough is to be determined only by listening of the person choosing q.
Gusar
15th October 2008, 11:48
Ok, this is weird...$ time a52dec -o wav *T80* 2> /dev/null | neroAacEnc -ignorelength -q 0.25 -if - -of linux.mp4
*************************************************************
* *
* Nero AAC Encoder *
* Copyright 2008 Nero AG *
* All Rights Reserved Worldwide *
* *
* Package build date: Sep 17 2008 *
* Package version: 1.3.3.0 *
* *
* See -help for a complete list of available parameters. *
* *
*************************************************************
Processed 2551 seconds...
real 3m49.771s
user 3m42.114s
sys 0m2.325s$ time a52dec -o wav *T80* 2> /dev/null | wine neroAacEnc.exe -ignorelength -q 0.25 -if - -of win.mp4
*************************************************************
* *
* Nero AAC Encoder *
* Copyright 2008 Nero AG *
* All Rights Reserved Worldwide *
* *
* Package build date: Sep 17 2008 *
* Package version: 1.3.3.0 *
* *
* See -help for a complete list of available parameters. *
* *
*************************************************************
Processed 2551 seconds...
real 2m47.440s
user 2m39.143s
sys 0m2.799s
The above just shows that the Linux version is still slower than the Windows version. But now comes the weird part:$ ls *.mp4
-rw-r--r-- 1 21M okt 15 12:11 linux.mp4
-rw-r--r-- 1 22M okt 15 12:14 win.mp4
The Linux version produces a different encode!
menno
15th October 2008, 23:42
The Linux version produces a different encode!
I'm guessing this is because of the 1000's of floating point comparisons the encoder makes each frame. With a different compiler you will get different results. But I will check this more thoroughly.
madshi
2nd November 2008, 20:29
Would you Nero guys mind adding support for IEEE float style WAV files (wave format extensible GUID "{00000003-0000-0010-8000-00AA00389B71}") in the native bitdepth of your encoder (32bit or 64bit)?
The reason I'm asking is this: In my audio processing tool (eac3to) I often end up with floating point data. Currently I have to downconvert that to 24bit PCM because the Nero AAC Encoder doesn't accept floating point input. But internally AAC encoding is done in floating point, right? So having direct floating point input support would improve both performance and audio quality (slightly).
Thanks! :)
menno
3rd November 2008, 22:33
Would you Nero guys mind adding support for IEEE float style WAV files (wave format extensible GUID "{00000003-0000-0010-8000-00AA00389B71}") in the native bitdepth of your encoder (32bit or 64bit)?
The reason I'm asking is this: In my audio processing tool (eac3to) I often end up with floating point data. Currently I have to downconvert that to 24bit PCM because the Nero AAC Encoder doesn't accept floating point input. But internally AAC encoding is done in floating point, right? So having direct floating point input support would improve both performance and audio quality (slightly).
Thanks! :)
Hmm, I just double checked this and we already support this input format, although only in 32 bit. It works fine on the test samples I have. Maybe you can send me a short sample that doesn't work on our encoder and I can have a closer look at it.
madshi
4th November 2008, 10:14
I'm sorry, that was my fault. I thought I had tested 32bit float, but it seems I did not. It does work fine - thanks! :)
madshi
4th January 2009, 22:52
Happy New Year to you Nero people!
One little request: Would you be willing to add stdout support to both your command line AAC encoder and decoder? That would be nice!
menno
5th January 2009, 16:39
Happy New Year to you Nero people!
One little request: Would you be willing to add stdout support to both your command line AAC encoder and decoder? That would be nice!
Thanks! Same wishes to all our users, and those we still need to convince :)
For the decoder stdout support should be possible, but with the encoder we might run into some problems with the mp4 format, but I'll look into it.
Dark Shikari
5th January 2009, 16:53
For the decoder stdout support should be possible, but with the encoder we might run into some problems with the mp4 format, but I'll look into it.You should be able to do it if you put the header at the end instead of the start. That's the method x264 uses for outputting an mp4 to stdout.
madshi
5th January 2009, 18:09
For the decoder stdout support should be possible, but with the encoder we might run into some problems with the mp4 format, but I'll look into it.
Maybe for the encoder you could output a raw AAC stream, if stdout is activated? Or leave the header "size" field empty (or set to highest possible value)? Or Dark Shikari's suggestion sounds good to me, too.
Thanks in any case for looking into this!
lexor
5th January 2009, 19:07
You should be able to do it if you put the header at the end instead of the start. That's the method x264 uses for outputting an mp4 to stdout.
hmm, I wonder if that's the reason psp chocks on mp4 made by x264, but plays same raw streams muxed with mp4box fine.
Dark Shikari
5th January 2009, 19:12
hmm, I wonder if that's the reason psp chocks on mp4 made by x264, but plays same raw streams muxed with mp4box fine.Yes, you have to remux or use qt-faststart for many devices and for web playback when using either x264's or ffmpeg's muxer. This is by design.
sl1pkn07
5th January 2009, 20:31
thanks for the new version!
fachman
14th January 2009, 01:32
This is normal behavior. It happens because different psychoacoustics is used for q0.35 and q0.37. Some jumps like this might occur at some q values for some files. When decoding big set of files, average bitrate should increase, but is not guaranteed.
Hi
Can you give us the q factor, bitrate numbers where your encoder changes its scheme of work, by adjusting psychoacoustics or other tricks???
For example at which bitrate your encoder with Auto setting changes AAC LC to AAC HE with 5.1 sound??? 160?? 128?
I also noticed some strange things regarding your encoder.
When we set q=0,2 and encode the same file with AAC HE and AAC LC, the LC version is much smaller.
With q=0,21 HE is smaller than LC. Glitch???
I am talking about 5.1 audio, because I have tested it on several files. I am not sure about stereo.
I thought that HE is the right way for smaller bitrates, so with the same quality it should take less bits???
Thanx for the good work
madshi
14th January 2009, 10:34
One more request: Could you please allow 24bit output for the Nero AAC decoder? The Nero DirectShow AAC decoder outputs 24bit, but the command line decoder only 16bit.
Thanks!
burfadel
14th January 2009, 16:13
I thought for very low bitrates HE is better, for high bitrates LC is better? :) ...
menno
15th January 2009, 01:02
fachman, that seems like a glitch indeed, do you get that consistently over multiple files? I will look into it.
madshi, noted.
nautilus7
16th January 2009, 22:20
menno, when encoding with NeroAacEnc, is there any delay value added by default to the audio data? If yes, could you tell me the exact amount?
menno
17th January 2009, 00:12
Yes, depends on profile (LC, HE, HEv2) and samplerate. However, the encoder writes gapless info to the mp4 file (using chapter list) and a capable decoder will compensate for this so the result will be 0 samples delay. For LC the delay is 2048 samples IIRC, for HE/HEv2 a little bit more (2500 or something).
nautilus7
17th January 2009, 00:24
OK, thanks, but could you explain it a little further?
For example in LC profile and 48KHz how much is the delay in ms?
What you say about a capable decoder... Is such decoder the neroaacdec included in the encoder package? And nero 7 dshow decoder is not such? (see this (http://forum.doom9.org/showthread.php?p=1238245#post1238245) post)
menno
17th January 2009, 04:14
Divide the nr of samples by the samplerate (in kHz) and you will have milliseconds.
nautilus7
17th January 2009, 10:05
Thanks again.
microchip8
22nd January 2009, 11:22
Does neroAacEnc implement TNS and/or backward prediction? If not, any plans to add these features?
menno
22nd January 2009, 16:10
Does neroAacEnc implement TNS and/or backward prediction? If not, any plans to add these features?
TNS: yes
prediction: No, and it wouldn't make sense because there are hardly any players (hardware and software) that can decode that. The gain is also said to be minimal.
microchip8
22nd January 2009, 17:08
Thanks for the info, menno :)
So I guess TNS is automatically turned on? Why not a switch to let the user decide if he wants it or not?
EDIT: also is there any benefit in using 2pass mode?
menno
22nd January 2009, 17:52
So I guess TNS is automatically turned on? Why not a switch to let the user decide if he wants it or not?
TNS is not something that is just on or off over the whole file. Usage of TNS and determining it's parameters is done by the encoder based on the audio content. We believe our encoder is good enough at doing this to assume that disabling TNS will almost always deteriorate quality. If TNS doesn't benefit on a particular frame, the encoder will turn it off itself.
EDIT: also is there any benefit in using 2pass mode?
2pass is useful when you want constant quality with an exact predetermined output size.
microchip8
22nd January 2009, 18:43
TNS is not something that is just on or off over the whole file. Usage of TNS and determining it's parameters is done by the encoder based on the audio content. We believe our encoder is good enough at doing this to assume that disabling TNS will almost always deteriorate quality. If TNS doesn't benefit on a particular frame, the encoder will turn it off itself.
2pass is useful when you want constant quality with an exact predetermined output size.
thanks, that clears it up. One final question, though. Which will sound better? ABR 120 kbps 2pass or VBR quality mode with roughly the same bitrate as ABR. Sorry for stupid question, but I'm trying to chose the "best" mode so I can rip my albums here :)
Also, is there an easy way of translating quality values to average bitrates?
menno
23rd January 2009, 05:35
Have a look here: http://www.audiocoding.com/nero_aacenc.html
It's only a general idea, on average it should be fairly correct, but on individual files you will get differences.
microchip8
23rd January 2009, 14:38
Have a look here: http://www.audiocoding.com/nero_aacenc.html
It's only a general idea, on average it should be fairly correct, but on individual files you will get differences.
Thanks for that. Currently, when encoding stuff with neroAacEnc, it only prints processed seconds. Is it possible to add in a future version things like bitrate information similar to how LAME does it?
jeffy
24th January 2009, 14:59
@menno: The links in the first post are not valid anymore. What happened? The search engine of nero.com doesn't find anything related. Thank you.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.