A new version of the Nero Digital Audio+ package has been released on http://www.nerodigital.com/ (http://www.nerodigital.com/)
The package can be downloaded here: http://www.nero.com/nerodigital/eng/down-ndaudio.php (http://www.nero.com/nerodigital/eng/down-ndaudio.php)
2007-08-06 - Version 1.1.34.2
- neroAacEnc:
- Retuning of almost all bitrates
- Fix in HEv2 encoder/decoder delay
- Fixed incorrect streamlength written in MP4 files
- Removed -hinttrack option
Is this essentially the same package that was released for the listening tests, or is it different?
Is this essentially the same package that was released for the listening tests, or is it different?
the one in the listening tests was 1.1.34.0 and this one has a .2 so i doubt it
1) q mapping fix for mono
2) q mapping fix for -q 1.0
1) q mapping fix for mono
2) q mapping fix for -q 1.0
Thank yooou.
1) q mapping fix for mono
2) q mapping fix for -q 1.0
Thank yooou.
This is pretty awesome. The last two changes were fixes to bugs pointed out by members of our very own HA community prior to official release!
Just goes to show that some public beta testing isn't necessarily a bad thing.
As there is a Linux version now, would it be difficult to get it to run on OS X?
Dang it, I ripped a CD with the old version just a few minutes before I saw this. Hopefully this release doesn't have any notable improvements.
Seriously though, thanks for updating the free encoder. Linux support in particular is much appreciated.
Hmm, it's strange - SSE build doesn't want to run on Athlon 64 with full SSE support under 32-bit WinXP .
C:\Bin>neroAacEnc_SSE.exe
Fatal Error : This program was not built to run on the processor in your system.
Some info about processor (from CPU-Z):
-------------------------
CPU-Z version 1.38
-------------------------
Processors Information
------------------------------------------------------------------------------------
Processor 1 (ID = 0)
Number of cores 1
Number of threads 1 (max 1)
Name AMD Athlon 64 3200+
Codename Venice
Specification AMD Athlon™ 64 Processor 3200+
Package Socket 939
CPUID F.F.2
Extended CPUID F.2F
Brand ID 4
Core Stepping DH-E6
Technology 90 nm
Core Speed 1006.3 MHz (5.0 x 201.3 MHz)
HT Link speed 1006.3 MHz
Stock frequency 2000 MHz
Instructions sets MMX (+), 3DNow! (+), SSE, SSE2, SSE3, x86-64
L1 Data cache 64 KBytes, 2-way set associative, 64-byte line size
L1 Instruction cache 64 KBytes, 2-way set associative, 64-byte line size
L2 cache 512 KBytes, 16-way set associative, 64-byte line size
FID/VID Control yes
max FID 10.0x
VID range 1.100V - 1.450V
K8 Thermal sensor yes
K8 Revision ID 4.2
Attached device PCI device at bus 0, device 24, function 0
Attached device PCI device at bus 0, device 24, function 1
Attached device PCI device at bus 0, device 24, function 2
Attached device PCI device at bus 0, device 24, function 3
Plain version works well. Are Athlon processors unsupported by the SSE build or it's just a bug?
Hmm, it's strange - SSE build doesn't want to run on Athlon 64 with full SSE support under 32-bit WinXP .
Plain version works well. Are Athlon processors unsupported by the SSE build or it's just a bug?
Same problem here.
Name AMD Athlon 64 3400+
Code name NewCastle
Specification AMD Athlon™ 64 Processor 3400+
Family/Model/Stepping FC0
Extended Family/Model F/C
Brand ID 4
Package Socket 754
Core Stepping DH7-CG
Technology 0.13µ
Instructions Sets MMX, Extended MMX, 3DNow!, Extended 3DNow!, SSE, SSE2, x86-64
Hopefully this release doesn't have any notable improvements.
None at all. It's a pure bugfix release. Encoding in stereo mode using any setting besides -q 1.0 leads to bit-identical results with both versions, as was stated in another thread.
Hmm, it's strange - SSE build doesn't want to run on Athlon 64 with full SSE support under 32-bit WinXP .
Plain version works well. Are Athlon processors unsupported by the SSE build or it's just a bug?
Same problem here.
It might be an Intel compiler related problem:
http://www.swallowtail.org/naughty-intel.html (http://www.swallowtail.org/naughty-intel.html)
AFAIK, we do not use Intel compiler for producing those binaries.
We'll check this out tomorrow.
I found a found a possible killer sample that sounds bad on Nero AAC at -q 0.5 and it is transparent on LAME 3.97 -V 5 --vbr-new.
http://www.hydrogenaudio.org/forums/index....showtopic=56849 (http://www.hydrogenaudio.org/forums/index.php?showtopic=56849)
I really appreciate the Linux version. Now I can finally see how much better it is than FAAC.
Now like another guy said, what's the chance of a Mac OS X version?
Thanks, you guys are great!
Great work guys!
I'll throw my hat in for an OS X version of the encoder.
This is pretty awesome. The last two changes were fixes to bugs pointed out by members of our very own HA community prior to official release!
Just goes to show that some public beta testing isn't necessarily a bad thing.
Indeed Thanks again to our beta testers!
As there is a Linux version now, would it be difficult to get it to run on OS X?
That is probably as easy as getting an OS X development machine here... so I can try, but I don't promise anything
AFAIK, we do not use Intel compiler for producing those binaries.
We'll check this out tomorrow.
Actually, for this release we do use the Intel compiler. I didn't know about this issue, will be better for next release.
Anyway, I think our current non-SSE build is faster than the old SSE build.
What is the new q value for approximately 100 Kbps VBR when used for DVD soundtracks? Previously I have been using 0.35
Does this page need to be updated to reflect the neq Q values?
http://www.hydrogenaudio.org/forums/index....showtopic=44310 (http://www.hydrogenaudio.org/forums/index.php?showtopic=44310)
neroAacEnc_SSE.exe is builded with OpenMP support (libguide.lib included in exe). Is it SSE or SSE2 build (because processors with SSE doesn't support multithreading)???
What is the new q value for approximately 100 Kbps VBR when used for DVD soundtracks? Previously I have been using 0.35
Does this page need to be updated to reflect the neq Q values?
http://www.hydrogenaudio.org/forums/index....showtopic=44310 (http://www.hydrogenaudio.org/forums/index.php?showtopic=44310)
No, that table should be more valid now than before (on average). It can always deviate, it depends a lot on what you're encoding.
No, that table should be more valid now than before (on average). It can always deviate, it depends a lot on what you're encoding.
Thanks for the info (and for the new version).
No, that table should be more valid now than before (on average). It can always deviate, it depends a lot on what you're encoding.
I can confirm this. I recently encoded 2727 tracks using the 1.1.34.0 version, mainly Metal and Hard Rock genres. Though there are also a few Classical recordings, the majority of my CDs is quite competitive for an encoder to process. Hence, the whole bunch's average of exactly 100 kbit/s (calculated by foobar) is a very good result for -q 0.34 (usually ~96 kbit/s).
No improvements to multichannel encoding? : (
Thanks for the update!
No improvements to multichannel encoding? : (
Thanks for the update!
No unfortunately, the next release will have huge (because there is room for that ) improvements for multichannel support.
I like the linux version (proper stdin support and such).
But the linux version is very slow, compared to the windows exe running under wine.
I just did a fast test with only one file, with wine it took 5 seconds and with the linux binary it took 9 seconds.
Its probably the different compilers, didn't know they make such a difference...
Windows binary:
time wine tmp/win32/neroAacEnc.exe -q 0.5 -if 1.wav -of test1.mp4
*************************************************************
* *
* Nero Digital Audio Reference MPEG-4 & 3GPP Audio Encoder *
* Copyright 2007 Nero AG *
* All Rights Reserved Worldwide *
* *
* Package build date: Aug 6 2007 *
* Package version: 1.1.34.2 *
* *
* See -help for a complete list of available parameters. *
* *
*************************************************************
Processed 119 seconds...
real 0m4.988s
user 0m4.824s
sys 0m0.120s
Linux Binary:
time tmp/linux/neroAacEnc -q 0.5 -if 1.wav -of test1.mp4
*************************************************************
* *
* Nero Digital Audio Reference MPEG-4 & 3GPP Audio Encoder *
* Copyright 2007 Nero AG *
* All Rights Reserved Worldwide *
* *
* Package build date: Aug 6 2007 *
* *
* *
* See -help for a complete list of available parameters. *
* *
*************************************************************
Processed 119 seconds...
real 0m9.173s
user 0m9.065s
sys 0m0.104s
....
Anyway, I think our current non-SSE build is faster than the old SSE build.
On my Windows XP Core2duo @ 3 GHz using foobar2000 converting from FLAC to mp4 (Nero Digital Audio+ 1.1.34.2), neroAacEnc.exe is about 5 times faster compared to neroAacEnc_SSE.exe
The convesion speeds of neroAacEnc.exe are in line with Ogg Vorbis and Lame 3.98 betas (always VBR with resulting bitrates between 100 and 160 kbps) but that the speed of neroAacEnc.exe is really slow.
Linux compile is so much slower because the processor specific optimisations have not been included (yet).
Thank you. Nero AAC became my favorite lossy format because it's good and I can play it anywhere (my car audio supports he aac)...
As there is a Linux version now, would it be difficult to get it to run on OS X?
That is probably as easy as getting an OS X development machine here... so I can try, but I don't promise anything
Thanks! It would be rather interesting, competing with iTunes AAC on their own turf.
I suppose getting the cheapest Mac Mini will do. And perhaps some older PPC machine off eBay for PPC testing, endianness can screw things up a bit.
Great with a linux-version. Thanks a bushel.
But could we get a linux-version of the tagger too?
Is it legally ok to package this for Linux distros, think an rpm package?
Is it legally ok to package this for Linux distros, think an rpm package?
The license (http://www.nero.com/nerodigital/eng/down-ndaudio.php) says
This License does not provide any rights to reproduce and/or distribute this software package in whole or in any part.
so I
think the answer is no.
No unfortunately, the next release will have huge (because there is room for that ) improvements for multichannel support.
Judging by the previous release schedule we're expecting a 6 - 12 month wait? So I won't hold off any encoding projects.
Thanks!
Actually, for this release we do use the Intel compiler. I didn't know about this issue, will be better for next release.
Anyway, I think our current non-SSE build is faster than the old SSE build.
Does this mean that we should use non-SSE version though our CPUs support SSE?
Does this mean that we should use non-SSE version though our CPUs support SSE?
Anyway, I think our current non-SSE build is faster than the old SSE build.
Great with a linux-version. Thanks a bushel.
But could we get a linux-version of the tagger too?
Thank you very much for the Linux release, but I have to second that request. At the moment, I have to turn to wine+Nero's tagger for tagging my mp4 files. Or does anyone have any other mp4-tagging solution handy for Kubuntu 6.10 Edgy? (Amarok supposedly does it, but I couldn't get my self-compiled sources to run, nor does my distro package offer the feature) I hope it's not too much trouble to compile the tagger likewise for Linux...
Does this mean that we should use non-SSE version though our CPUs support SSE?
Anyway, I think our current non-SSE build is faster than the old SSE build.
But someone have found bugs in SSE version,and we do'nt know if quality comes under the influence of these bugs.In another word,Will SSE version and non-SSE come about the files of same quality?
Thank you very much for the Linux release, but I have to second that request. At the moment, I have to turn to wine+Nero's tagger for tagging my mp4 files. Or does anyone have any other mp4-tagging solution handy for Kubuntu 6.10 Edgy? (Amarok supposedly does it, but I couldn't get my self-compiled sources to run, nor does my distro package offer the feature) I hope it's not too much trouble to compile the tagger likewise for Linux...
Well, what exactly is the problem that prevents you from successfully compiling the Amarok sources? Half a month ago I compiled the Amarok 1.4.6 sources on a Kubuntu Feisty system myself, in order to get MP4 tag writing and reading support for my newly created Nero AAC collection running. Just today the current SVN code flawlessly compiled as well. If it's about problems with the libraries found in the Edgy repositories, then Christian Marillat's Debian repository should fix the issue. At least that's the place where I got a working version of libmp4v2-dev (FAAD2) from, which is needed to compile Amarok with full MP4 support. MP4 Moodbar compatibility is another thing, this made me stick to the Debian unstable (Sid) repository in order to download the required gstreamer0.10-plugins-bad package.
And yes, I also second the request for a Linux command line tagger that could be used in conjunction with certain ripping GUIs, like K3b, KAudioCreator or rubyripper.
And yes, I also second the request for a Linux command line tagger that could be used in conjunction with certain ripping GUIs, like K3b, KAudioCreator or rubyripper.
mp4tags from the MPEG4IP package or AtomicParsley (SVN version)...
Well, what exactly is the problem that prevents you from successfully compiling the Amarok sources?
Can't remember exactly, but it was a source problem, not a dependency problem (followed a HOWTO others have followed with success, installed every package even remotely connected anyway); it complained about things not declared in the source IIRC. It is of course possible that I encountered an unfortunate moment where two updates clashed or something like that.
I cannot compile MPEG4IP because of the faac-faad2 incompatibility, but I gave up anyway because I want to test Feisty this week. Maybe I'll have better luck with compiling SVN sources on Feisty, or if anyone can point me to repositories holding the newest Amarok with mp4-tagging support, I can install them as well. Thanks anyway.
But someone have found bugs in SSE version,and we do'nt know if quality comes under the influence of these bugs.In another word,Will SSE version and non-SSE come about the files of same quality?
Which bug? Beside the bug that it is not working at all on some machines?
Just use the non-SSE build which also uses a lot of SSE code and is faster than the SSE build from the previous release.
mp4tags from the MPEG4IP package or AtomicParsley (SVN version)...
Thanks, I'll have a look into these. Preferably into the latter, since, now that you mention it, I remember that REACT2 also uses AtomicParsley for tagging .m4a/.mp4.
or if anyone can point me to repositories holding the newest Amarok with mp4-tagging support, I can install them as well
Haven't been successful concerning this one so far, but there's a package of EasyTag compiled with AAC support (easytag-aac) over at http://debian-multimedia.org (http://debian-multimedia.org). The repositories can be found on the site, the GPG key is here (http://www.debian-multimedia.org/pool/main/d/debian-multimedia-keyring/debian-multimedia-keyring_2007.02.14_all.deb).
Edit: Medibuntu (http://medibuntu.sos-sts.com/) offers Amarok 1.4.5 packages for Edgy. Maybe even one with the desired MP4 tag reading/writing support, since they state that their repository includes packages that aren't part of Ubuntu for legal reasons.
I just wanted to take a quick second to thank Nero, Menno, and Ivan Dimkovic for producing a Linux binary of their software.
Even by today's standards we're a pretty niche group that often gets left by the wayside, and I appreciate the support.
Now I have a lot of learning to do .
I was making a bitrate table with the new encoder and when I listened to some files I noticed bad artefacts at ~130 kbps: ringing, more or less strong according to the samples and sometimes not noticeable at all. I've compared it with an older release to Nero AAC (1.0.7.0) at similar bitrate and there's absolutely no problem (in worse cases it's simply subtle).
An exemple is available and include a lossless sample with two different encodings:
http://www.megaupload.com/fr/?d=ICHI80GW (http://www.megaupload.com/fr/?d=ICHI80GW)
short descriptions of all problems:
02.00 -> 12.00: male chorus suffers from ringing with some metallic effects (the beginning of “shall” at ~04.00)
12.00 -> 15.00: Trumpets are distorted
15.00 -> 18.00: "acidity" on violins, ringing too - and still issues with trumpets
18.00 -> end: mix of all problems and as conclusion (21.00 - 23.00) noisy horns (short-impulses)
A new version of the Nero Digital Audio+ package has been released on http://www.nerodigital.com/ (http://www.nerodigital.com/)
The package can be downloaded here: http://www.nero.com/nerodigital/eng/down-ndaudio.php (http://www.nero.com/nerodigital/eng/down-ndaudio.php)
Thanks for the Linux version. I'm preparing a new Debian package (for i386 only, though) of it as we speak.
On thing, though: the license file says that no redistribution is allowed. How paranoid should I be regarding this?
Regards, Rogério.
Haven't been successful concerning this one so far, but there's a package of EasyTag compiled with AAC support (easytag-aac) over at http://debian-multimedia.org (http://debian-multimedia.org). The repositories can be found on the site, the GPG key is here (http://www.debian-multimedia.org/pool/main/d/debian-multimedia-keyring/debian-multimedia-keyring_2007.02.14_all.deb).
Edit: Medibuntu (http://medibuntu.sos-sts.com/) offers Amarok 1.4.5 packages for Edgy. Maybe even one with the desired MP4 tag reading/writing support, since they state that their repository includes packages that aren't part of Ubuntu for legal reasons.
I use the easytag-aac package from Christian Marillat (which is quite responsive, BTW) all the time under a Debian with an old Duron 600MHz and I have no problems with it.
It tags MP3s, FLACs, AACs, Vorbis and even Speex (I asked the developers of easytag for this and they replied promptly with the support, as you can see in the Debian Bug Tracking System. I am sincerely quite satisfied with it.
I mainly use it for tagging, but I use iTunes in an HFS+ volume to organize the files. Everything has worked quite fine with me for playing things with my old (2nd generation) iPod and Linux players (I use three: moc, amarok, and audacious---note that this is
not audacity, which is the audio editor).
I highly recommend that. Well, I highly recommend migration of anything to Debian.
Regards, Rogério.
P.S.: I discovered a very serious and silly bug in Apple's fsck of its native filesystem, HFS+. For more details, please see Bug 436159 (http://bugs.debian.org/436159) in a package that I maintain.
On thing, though: the license file says that no redistribution is allowed. How paranoid should I be regarding this?
The license prohibits distribution. What is there to be paranoid about?
Besides, Quod Libet supports MP4 tagging via the Mutagen library. Picard, the MusicBrainz tagger, does too.
I use the easytag-aac package from Christian Marillat (which is quite responsive, BTW) all the time under a Debian with an old Duron 600MHz and I have no problems with it.
I'm not entirely happy with it at the moment, because embedding artwork inside ID3v2 tags for my portable player doesn't work well with the 2.1.2 version of EasyTAG. Displaying them with Amarok reveals heavy corruption of the images, which happens with both Christian Marillat's and an own compile. Gotta test the stable version in hope that it fixes this issue.
Maybe somebody will update the topic of recommended settings due to new q maping.
http://www.hydrogenaudio.org/forums/index....showtopic=44310 (http://www.hydrogenaudio.org/forums/index.php?showtopic=44310)
Maybe somebody will update the topic of recommended settings due to new q maping.
http://www.hydrogenaudio.org/forums/index....showtopic=44310 (http://www.hydrogenaudio.org/forums/index.php?showtopic=44310)
Read Post #21
http://www.hydrogenaudio.org/forums/index....st&p=510658 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=56845&view=findpost&p=510658)
I was making a bitrate table with the new encoder and when I listened to some files I noticed bad artefacts at ~130 kbps: ringing, more or less strong according to the samples and sometimes not noticeable at all. I've compared it with an older release to Nero AAC (1.0.7.0) at similar bitrate and there's absolutely no problem (in worse cases it's simply subtle).
An exemple is available and include a lossless sample with two different encodings:
http://www.megaupload.com/fr/?d=ICHI80GW (http://www.megaupload.com/fr/?d=ICHI80GW)
short descriptions of all problems:
02.00 -> 12.00: male chorus suffers from ringing with some metallic effects (the beginning of “shall” at ~04.00)
12.00 -> 15.00: Trumpets are distorted
15.00 -> 18.00: "acidity" on violins, ringing too - and still issues with trumpets
18.00 -> end: mix of all problems and as conclusion (21.00 - 23.00) noisy horns (short-impulses)
Thanks for the report.
Can you say which -q settings you used for both versions? That makes it easier for us to check
Anyone interested in a patch for the SSE version to get rid of that stupid Intel CPU check? I can post one, that is, if it isn't against the rules.
@menno: both ND versions were used with -0.45.
I've noticed something strange with my bitrate table. Average bitrate isn't linear and there's a break between 0.44 and 0.45 setting.
In summary:
setting: 0.40 0.41 0.42 0.43 0.44 0.45 0.46 0.47 0.48
---------------------------------------------------------------------
bitrate: 114 119 123 127 132 131 135 139 142
The bitrate table was built with my usual gallery of 150 full
classical music tracks. The values in this table are the average bitrate for each setting. The detailed table (see link below) is showing that 0.44 is from time to time bigger than 0.45 and 0.43. There's nothing worrying by itself.
But when I compared 0.44 and 0.45 encodings with the problem sample I've submitted, I was astonished by the quality difference! 0.44 is much better than 0.45 and has clearly less ringing. There must be a bug somewhere...
The ringing is not only audible but is also visible on any frequency graph (pointless without ABX of course) and 0.45 (and 0.46) looks considerably more agressive than 0.44.
In any cases the old nero digital version (1.0.7.0) at 0.45 outperforms the new one even with the most favorable (0.44 instead of 0.45) mode.
link: http://www.megaupload.com/?d=15LZ8LV9 (http://www.megaupload.com/?d=15LZ8LV9)
Guruboolez,
Yes we found something with the sample you send. Probably not many people would hear this problem, but we will solve it.
About the bitrates: The switch from 1 parameter table to the next can cause a glitch in the bitrate. However, with the old version you probably would have noticed that the steps in bitrate between the tables were much bigger. So I guess it can happen that bitrate even decreases, because we brought these switches much closer together. I guess it depends again on exactly what file you are encoding, as your table also proves
Hello,
1) windows: Has anyone tryed to use this with audacity as external encoder?
When using this commandline:
neroAacEnc.exe -q 0.12 -ignorelength -if - -of "%f".mp4
where "%f" is tag for the filename it says:
ERROR: could not parse WAV file
I don't know which software to blame, because audacity normally works with lame as a commandline encoder. Here is example commandline:
lame.exe -S --noreplaygain -V 2 --vbr-new - "%f".mp3
with lame, nothing is sent to stdout and file is encoded perfectly.
2) under linux: is it somehow possible to use this encoder to prepare a stream for live streaming to shoutcast/icecast server?
Would really appreciate a OS X release too, thanks.
In the mean time I'm having some trouble encoding with CDex 1.70b, I choose the Psytel AAC encoder in the settings and look up the NeroAAC exe.
But I end up with unplayable 108kb large files whatever encoding I choose, anyone one what the problem is?
Hello,
1) windows: Has anyone tryed to use this with audacity as external encoder?
When using this commandline:
neroAacEnc.exe -q 0.12 -ignorelength -if - -of "%f".mp4
where "%f" is tag for the filename it says:
ERROR: could not parse WAV file
I don't know which software to blame, because audacity normally works with lame as a commandline encoder.
I have the exact same problem on Linux with Audacity. I'm not familiar enough with encoding from STDIN to know for sure but I expect Audacity sends RAW PCM data while lame is fine with that, neroAacEnc requires WAV headers.
Thank you for this update. Unlike previous release, it works under Win98. Great!
For anyone as late to the party as I am, the linked download page seems to have disappeared. I've always had trouble navigating through Nero's site trying to locate their Digital Audio+ info, and this still remains the case. However I did find a working FileForum BetaNews location (for the moment at least):
http://fileforum.betanews.com/detail/Nero_...io/1150910171/1 (http://fileforum.betanews.com/detail/Nero_Digital_Audio/1150910171/1)
Hmm, indeed. Seems to have disappeared with the website update. I will complain on monday
Seems like it's still missing from the website.
Any direct link that we can access to get the codec, menno?
I'm beginning to think Nero's upper brackets don't like the idea of giving away their greatest audio encoder practically for free, but that's just me being skeptical. =)
Anyone interested in a patch for the SSE version to get rid of that stupid Intel CPU check? I can post one, that is, if it isn't against the rules.
They posted both SSE2 and SSE versions in the last update. I was looking forward to trying the SSE version on my Pentium III, but it failed the CPU check! The SSE2 version, which I didn't expect to work, got as far as showing the masthead, then executed an illegal instruction and crashed.
I wrote to Nero support and asked them to pass my results and cpuID output along to the developers, which they said they'd do. But then a week later the download is gone. I hope it wasn't my fault...
Anyway, offline, I'd be interested in testing your patch if it's against the regular SSE (not SSE2) version from the most recent release.
We are working on putting the download back, it seems not so easy since the website update and it has to be translated in multiple languages, but it will be back don't worry.
Regarding any SSE and SSE2 versions, these will completely disappear in the next updates. All optimizations have been completely merged in our internal builds and making a special compile didn't give any speed gain anymore.
neroAacEnc.exe -q 0.12 -ignorelength -if - -of "%f".mp4
where "%f" is tag for the filename it says:
ERROR: could not parse WAV file
I don't know which software to blame, because audacity normally works with lame as a commandline encoder.
I have the exact same problem on Linux with Audacity. I'm not familiar enough with encoding from STDIN to know for sure but I expect Audacity sends RAW PCM data while lame is fine with that, neroAacEnc requires WAV headers.
I've the same problem too, but these wav files were decoded from wv under WinXP x64 and wvunpack. Most tools do work with these wav files but every files decoded by wvunpack can't be encoded using NeroAAC. Any ideas or solutions on this?
thank you!
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)
Any idea when the improvements will make it into the CLI? Or is there already an updated version floating around somewhere?
We will probably do an update sometime next month.
Only now I found that Nero encoder is multithreaded. Transcoded 2 hs length single files.
Great.