First of all, thanks for this awesome encoder, Nero!

I've encoded a few files via the LC VBR profile at q 0.15 (for my PocketPC device), and I admit I'm shocked and amazed at the quality it delivers. However, at q 0.14, the lowpass apparently drops sharply, and much to my chagrin, much of the audio's high frequency signal is cut off.

Is there a way for the (advanced) user to manually set the codec's lowpass frequency? I think this would help tremendously in the AAC-LC low-bitrate area for those of us who cannot play AAC-HE on any hardware or mobile devices. Thanks!

PS: I'm glad to finally be a part of the Hydrogenaudio community!

Try Speek's BatchEnc: http://members.home.nl/w.speek/batchenc.htm

If you use EAC, tags can be made with TG.EXE

Program: c:\windows\system32\cmd.exe

Additional command line options: /c c:\<path>\neroaacenc.exe -q 0.6 -if %s -of %d && c:\<path>\tg.exe %d --artist "%a" --album "%g" --track "%n" --title "%t" --genre "%m" --year "%y"

Seems to work ok.

Ivan or Garf:

Whenever the encoder is updated, will you let us know here? Or will we be able to just check the site (@ Nero) for it to tell us that an updated version has been posted?

Are you sure the encoder didn't switch to HE AAC? Try forcing LC AAC with one of the options. -lc I think

No it's not, he uses LC, did he use HE profile not will get cut off high frequncy, downsample to the 22khz or lower.

Low pass frequency sound like good option, like various stereo modes, and every pro thing.

Great encoder... very good work.
I have a question though. I saw some posts earlier that the NeroAacEnc.exe checks if the system has support for SSE SSE2 and SSE3... and uses the ones that are available ... does NeroAacEnc_sse2.exe do the same thing? (refering to SSE3 support) ...

If my system supports SSE3 instructions will the encoder make use of this? And if so... witch executable?.. the nonSSE or the other?

I don't fully understand what you are saying, but if you decode HE AAC with a LC AAC decoder you will indeed get a 22kHz file, which has the same effect as lowpass at 11kHz.

When you use LC and lower bitrates lower than 96kbs you get downsample like 32,22khz and other, but with lowpass switch you can stay to 44khz but with artifacts. with 22khz you get a big cut off of high frequencyies.

I have experimenting at low bitrates in LC profiles as well, comparing with iTunes 64kbps. Interestingly, what I found is I could almost always ABX the -q based VBR vs both iTunes and -2pass vbr, but not the others. The observation being that for the same (low) bitrate, -q always sounded much worse, with some rather nasty warbling artifacts.

I have settled on -lc -br 64000 -2pass

To be honest, I cannot ABX between this setting and iTunes 64kbps, but 2 pass vbr has got to be better ;-) and I am glad to get rid of iTunes.

Been using that one for ages... I've even recommended it to others asking similar questions on HA. And yes, it works fine with this encoder as well, but what I had in mind was something more along the lines of "Ivan & Menno" (Speek's older, dedicated frontend for Psytel and FAAD). Something that would give an end-user easy access to relevant options, without said user having to suss out the proper command-line syntax.

Nothing wrong with proper command-line syntax, of course! But while I'm thoroughly comfortable with BatchEnc, if I want to turn a novice friend on to this encoder it would be nice if there was also a novice-friendly way to learn about it.

- M.

I did in fact use the -lc switch, and I can assure everyone that my encoded files are indeed reported as 44.1khz. It is the codec's lowpass I am referring to in my above post. The reason lowpass exists is to mask encoding artifacts which would inevitably be present in the audio's high spectrum when the bitrate falls too low for the encoder to otherwise conceal them. The Nero LC encoder, for instance, produces very few annoying "artifacts" even at -lc -q 0.1 but with a much higher lowpass frequency, so the resulting file would have very little high-frequency preservation and thus sound "dull," "flat," or "garbled." In my case, however, I find Nero's current lowpass too aggressive for my music, and I'd like to be able to "tell the encoder so" by manually specifying a higher lowpass frequency.

To demonstrate what I mean, try the following test.
With an audio file containing many audible high-frequency components, perform an encode at -lc -q 0.15 and another at -lc -q 0.14. The difference: though only a tiny bit smaller, the q 0.14 encode will sound drastically flatter because the high-frequency components are drastically reduced compared to the q 0.15 encode. In conclusion, the high-end will be effectively eliminated due to the codec's lower lowpass frequency at q 0.14.

