This has already been done and will be in the next update. [1]

[1] I'm wondering if we'll now get people who refuse to upgrade "because the new encoder doesn't support VBR 2pass".

bet on it.

Really good work. Conclusion is 2passperiod don't work correcty or perhaps that we don't understand correctly 2passperiod fonction ... ???

Anyway in theory we can make streaming with simple CBR, CBR 2 pass (buffer) or with ABR 2 pass (vbv) and it's a "real life scenario". Make 2pass on short sample is not stupid way.




Well but you make exactly that when you compare CBR codec vs VBR codec with your short sample for subjective test ... ;-)

Is that just a gut feeling, or have you tested it? I notice no slowdown on my machine, and I wouldn't really expect any. Wine isn't a virtual machine or anything, it just grabs the Win32 calls and translates them to the Posix equivilents. I would think that with a command line encoder, the only OS calls would be to open the file at the begining and write the stream out as it's running: hardly anything to give Wine trouble.

off topic, but, did you had to quote that much text, and the whole graph?

starkly contrasts with this:


It seems these potential complaints would arise from the complete novices, and thus it would make no difference whether or not they upgrade, seeing as the usability of the codec for them is very low in the first place. A piece of software is designed for an intended audience/userbase, and as Ivan stated, this particular CLI codec does not aim for a novice userbase.
Also, in reference to my previous post requesting these promised "additional methods [the user] would wish to use in the process" be exposed; the removal of the 2-pass VBR option--despite 2-pass VBR being verifiably (and theoretically) quite useless--would undermine the control that the expert user has over the encoding process, a process in which the user is expected to know full well what he's doing and what to expect of the encoder.
Making the encoder novice-friendly at the expense of the freedom of the "pro" user does little to fulfill the codec's aforementioned professional userbase.

In fact, as of late, the encoder has become decidedly more novice-friendly and less open to expert configuration. For instance, the PNS option has vanished. It is now frowned upon to set even the AAC profile, the #1 determining factor in the resulting AAC's playback on external hardware/devices. I'm not saying or even implying that this is "wrong" or "bad" in any way, though; I'm simply saying that the target audience now appears to be quite different than that which was initially stated. I certainly wouldn't mind seeing that Vorbis-like "advanced options category" I suggested come to life

You are making things way too complicated. When we say "advanced users", we mean people who are able to use a commandline encoder, and don't need a shiny GUI, but can, for example, figure out how to encode with foobar2000. The kind of people who have been complaining so heavily for years here that they have to download the entire Nero suite just to get a 1M encoder.

The encoder internals are not meant to be tweakable from the outside for users, and if it depends on me, they will never be outside the sheer necessary things (like LC vs HE-AAC).

I don't trust 99% of the "advanced" users to use these settings correctly, and the past with lamelines and everything (and even this thread) clearly show that it is a bad idea to expose them.

<hat and cape on>
I'm in a position where I can steer history so we do not end up downloading a garbled 192kbps SBR+PS L/R stereo tune from an artists website, and I will take my responsibility to stop it from happening, at least with Nero AAC
</hat and cape off>

Garf didn't say that he is going to disable a wrongly used setting. He is going to disable a setting that doesn't work in the first place.

