View Full Version : Nero Releases FREE Reference Quality MPEG-4 Audio Command Line Encoder
Pages :
1
2
3
4
5
6
7
[
8]
9
Romario
26th July 2007, 23:46
menno, what about proimised LC-AAC improvments, Ivan talked something about it?
menno
27th July 2007, 06:18
menno, what about proimised LC-AAC improvments, Ivan talked something about it?
They are in there too :)
Gusar
27th July 2007, 09:50
Is the linux build not optimized by any chance? Because there's a huge difference in speed:$ time a52dec -o wav6 "VTS_01_1 T01 3_2ch 384Kbps DELAY -248ms.ac3" 2> /dev/null | ./neroAacEnc -ignorelength -q 0.17 -if - -of linux.mp4
*************************************************************
* *
* Nero Digital Audio Reference MPEG-4 & 3GPP Audio Encoder *
* Copyright 2007 Nero AG *
* All Rights Reserved Worldwide *
* *
* Package build date: Jul 20 2007 *
* *
* *
* See -help for a complete list of available parameters. *
* *
*************************************************************
Processed 304 seconds...
real 1m28.181s
user 1m25.989s
sys 0m0.767s
$ time a52dec -o wav6 "VTS_01_1 T01 3_2ch 384Kbps DELAY -248ms.ac3" 2> /dev/null | wine neroAacEnc.exe -ignorelength -q 0.17 -if - -of win.mp4
*************************************************************
* *
* Nero Digital Audio Reference MPEG-4 & 3GPP Audio Encoder *
* Copyright 2007 Nero AG *
* All Rights Reserved Worldwide *
* *
* Package build date: Jul 20 2007 *
* Package version: 1.1.34.0 *
* *
* See -help for a complete list of available parameters. *
* *
*************************************************************
Processed 304 seconds...
real 0m52.108s
user 0m50.207s
sys 0m0.752
A 30 seconds difference on a 5 minute clip. Now, imagine if I would encode the entire movie, not just one chapter.
menno
27th July 2007, 09:56
Yeah, we didn't have time yet to do all optimizations for the linux version too. I guess if you have/use wine then using that will be better at the moment.
First thing was to actually get it working on linux, next step will be to incorporate all the optimizations.
Gusar
27th July 2007, 16:52
Yeah, we didn't have time yet to do all optimizations for the linux version too. I guess if you have/use wine then using that will be better at the moment.
First thing was to actually get it working on linux, next step will be to incorporate all the optimizations.Makes sense. Maybe this could be mentioned in the changelog. That said, the fact that you provide linux builds at all deserves respect. Thank you for providing linux users a high quality aac encoder.
Bigmango
28th July 2007, 02:17
Holly Molly !
Nero, thanks so much for Linux support :thanks:
menno
30th July 2007, 07:05
I tried adding -f wav like this:
C:\ffmpeg>ffmpeg -i INPUT.wma -acodec pcm_s16le -f wav - | neroaacenc_sse2 -q 0.
28 -ignorelength -if - -of output.mp4
FFmpeg version CVS, Copyright (c) 2000-2004 Fabrice Bellard
configuration: --enable-theora --enable-mp3lame --enable-libogg --enable-vorb
is --enable-faad --enable-faac --enable-xvid --enable-x264 --enable-mingw32 --en
able-a52 --enable-dts --enable-pp --enable-gpl --enable-memalign-hack --enable-a
mr_nb --enable-amr_wb
libavutil version: 49.0.0
libavcodec version: 51.1.0
libavformat version: 50.0.0
built on Jan 29 2006 03:34:22, gcc: 4.0.2
Input #0, asf, from 'INPUT.wma':
*************************************************************
* *
* Nero Digital Audio Reference MPEG-4 & 3GPP Audio Encoder *
* Copyright (C) 2006 Nero AG *
Duration: 00:41:10.4, start: 0.608000, bitrate: 20 kb/s
Stream #0.0: Audio: wmav2, 22050 Hz, mono, 20 kb/s
Output #0, wav, to 'pipe:':
Stream #0.0: Audio: pcm_s16le, 22050 Hz, mono, 352 kb/s
Stream mapping:
Stream #0.0 -> #0.0
* All Rights Reserved Worldwide *
* *
* Package build date: May 1 2006 *
* *
* See -help for a complete list of available parameters. *
* *
*************************************************************
ERROR: could not parse WAV file
size= 106376kB time=2470.0 bitrate= 352.8kbits/s
video:0kB audio:106376kB global headers:0kB muxing overhead 0.000040%
Problem with piping? 'cause I tried:
> ffmpeg -i input.wma -f wav temp
> neroaacenc_sse2 -q 0.28 -ignorelength -if temp -of output.mp4
and it works... Nero's problem or XP's piping problem?
update: tested with 1.0.0.2, same result.
Thank you.
Although it's old, bond asked me to look at this.
ffmpeg writes a length of 0 to the wave header when outputting to stdout. Even when the -ignorelength option is used this value 0 is not ignored in the aac encoder. The encoder assumes this length or less samples in the file.
Most software writes the maximum possible length to the wave header before it knows the actual output size. I consider it something that should be fixed in ffmpeg as pretty much every software I tried can not read this wave file.
tebasuna51
30th July 2007, 13:26
Although it's old, bond asked me to look at this.
ffmpeg writes a length of 0 to the wave header when outputting to stdout. Even when the -ignorelength option is used this value 0 is not ignored in the aac encoder. The encoder assumes this length or less samples in the file.
Most software writes the maximum possible length to the wave header before it knows the actual output size. I consider it something that should be fixed in ffmpeg as pretty much every software I tried can not read this wave file.
You are right about ffmpeg must fix this issue because also:
ffmpeg -i INPUT.wma -acodec pcm_s16le -f wav - > output.wav
make a unusable output wav and, of course, is not a NeroAacEnc problem.
But NeroAacEnc -ignorelength, can accept wav files with DataLength = 0, really the NeroAacEnc test to accept the wav (with -ignorelength) is:
RIFFLength = DataLength + DataChunkOffset
Then a standard PCM wav file (DataChunkOffset = 36) can be accepted with:
RIFFLength = 36
DataLength = 0
I think this test is really strange because if these fields are invalid (overflow for size > 4 bytes) you can't expect any relation between them.
For instance faad fill these two fields (when overflow) with 0xFFFFFF00 then are not accepted with NeroAacEnc. Also old NeroAacDec version output are not accepted.
Maybe the test is to ensure the 'data' chunk is the last ( if RIFFLength = DataLength + DataChunkOffset not exist other chunks after 'data' and all the bytes until eof must be audio samples) but I don't know any app. than write extrachunks at end of illegal wav files (> 4 GB).
If you want maintain the test maybe you can include a new parameter -ignore2length to really ignore the two invalid fields.
Thanks.
bond
30th July 2007, 20:20
:thanks: menno
menno
31st July 2007, 07:07
You are right about ffmpeg must fix this issue because also:
ffmpeg -i INPUT.wma -acodec pcm_s16le -f wav - > output.wav
make a unusable output wav and, of course, is not a NeroAacEnc problem.
But NeroAacEnc -ignorelength, can accept wav files with DataLength = 0, really the NeroAacEnc test to accept the wav (with -ignorelength) is:
RIFFLength = DataLength + DataChunkOffset
Then a standard PCM wav file (DataChunkOffset = 36) can be accepted with:
RIFFLength = 36
DataLength = 0
I think this test is really strange because if these fields are invalid (overflow for size > 4 bytes) you can't expect any relation between them.
For instance faad fill these two fields (when overflow) with 0xFFFFFF00 then are not accepted with NeroAacEnc. Also old NeroAacDec version output are not accepted.
Maybe the test is to ensure the 'data' chunk is the last ( if RIFFLength = DataLength + DataChunkOffset not exist other chunks after 'data' and all the bytes until eof must be audio samples) but I don't know any app. than write extrachunks at end of illegal wav files (> 4 GB).
If you want maintain the test maybe you can include a new parameter -ignore2length to really ignore the two invalid fields.
Thanks.
I'm not sure I understand exactly what you mean. Right now our wave library checks for a size of 4 (minimum) while 36 should be the minimum for even having a readable header.
Some sanity check has to remain, I think.
tebasuna51
31st July 2007, 09:48
I'm not sure I understand exactly what you mean. Right now our wave library checks for a size of 4 (minimum) while 36 should be the minimum for even having a readable header.
Some sanity check has to remain, I think.
Really I was wrong in one thing, The test is not:
RIFFLength = DataLength + DataChunkOffset
but
RIFFLength => DataLength + DataChunkOffset
Examples with standard PCM WAV files (DataChunkOffset=36):
RIFFLength=35, DataLength=0 ->Reject
RIFFLength=36, DataLength=0 ->Accepted
RIFFLength=37, DataLength=0 ->Accepted
RIFFLength=135, DataLength=100 ->Reject
RIFFLength=136, DataLength=100 ->Accepted
...
Examples with WAVE_FORMAT_EXTENSIBLE files (DataChunkOffset=60):
RIFFLength=59, DataLength=0 ->Reject
RIFFLength=60, DataLength=0 ->Accepted
RIFFLength=61, DataLength=0 ->Accepted
RIFFLength=159, DataLength=100 ->Reject
RIFFLength=160, DataLength=100 ->Accepted
...
Then the test is not to ensure the 'data' chunk is the last and become more strange for me. Ensure there are a readable header checking a field that can be with overflow (> 4 GB) or unknow when using 'pipe'?.
This field can be wrong, to ensure if there are a readable header try to read enough bytes from the stream, check if necessary parameters (Channels, Samplerate, BitsPerSample,...) are coherent and then continue reading and encoding until end of file.
This is, for me of course, the meaning of IgnoreLength parameter.
BTW, thanks for your free encoder, I dont want criticize but improve.
MetalPhreak
15th August 2007, 17:42
Just thought I'd let everyone know the new version has been "officially" released. I'm busy playing with it now.
menno
15th August 2007, 17:50
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
- Linux version
- New q value mappings
- Retuning of almost all bitrates
- Fix in HEv2 encoder/decoder delay
- Fixed incorrect streamlength written in MP4 files
- Significant speedup
- Removed -hinttrack option
* neroAacDec
- Linux version
- Fixed a memory leak
* neroAacTag
- Added -hinttrack option
menno
15th August 2007, 17:51
BTW, we found a bug when using -2pass option on 5.1 files, better not use that!
Old versions also had this bug, will be fixed in next version.
deets
15th August 2007, 18:18
any change of a multi threaded version :D
but thanks anyway, is great!
MrCommunistGen
16th August 2007, 00:08
Using MeGUI the SSE version isn't working for me anymore on my Athlon X2 3800+ its a S939 Manchester but the specific core shouldn't matter since all the X2s support SSE, SSE2, and SSE3. 1.0.7 and earlier worked just fine. The non-SSE version of 1.1.34.2 still works but I think its slower.
The MeGUI log file tells me:
"System.ApplicationException: Abnormal encoder termination 1
at MeGUI.AviSynthAudioEncoder.encode()
Fatal Error : This program was not built to run on the processor in your system."
-mcg
Pookie
16th August 2007, 05:05
You Nero guys are very cool for making this available to everyone. Thanks!
menno
16th August 2007, 06:27
It seems using the Intel compiler was not such a great idea, sorry to AMD users who want to use this.
But I think the current non-SSE build is not slower than the old SSE build, at least not much.
menno
16th August 2007, 06:35
any change of a multi threaded version :D
If you're encoding multiple files you could use foobar2000 (maybe some other GUI's support this too) to run multiple encoding threads at once.
plane
16th August 2007, 11:43
BTW, we found a bug when using -2pass option on 5.1 files, better not use that!
Old versions also had this bug, will be fixed in next version.
what kind of that bug?
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=55827&view=findpost&p=501353
and is this another one bug?
menno
16th August 2007, 11:48
what kind of that bug?
Well, some tables get screwed up and the result is absolutely terrible sounding. Note: only for 5.1 and only with -2pass it is really bad.
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=55827&view=findpost&p=501353
and is this another one bug?
I don't see any bug report in that post? You mean the fact that -br generates the same bitrate with and without -2pass? That is normal, it works to the same average bitrate, the distribution of the bits over the frames will just be different.
plane
16th August 2007, 12:17
I don't see any bug report in that post? You mean the fact that -br generates the same bitrate with and without -2pass? That is normal, it works to the same average bitrate, the distribution of the bits over the frames will just be different.
thanks for clear :)
deets
16th August 2007, 15:37
If you're encoding multiple files you could use foobar2000 (maybe some other GUI's support this too) to run multiple encoding threads at once.
yeah megui can now, but i have 4 cores and i wanna use them :D
go on, ill be your friend ;)
MrCommunistGen
16th August 2007, 17:17
@menno
I'm glad that the problem has a simple explanation. About the speed, its probably just my perception, especially since I just updated MeGui and it has a new way of showing encode speed. And of course my misguided hope that something using SSE/SSE2 etc will be faster... Anyhow thanks for joining up to answer questions and hear comments. Its always nice being able to communicate with the people "on the inside"
@deets
Is there a way to run more than one thread on audio? I know that some of the video codecs support multiple cores, but I didn't think that it worked for audio codecs because that would require support from the codec itself. I *think* there is an alpha version of LAME available that supports multithreading.
-mcg
deets
16th August 2007, 17:45
yeah i think i had only heard about the lame one as well. Its not usually a big deal for small clips, but if your converting a 2h20min DVD to aac then it could be handy, plus i have the cores doing nothing :P
but i knew that anyway, just wondered if it was even in the future as intel is pushing multi core support in software these days :)
burfadel
16th August 2007, 19:26
The Lame MT version doesn't process different sections of audio on each core, it simply does some of the acoustic modelling etc. on one thread and the actual encoding is still done on one thread only.
menno
17th August 2007, 06:29
@menno
I'm glad that the problem has a simple explanation. About the speed, its probably just my perception, especially since I just updated MeGui and it has a new way of showing encode speed. And of course my misguided hope that something using SSE/SSE2 etc will be faster... Anyhow thanks for joining up to answer questions and hear comments. Its always nice being able to communicate with the people "on the inside"
-mcg
If it's any comfort, the non-SSE build also uses a lot of SSE code :D
The difference is that for the SSE build version the compiler generates additional SSE code.
Sharktooth
17th August 2007, 16:20
blah... intel compiler crap...
bond
18th August 2007, 10:05
Although it's old, bond asked me to look at this.
ffmpeg writes a length of 0 to the wave header when outputting to stdout. Even when the -ignorelength option is used this value 0 is not ignored in the aac encoder. The encoder assumes this length or less samples in the file.
Most software writes the maximum possible length to the wave header before it knows the actual output size. I consider it something that should be fixed in ffmpeg as pretty much every software I tried can not read this wave file.they dont want to fix it in ffmpeg :(
burfadel
18th August 2007, 13:08
blah... intel compiler crap...
Yeah I wonder how the court case worked out? apparently the Intel compiler was designed so things compiled with it would work poorly on AMD systems. I guess if AMD won, the very latest compiler would be fine with both systems, I guess Intel won!
Sharktooth
18th August 2007, 16:11
still heard no words about that
mizaru
30th August 2007, 16:52
The SSE version of the encoder can easily be patched to run on AMD systems. However, I did not notice any speedup compared to the non-SSE version (tested on an X2 4200).
menno
31st August 2007, 08:08
The SSE version of the encoder can easily be patched to run on AMD systems. However, I did not notice any speedup compared to the non-SSE version (tested on an X2 4200).
Yes, the so-called SSE version is more there because it always was there. In the non-SSE version pretty much all places where SSE is possible, SSE is used, just only when your CPU supports it. In the next version we are considering removing the SSE build, as it seems to bring very little except increasing the download size :)
scott1256ca
31st August 2007, 08:41
I'm new to this, so please bear with me.
I running 1.1.34.2
Trying to convert a 6ch wav file to aac. All I get is 2 channel output.
neroAacEnc.exe -q0.3 -lc -if dead_aud2.wav -of dead_aud.mp4
also tried
neroAacEnc.exe -if dead_aud2.wav -of dead_aud.mp4
Is there some limitation? Is there a different download or version I should use?
I am opening the mp4 file in zoomplayer or mplayer and checking on the format in ac3filter. Decoder info says input format is PCM16 2/0 ...
When I open the .wav file, it says input format is pcm16 3/2.1
What am I doing wrong?
Thanks in advance
menno
31st August 2007, 08:44
I'm new to this, so please bear with me.
I running 1.1.34.2
Trying to convert a 6ch wav file to aac. All I get is 2 channel output.
neroAacEnc.exe -q0.3 -lc -if dead_aud2.wav -of dead_aud.mp4
also tried
neroAacEnc.exe -if dead_aud2.wav -of dead_aud.mp4
Is there some limitation? Is there a different download or version I should use?
I am opening the mp4 file in zoomplayer or mplayer and checking on the format in ac3filter. Decoder info says input format is PCM16 2/0 ...
When I open the .wav file, it says input format is pcm16 3/2.1
What am I doing wrong?
Thanks in advance
The MP4 file always says 2 channels, those players should get the info from the AudioSpecificConfig not from the mp4 track header itself. Try decoding it and you'll see that 6 channels come out.
scott1256ca
31st August 2007, 09:09
thanks. I'll try tomorrow.
lolent
14th October 2007, 01:29
I think there is a problem the nero encoder is not available anymore on nerodigital.com site ?
Someone has informations about this ?
Schrade
14th October 2007, 02:30
Huh. Wonder why it's off their page.
Ah well.. latest version is available here:
NeroDigitalAudio+ v1.1.34.0 (http://www.sendspace.com/file/57fc3f)
Sharktooth
14th October 2007, 03:54
1.1.34.2 (http://www.sendspace.com/file/4vrrly)
menno
14th October 2007, 07:23
It seems to have been lost in the webpage update for Nero 8. I'll see if I can get that solved :)
arfster
30th October 2007, 15:24
Is the audio ripper in Nero 8 of the same quality as this? (on highest quality settings, 2nd pass etc). Commandl ine is OK for a few files, but if I want to rip all my CDs the windows version looks a bit more practical :-)
menno
30th October 2007, 15:37
The current version in the web demo is the same version number as this command line encoder. Next webdemo will have an updated version IIRC.
There are also some batch tools around that can use this command line encoder, foobar2000 for example. Search this forum and you will find more. You can also have a look at http://www.hydrogenaudio.org
Bigmango
30th October 2007, 15:43
The current version in the web demo is the same version number as this command line encoder. Next webdemo will have an updated version IIRC.
According to a post from JohnV a couple months ago, Nero Recode does not do 2 pass audio encoding. Even if 2 pass is selected, it will do 2 pass for the video but not for the audio.
Has this changed ?
Also, the Nero wave aac export ui is very limited and you can't select 2 pass encoding either (even if saving the file to a wave). Is this going to improve ?
menno
30th October 2007, 15:49
According to a post from JohnV a couple months ago, Nero Recode does not do 2 pass audio encoding. Even if 2 pass is selected, it will do 2 pass for the video but not for the audio.
Has this changed ?
The new Recode (next release I think) will do proper 2pass for audio. It will also have better bitrate control for AAC.
Also, the Nero wave aac export ui is very limited and you can't select 2 pass encoding either (even if saving the file to a wave). Is this going to improve ?
Yeah, we consider adding some more options, but probably not 2pass, this is difficult considering the structure of the plugin manager (in some Nero apps the files will get written directly to a CD for example, this will not work well with 2pass, unless you use a CD-RW :p ).
Bigmango
30th October 2007, 16:50
The new Recode (next release I think) will do proper 2pass for audio. It will also have better bitrate control for AAC.
Awesome :thanks:
Also, (sorry this is off topic) if you communicate with them, please don't forget to bug the devel team for 720p AVCHD support (it now only supports 1080i & 1080p) :)
SpAwN_gUy
9th November 2007, 11:21
1.1.34.2 (http://www.sendspace.com/file/4vrrly)
i guess, something is fixed...
same version HERE: http://www.nero.com/eng/down-ndaudio.php
Sharktooth
9th November 2007, 16:20
yes. menno said they fixed the web pages in another thread
Sharktooth
1st March 2008, 14:34
leave alone the SSE version... there's no speedup... at least on your CPU...
menno
20th March 2008, 17:18
FYI here is a list of fixes in the current Nero 8 release (8.3.2.1)
Ndaudio version 1.1.34.13
* Greatly improved 5.1 encoding quality
* CBR now produces actual requested bitrate
* Improved 2nd pass encoding bitrate control
* Fixed MP4 file issue with 2nd generation iPod Shuffle
This encoder is used in:
* Nero Burning ROM (Encode Files, Save Tracks)
* Nero WaveEditor (save)
* Nero SoundTrax (save)
* Nero Recode (only with movie)
* Nero StartSmart (Audio Ripping)
* Nero MediaHome (if your receiving device supports AAC)
Sharktooth
20th March 2008, 17:22
is this encoder version also available with a CLI?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.