Let me reiterate that this is not a subjective statement of quality, but rather an objective statement regarding the frequency range of the resulting file, which is drastically and perhaps unpleasantly reduced when encoding below q 0.15.

My initial question was whether or not an option exists with which the user can tweak or otherwise adjust the lowpass filter, which I believe to be overly aggressive for my content.
Cheers!

First of all, thanks for this incredible release -- I registered with Hydrogenaudio just to say that.

Question:

I'm a registered/paid user of both Nero versions 6 and 7 but I have been unable to upgrade to Nero7 because I rely on dBPoweramp's Nero encoder for all my transcoding (typically, downloaded FLACs --> Nero AAC for my iPod), and dBPowerAmp's encoder module is incompatible with Nero 7: apparently this use causes Nero 7 to detect the use as trial-basis, even if you have the full product installed, and this is a known problem. So I have continued to encode with "only" Nero 6 installed. (Codec version: aacenc32.dll version 3.2.0.24)

I got your new command-line encoder to work with Fb2k, thanks to the tips on this board (yay!), but I was unable to get it to work with dBPowerAmp's command-line module. The Ahead CLI encoder barfed, claiming that it wasn't getting proper WAV files, so I guess that the dBPowerAmp FLAC decoder doesn't result in the files spending any time as true WAV. :(

However, I don't encode very aggressively. Usually, I encode from FLAC to Nero AAC at 224kbps. So my main question is: should I sweat trying to get the newest encoder to work in my lifestyle? Is there a significant improvement at bitrates such as 224kbps which should convince me to leave v3.2.0.24 behind for the new, free encoder? And if so, the question I guess goes out to the board at large as to whether anyone has gotten this encoder to work in the dBPowerAmp world for FLAC input.

Very soon I will release english version MPWGUI 2.1, it's extremly simple & user-firendly GUI supported:
decode: aac/mp3/ogg/wav/ac3/dts/aif/flac/mpa/mp2/mpc/wma/wv/ape... maybe I forgot something
encode: ape/aac(LC/HE/HC/LTP - iTunes/NeroAAC/FAAC)/flac/mp3/mpc/AoTuV OGG/wav/wv(only lossless mode)
Current russian version (2.0) available at http://dsrt.boom.ru
First english version will be available at http://dsrt.boom.ru/down-eng.htm

I'll try it, thanks.

@ Apesbrain: Works like a charm, thank you very much. So simple, and I tried and failed with mareo...

Since a GNU/Linux version is in the works, a simply recompile should make it available for Mac OS X as well...
/me wait for the Mac OS X version.

I can only say, YES, we commited ourselves to full cross-platform support.

We are working very hard on getting the Linux version out and provide our valued Linux users with first-in-the-world native AAC highest-quality encoding support.

I will look into supporting other proposed platforms as soon as Linux is deployed.

I also wish to thank you all for such a huge support for this move - I really hope also this will also make our technology higher-quality with help from everyone here.

They both do it. SSE2 just requires at least SSE2 to run, but is a bit faster.




Got a sample or something where this is obvious? I'd like to investigate.




I much prefer the correct solution and that is for us to do more tuning to find the optimal lowpass settings, and perhaps add some more intervals than the current, apparently too abrupt, switch. Low bitrate LC AAC is currently suboptimal, because we strongly recommend to use HE-AAC or HE-AACv2 at those bitrate, so LC AAC didn't have as much tuning in that area. But it is certainly something that can and will be improved.



I'll certainly give a note here...




I would be amazed if the old encoder managed to cause an audible artifact at such a high bitrate, so we could keep massively improving it for 10 years and you'd never hear the improvement. However, if you're encoding at such a high rate, you are perhaps interested in inaudible improvements and then there might indeed be some improvements you'll never hear




...I don't think so. I saw some people on heise.de commenting that since the encoder is commandline, compiling a Linux version is just a matter of recompiling.

I'm afraid NOT Please don't expect this too soon.

how do i enable PNS mode?