So, if anyone considers himself a "pro", and uses a setting because he believes it does A(x), but does Random(x), it will either mean the setting is useless (even a random result wouldn't be noticeable) or that he will give bad comments about the encoder.

As well you should!

Thanks for making such a great encoder available for free! Time to go try it out.

seriously though, PNS can only improve quality at lower bitrate LC-AAC, so why kill it, please enable a PNS setting, please?

Very nice Honestly, I couldn't agree more.

Well, my last few lines on the subject before people get their hopes up about awesome 999kbps q 1 SBR+PS L/R -9pass 400ghz 2-bit PCM aac audio :
The Vorbis encoder has seperately documented, nearly hidden commandlines which all start out like --advanced-encode-option X, which makes it very hard for a user to even find about the advanced options, but still available for Mr. Pro to enable his PNS and tweak the lowpass on his 64kbps LC-AAC files

But I gotta hand it to you-- you make a very good point, and the encoder's yours anyway, so...

PS: The underlined passage is not a link. It's merely underlined. Just to clear things up.

Boo for the fake link.

It's not a link, it's just underlined to draw attention to itself above the rest of my post Yay for the real underline.

edit: If you want a link (it's fun to click things sometimes, right? ), here you go: http://wiki.hydrogenaudio.org/index.php?ti...ncoder_Settings or something like that... just grab the encoder and see if you can find them easily without that

L/R Stereo? That's nothing.

I know at least one person who swears by using the Winamp AAC encoder in Dual Channel mode.

You now know a second person, i agree with dark sheep, becouse is right for advanced settings, but for me M/S stereo not sounds good, you can me prove that is not true, but for me is not same, nevermind that be mp3/aac other codec which uses M/S, i can prove to you what i hear becouse the differences are very small and not noticable. Dual Channel are not god and not same as real stereo L/R, i am not voting for Dual channel, than for L/R.

Graf is right about other peoples who can't use propertly encoder and make stupid things like using sbr at high rates, ps or other things. And me are sick when download some mp3 and i discovered that song done by IS stereo or mp3Pro or some other bad things.

If you want to prove us - upload some samples encoded with a good AAC encoder (e.g. Nero AAC) and please pinpoint us to the stereo problems that you think won't be there if you use L/R coding.

Why is it hard to understand that AAC has the possibility to decide, on each frequency band, what is really better? Come on, people, this is not MP3 where you had to code entire frame as L/R or M/S (and, therefore, you always had to make some compromise)

Nobody needs to prove that you are wrong - but you are required by the board rules (TOS#8) to prove that you are right since you claimed it.

ivan, if the encoder cannot decide to use PNS when it very well could use it, then i'd like the option to use it myself.

thanks.

Just a quick question. Is this the same version that appears in Nero 7.2?

how about having 2 help options? like LAME --longhelp and --help

basic usage under -help (like the options now).. good for beginners
and all the stuff that can mess everything up under -longhelp ... enough options to keep control freaks like me from complaining about the lack of options (like the lowpass frequency )

anyways...

thanks for the encoder

Although I agree that access to advanced options could lead to garbled encodings by some who think that they know how to use them, there is that 1% of users (probably 0,1%) that could actually help with the improvement of the encoder, by finding settings for example which could provide better quality with certain files. We’ve seen this in the past with lame for example, where certain switches, like “--athaa-sensitivity x” or “--vbr-new” just to name a few, where proven (by that aforementioned 1% of people and verified by others) to offer better quality than the default settings, helping the developers improve the codec.

I’m just saying that limiting the access to the internals could possibly inhibit the faster evolution of the codec and I don’t think that lame’s or Vorbis’ good reputation was ruined by the offer of such advanced options or that there was a big damage done by those very few, who despite all the warnings, use dubious custom command lines.

As a last note, I think that at least it would nice to be able to choose, when to use SBR or PS within certain bit rate limitations of course. Something similar to what the old encoder did.

i'm with you on that one.

PNS would also be a good option to add.

reason why i am asking for this so much is because currently i have 2 mobiles i use for music that i switch back and forth with, one can play HE-AAC, the other can only do LC-AAC

in order to not use too much bitrate i encode the LC-AAC to 64kbps with PNS and it is sounding pretty good for the bitrate.

All right... here is a small list of a few switches I'd like to see added:


Sigh... wishful, wicked and ungrateful, isn't it?

Appreciatively,
- M.

I fully support the developers. I have seen the commandline mess in the history of LAME, and am annoyed by those newbies who does not know what they are doing, yet they just mess with the encoder and make some f**king crazy commandlines and claim to be a pro user. I don't want this history to repeat itself again if it can be prevented in the first place.

On the other hand, encoders should be smart enough and determine the optimal settings automatically, and it is the reponsibility of the developers to make sure the encoder works optimally in any situation. Users should not need to "tweak", and they should not tweak, the program themselves in order to get optimal settings.

So please, Garf and Ivan, close those development switches, and just leave them for your own development use. Then the world would be in peace.

I want to reply to some particularly stupid FUD on the doom9.org forum someone pointed me to:

http://forum.doom9.org/showpost.php?p=825151&postcount=164

The values I gave are AVERAGES. They're generated from running the encoder over a hopefully representative sample of my own music collection. The exact average you get will be only dependant on the complexity of your music, though if you encode enough, statistics tells us you should end up with something similar to my numbers. There is absolutely no guarantee that any given, isolated single piece you encode will end up with a bitrate that corresponds to that table.

In -q mode, the encoder solely and only looks at the output of the psymodel to determine how much bits to spend, and does not do any "averaging" whatsoever at all. There are no compromises, it's exactly what we say it is: pure, quality based VBR.

Any frontend for the new encoder?

Nero Burning Rom

or foobar2000

Hi,


I think it could be great to add your comments with this thread. To avoid some extras questions.

If you can't download the zipfile from the nero-server with ip 82.98.209.139 it's because the ip is in the InSoft range of some kind of IP-filter. Turn it off.

hi..........
i m not able to download this Nero Digital Audio Reference Quality MPEG-4 & 3GPP Audio Codec.
it is free for download.
can any one download it for me and send it to me.
my email address is ruchi.sharma@patni.com
i m new for audio.

thanks n regards
ruchi



how??? can u tell me??

emphasis in quotation is mine.
My comment only apply for 2pass encoding mode. With ABR/CBR/VBR using short samples isn't a problem simply because the encoding performance is not dependant to what comes first and what comes next to the tested data.

never understud why someone would like to embeb a gfx inside a music file, why don't you just leave it at the music root folder?

Digital Audio Players (like iPod for MP4 files) are working like that.

Some devices like iPods allow the display of album artwork on the screen, and this the image must be imbedded in the file.

Weeeh for tyranny of the minority and forcing developer-settings on the mainstream.

There is a much more easy solution to this: Developer-builds for, well, developers(testers).

i understand ... so this way you can listen at the song, while looking at the screen at a still image of the album art ... cool!

I think the channels thing should really be handled by something else, and the same for the invert thing.

Actually, I'm pretty sure that all the tags are stripped before an aac file is put on an ipod. The metadata and images are stored seperatly. So any player that supports an ipod and folder.jpg should be able to apply this style when transfering songs.

what about PNS.
c'mon...it can't hurt.

Hi, I have the same problem :

I have WinMe. Is any way to launch it on this system?

No,

This AAC encoder does not run on Win9x systems (Windows 95, Windows 98, Windows ME) as they do not have full Unicode support, which is what this encoder requires.

How about adding support for Unicows?

No the tags are not stripped on transfer to the iPod. The file names are changed but the files themselves are not.

Hi and thanks for this great encoder.

I've encoded a few albums and wondered why my average bitrates where a lot higher than those reported by other users (i.e. -q 0.425 results in about 128 kbit/s).

I realised that I have used the -lc switch (which I entered to be sure of iPod-compatability, not knowing what the HE-threshold was). I assumed that the switch would make no difference for higher quality levels.

I tested without the -lc switch now and the resulting file was a lot smaller.

My test gave an average bit rate of 179 kbit/s encoding with -q 0.425 -lc, and 133 kbit/s encoding with -0.425. Both the files where LC.

Is there a reason for this? Am I doing anything wrong?

The files where transcoded from flac with foobar 2000. The full command lines are as following:
-q 0.425 -lc -ignorelength -if - -of %d
-q 0.425 -ignorelength -if - -of %d

Normal and expected. If you force a quality profile, the -q scale changes.

Consider the following:

-q 0
-q 0 -lc
-q 1 -hev2

I don't see any way to make it behave consistently. Probably, the most reasonable thing to do would be to make the average bitrate equal, but of course that means that -q 0 -lc is very different quality from -q 0 -hev2.

Thank you for your answer.

Yes, I realize that the quality scale changes when a quality profile is enforced as it is in your examples. However, the encoder choses LC for -q 0.425, therefore my guess was that adding the -lc switch when encoding with -q 0.425 wouldn't change the results.

What I mean is that the -lc swith is just redundant for -q 0.425 and not enforcing the quality profile.


That would be quite strange since the -q mode aims for quality and not bitrate. These switches would result in one LC file and on HEv2 file, which of course should have different bit rates when aiming for same quality.

But why should two LC files have different bit rates when aiming for the same quality?

But I guess my logic is somehow flawed, will remove the -lc. Thanks again.

But will -q .425 with no other params always give me a LC file?

...to briefly change the subject, I've encoded my music from FLAC to AAC using Foobar and the neroAacEnc_sse2.exe encoder using the following parameters:

-ignorelength -q 0.6 -if - -of %d

When listening to softer pieces on my iPod Shuffle, every 15-30 seconds I hear very brief but distinct dropouts. Playback via iTunes on my PC sounds fine.

Has anyone with a Shuffle heard the same?

Sure, and if you are pre-processing your source, the most versatile tool is SoX. ("Invert" was basically added as an afterthought; I finished typing "Channels" and said to myself, "Well, if one went that far, how hard would it be to add this?")

What really puzzles me about the way the new encoder handles channels is that even if I feed it a MONO *.wav, the output *.m4a has both a LEFT and a RIGHT channel. I've not found a way to force this encoder to produce a single-channel *.m4a, despite the fact that both iTunes and Winamp will do so with the proper instructions.

For an overly-simplistic example of why I think this would be a good idea, if a user were encoding streamable content (-cbr), and had two stations (one mono, and the other stereo), intuition says "halve the bitrate for the mono station since you are only encoding one channel, and it will save bandwidth."

But in practice, at the moment, halving the bitrate for the mono station results in a lower-bitrate dual-mono channel, which (depending on how well the encoder recognizes that the actual content is monaural) may or may not sound as good.

Almost every other lossy encoder I've ever used had some sort of mono mode. At the very least, could we have a program smart enough to say "Hey, there's only ONE channel on this source! I'll just use one channel when I encode it, instead of two."

Cheers,
- M.