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

2007-08-06 - Version 1.1.34.2

• 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

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

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 .



Some info about processor (from CPU-Z):



Plain version works well. Are Athlon processors unsupported by the SSE build or it's just a bug?

Same problem here.

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.

It might be an Intel compiler related problem:
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

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.

Indeed Thanks again to our beta testers!



That is probably as easy as getting an OS X development machine here... so I can try, but I don't promise anything



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

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

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

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

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

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?

The license says
so I think the answer is no.

Judging by the previous release schedule we're expecting a 6 - 12 month wait? So I won't hold off any encoding projects.

Thanks!

Does this mean that we should use non-SSE version though our CPUs support SSE?

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

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?

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.

mp4tags from the MPEG4IP package or AtomicParsley (SVN version)...

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.

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.

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.


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. The repositories can be found on the site, the GPG key is here.

Edit: Medibuntu 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


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

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 in a package that I maintain.

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