I found the Encoder to be a little faster in SBR mode than in LC and even faster (twice as fast as LC) in SBR+PS mode. Just interested, what's the explanation for that?

Regards; ilikedirt

SBR mode: encoder LC core (and most psychoacoustics) runs at half the sampling rate (22kHz), so it has half as much data to process.
SBR+PS: as above, but not it's mono, too, which means another halving.

garf? how do i enable PNS?

the lowpassing in LC is horribly low.

My thoughts exactly. Unfortunately (or perhaps fortunately for encoding newbies/novices), these advanced options are decided upon automatically by the encoder and remain hidden from the user.

Therefore, I'd like to suggest an "advanced settings" group of options in which the advanced user can modify settings according to individual preferences, source type, or for testing purposes. Oggenc, for instance, has advanced features available for use via the "--advanced-encode-option" set, in which the advanced user can configure various high-level options such as impulse trigger and lowpass; the result of which being that I have tweaked these options according to what yielded the best average personal ABX result. This is based on the principle that a single lowpass doesn't necessarily apply well to all types of audio (or, to a lesser degree, to each listener's personal preference)--it is generally accepted, for instance, that heavy rock music in vorbis (AoTUV) requires a lower lowpass than, for instance, light pop. An advanced settings category like that present in vorbis (perhaps separately documented to keep newbies away) would potentially prove very useful for advanced users, myself among them. (Not to brag ).

One more quick question: will this encoder be updated at fixed intervals (as it was in the past), or will it generally go through updates (and reuploads) as soon as improvements are made? Judging by the responses in this thread and the fact that it was changed already in only a few days, I'm strongly inclined to believe the latter, but I just wanted to be clear on this.

Again, thanks for the free encoder and I wish you the best of luck in upcoming improvements!
DeathTheSheep

I'd like to congrats Ivan and the Nero Digital team (I already did it by mail), but I must say that I'm truly shocked by this announcement:



If I understand correctly, this encoder:
1/ is crystal clear at every bitrate. Did someone listened to 16 kbps encodings and confirmed the clarity? IIRC, the latest 48 kbps explicitely shows that 48 kbps (thus lower bitrate) encodings are very far from "crystal clarity".
2/ is Award Winning at every bitrate. Could someone give me links to these awards? The only "award" competition I know is the 48 kbps, and this test ended with no winner at all.

I recall that the board's Term of Service are very explicit on the following point:
8. All members that put forth a statement concerning subjective sound quality, must -- to the best of their ability -- provide objective support for their claims.

May I insist and ask for a link pointing to this full bitrate range award in order to back up the initial claims?

Hmmm, I do agree it doesn't make any sense though. I've removed that claim. Ivan can ask marketing for their sources and put it back if they reply

Thank you Garf

You did it. I gave back my claims from doom9 forum.

I have not been able to ABX nero against iTunes using iTunes 128k VBR and q settings around 0.43 (or whatever it takes to get a similar bitrate to iTunes). I'm wondering if others can?

In case anyone's interested in getting this all set up in Linux, here's a script I use to encode, tag, then replaygain:



and here's the corrosponding setup string for KAudioCreator:

I just tried on harpsichord and succeed

TEST#1

>> original sample <<
Nero -q 0.435 bitrate = 118 kbps [.MP4 file]
iTunes VBR 128 bitrate = 128 kbps [.M4A file]

=> difference was really obvious to my ears. But I'm tempted to say that I'm very sensitive with harpsichord sound (I often claimed to hear strong distortions that other people couldn't clearly hear) so try yourself.
Bitrate is also significantly lower. That's why I tried with a second harpsichord sample (test#2).


TEST#2

>> original sample <<
Nero -q 0.435 bitrate = 131 kbps [.MP4 file]
iTunes VBR 128 bitrate = 129 kbps [.M4A file]

Distortions was a bit harder to catch. ABX test was clearly better when I focused on the pre-echo issue (second half of the sample). This time, the bitrate discrepancy can't be invoked to explain the difference.


But it's just and only harpsichord. I noticed this issue when Nero 7.2 was released (see the corresponding thread) while listening to 150 samples; for most of them quality was fine (or close to be so: extensive tests would be required for confirmation but I don't have time for them). Harpsichord is often problematic (and clearly not representative of the whole quality of an encoder; and of course not really a concern for people that don't listen to 17th and 18th century music) with lossy encoders with rare exceptions.


EDIT: offset & gain were corrected

Thanks for lending us your ears

I tried on a random selection of tracks, and a few problem samples of my own, which I could ABX with the previous versions of the encoder. Nice to know what to look for; I'll try to find a few tracks wiht harpsichord in my collection.

does anyone know why it errorlevels 1 if OK?

Thanks for the initial test. I think it would be nice to have another test that included iTunes and Nero at around 128 since that last one didn't really count.

For the record, I hate Harpisords compressed or no. When an encoder screws up violins is when I'll cry foul.

Was anyone able to tag the files with MPEG4ip's mp4tags.exe?

1st sample from previous Guru's post.

Nero -q 0.435 - 172 kbytes ( quite easy to spot)
Nero -q 0.435 -2pass - 204 kbytes
Itunes VBR 128 - 227 kbytes



-q x (VBR) + 2pass can be usefull?

VBR + 2 pass doesn't work (and doesn't make sense).
Anyway, testing 2-pass on short samples should be avoided in my opinion (the bitrate distribution is quite different from what it should be while encoding the complete track with the same encoding mode).

If I understand you correctly. VBR+2 pass can have better bitrate distribution on short sample but not on long ones (real life encoding 3-5 minutes).

Maybe it would be better to check performance of VBR + 2 pass on long samples. It is new encoder. Maybe something has chaged since wma 2 pass.

Garf says that VBR+2pass hasn't sense but ...... it would be interesting and usefull to see (pre)abx test.

Excuse the newb-like question but I'm having trouble getting any 3rd party app to recognize this encoder (namely, Foobar and Dbpoweramp). Inside of Foobar, under Tools --> Converter (after placing neroAacEnc.exe in the Foobar prog directory), the only encoder I'm given access to is the one that claims to require that Nero be installed. I'm probably missing something obvious or missing a Foobar component (I'm using v0.9 and have an AMD AthlonXP Processor).

No no no...
The short sample story has nothing to do with quality.
If you test a 10 sec long sample in two pass, the encoder would distribute the bitrate among 10 seconds only. In a "real life scenario", your ten seconds will be encoded very differently because the encoder would distribute th bitrate among 4 minutes (it's an example). In other words, the quality of a short part completely depends of the distribution of the whole file. That's why encoding a short musical moment as short sample instead as a short part of a bigger composition should lead to a different output, even if the input and the encoded setting are the same.
Example:
I built a bitrate curve of the V16 sample (the one you test) encoded with three settings [EDIT] and made a big mistake*. Example is therefore removed, and guruboolez is going to bed :/

* mistake for people who saw the graphs: I compared a sample-based VBR encoding to a track-based 2pass encoding instead of comparing both inputs at the same encoding mode.

vinnie97> update to foobar2000 0.9.2 beta if you want to use the GUI (with slider and encoding mode selection) or add a new CUSTOM preset to foobar2000 with the following options:

Encoder: neroAACEnc.exe
Extension: MP4
Parameters: -ignorelength -cbr 128000 -if - -of %d

Format is: LOSSY
BPS...: 32

Thank you again, Guru...forever indebted, etc. The new version of Foobar revealed the GUI options and accepted the new encoder.

I'm just compared files generated by NeroAACEnc & NeroAACEnc_sse2 (Win2k & iP4 processor) at same settings (-cbr 192000) and the same source... after decode by NeroAACDec WAVs slightly different from each another... Difference about +-1
What encoder is better?... I'm understand what +-1 - is a ridiculous difference but...
...When I'm used FAAD for decode process difference rise to +-2... and iTunes decode leads to totally different WAV.
What decoder I should use?
...When I run NeroAACEnc & NeroAACEnc_sse2 under Win98SE... NeroAACEnc_sse2 ended at same result as NeroAACEnc_sse2 under W2k/WXP... but NeroAACEnc generated 3rd version different from NeroAACEnc_sse2 & NeroAACEnc under W2k... I'm think it is a math issue... little difference.. but this is a straight path to overflow... Or I'm little paranoid

Thanks. I was already using wine for this, but wine is way too slow for executing things, at least on my Duron computer (which is the fastest that I have at my disposal). I'm anxiously expecting the Linux binaries and I do hope that they work fine with Debian's testing distribution.

BTW, I didn't know about atomicparsley. I think that I will package it for Debian. A good thing, though, would be to use easytag to tag mp4/m4a files. All with native tools.


Regards, Rogério Brito.




Thank you very much for this piece of news. I am anxiously awaiting for this release.

Oh, BTW, regarding your initial post, you mentioned that



Which command line options are available for this? I tried seeing the output of strings on the (non-SSE2) binary, but I couldn't guess how to enable that. Sorry if I am missing something obvious.


Thanks in advance, Rogério Brito.

1) Well be carefull with neroaacenc you can choose 2pass period (in fact buffer). bitrate will be always constant on this period. It's an "streaming scenario" and "real life scenario". Bitrate repartition will be between pure CBR RC mode and pure VBR quality RC mode.

2) if 2pass RC mode is good then work on 10 secondes sample is really not a problem.

He's not saying it's a problem, he's saying encoding just the sample or encoding the sample as part of something else are two entirely different things (and he's right).




The +- 1 bit are simply rounding errors, which are expected.


As for iTunes leading to an entirely different WAV, that's probably because iTunes either:

• Doesn't support HE-AAC
• Doesn't support HE-AACv2
• Doesn't support gapless decoding

No, No, No, No, No, No, No, No, No, No, No, NO!

If you would run an 10000 pass encoding with VBR, the effect should be exactly the same as in the first pass.

The reason this is not happening is because this mode is not supposed to be used, I didn't anticipate anyone being silly enough to use it, and so the encoder is doing just random things when you try this. If you let it do random things on the samples where it performs worst at in normal mode, it might just by pure change produce a better result, but in general I would expect seriously degraded performance.

It might perpaps, purely hypothethically, be possible to get some advantage from 2 pass even in VBR, but his is just one silly idea I have to perhaps try and implement in the future, and nothing of this is implemented in the encoder at all.

So please, just remember, 2 pass is for ABR.

The "constant" word is special is the AAC world
Anyway, I compared the bitrate curve of four different 2pass encodings:

128 kbps 2pass with a period of 2000 ms
128 kbps 2pass with a period of 10000 ms
128 kbps 2pass with a period of 30000 ms
128 kbps 2pass with a period of O ms (unrestricted)



a zoomed graph is available:
http://gurusamples2.free.fr/ndaac/A5_2pass_bitrate_zoom.png

As you can see, graphs are really similar (excepted at the very end). The unrestricted mode (period 0) behave also differently on the beginning but the three others (period of 2 sec, 10 sec, 30 sec) are close to be identical during the two first minutes. Moreover, the bitrate doesn't look constant at all during the selected period

• has an extra 10 sample delay at the beginning (last time I checked)

Why don't you just disable 2pass in VBR Mode?

Another graph.
This time I split each 2-pass encoding with YAMB (MP4Box) into shorter parts. The length of each part correspond to the 2-pass averaging period. I works pretty well (each small part in exactly cut at the right sample!).
There are:
- 77 segments of 2 seconds (input: -br 128000 -2pass -2passperiod 2000.mp4)
- 16 segments of 10 seconds (input: -br 128000 -2pass -2passperiod 10000.mp4)
- 6 segments of 30 seconds (input: -br 128000 -2pass -2passperiod 30000.mp4)

The last 10 sec & 30 sec segments are not present in the graph (they're too shorts because reference file is not a multiple of 10 and 30).





As you can see, the bitrate of each 2-pass segment is by far not constant.

-2 seconds: MIN=122 kbps MAX=153 kbps AVG=130kbps
-10 seconds: MIN=125 kbps MAX=179 kbps AVG=130kbps
-30 seconds: MIN=127 kbps MAX=149 kbps AVG=119/137kbps [complete serie: 127-129-133-149-149-27: the series is too short, hence the inaccurate averaging]

It also illustrate why short samples shouldn't be used for listening evaluation of "2-pass mode". If you encode each segment separately, all of them should end at 128 kbps and the plots would be perfectly linear; if you extract them from a long encoding, the bitrate would vary as shown in the plot's variations. Here: the variation goes from 122 to 179 kbps... no need to say that it should affects the output quality.