Mono channels should be encoded as mono.

They are just decoded as stereo.

Well, tested with a 2G iPod and it's fine. Must be a Shuffle thing. Sorry to interrupt.

Ivan, when I play a "mono" iTunes encode in Winamp (using the AudioCoding "MP4 input plugin for Winamp" from RareWares) it shows up as one channel. But when I play a "mono" file from your encoder it shows up as two channels.

A single-channel *.wav was used to encode each *.m4a file. This isn't a case of CD-mono content (dual channels, even if the content is the same) being mistaken for subtle stereo; it appears the encoder is taking a single-channel source and storing it as two channels within the encoded file, even though that is not required by the MPEG-4 spec!

Unless I've horribly misunderstood the purpose of a mono channel, that just doesn't make any sense.

- M.

No, what Ivan said is exactly correct:

The file is mono, but it will be decoded as stereo.

The reason for this is that a mono file *may* in fact be a parametric stereo file (the decoder can't know for sure), so a mono file could possibly suddenly transform into a stereo file in the middle of decoding. For this reason, the FAAD2 decoder, and everything based on it, will decode them always as stereo, even if they are mono.




Yes, unless it turns out that some improvement to SBR makes it useful for higher bitrates, or we manage to improve quality so much that you can get -q 0.425 quality at significantly lower bitrates.

But for the current encoder, it's always LC.

Hmm, this is odd. When I use only the "-q 0.4" option, it produces a LC-AAC file at ~130kbps. However, when the "-lc" option is added, the average bitrate jumps about 60kbps.

Okay, what you've said makes sense. iTunes "mono" files are *not* be parametric stereo, since they show up as mono regardless of how they are decoded, and are strictly channel-limited. You've basically chosen (for reasons of quality) to allow the encoder to parametrically determine the necessary separation, based on content. (Phrased redundantly, but you know what I mean.)

But to draw to the logical conclusion: If a Nero-codec "mono" file is parametric stereo, and -cbr 128000 (when used for streaming a stereo station) determines one set of frequency cutoff values and dynamic assumptions, does -cbr 64000 dynamically adjust those cutoffs and assumptions based on monaural content? Or will the apparent quality of the -cbr 64000 mono stream be significantly lower than its stereo -cbr 128000 counterpart?

- M.

garf. why are you avoiding my question?

why not give me explanation of why PNS would be a "bad" idea.

I already explained this like 2 or 3 posts before yours

http://www.hydrogenaudio.org/forums/index....ndpost&p=390899



I already answered your question:

http://www.hydrogenaudio.org/forums/index....ndpost&p=390517





You're still forcing it to a specific mode. If you do this, you end up on a different scale than with normal -q.

I thought some time about "fixing" this, but as explained in my previous answer, I don't think it's possible in general so I didn't bother too much. Don't force profiles unless you absolutely need to.

If you look at this graph for 6 channel encoding:

http://img183.imageshack.us/my.php?image=n...052006gerad.png

You can see what happens. Note how the two parts of VBR(free) are parellel with respenctive parts of LC(force) and HE(force). Also note that if there wasn't a remapping going on, you would't be able to make 300kbps encodes, because the encoder would jump from 200 to 400kbps.




No, no, no, I absolutely did not say this anywhere. I didn't even mention the word encoder.

Encoding a mono file gives you a mono file.

Decoding a mono file can give you a stereo file. (depends on the decoder)

If it's still not clear now, I don't know how else to explain it.

Yes it's possible. E-mail me, I teach you how to make it run... It's really simple.
NeroAACDec/Enc/Enc_sse2 runs under Win9x/Me without any problems.

Why don't you just share your knoledge here?

I just noticed that latest Foobar (9.2 beta 2) has a built-in converter option for "MP4 Nero" that includes a button to download this new encoder.

For this to work, what folder does the encoder have to be in?

And how does one specify the "SSE2" version?

Thanks.

Has anyone managed to make this work under Virtual PC? It just crashes for me immediately after displaying the copyright and build info.

So is there a quality cut-off point where LC isn't used? I just want to make sure to get the same quality LC file with a lower bitrate (by NOT using the -lc switch or any quality profile switch). Don't want to end up encoding my collection and then find out that my iPod can't play the files because they ended being encoded to HE or HEv2.

Maybe the -lc switch should only "activate" if neroenc decides that the file will be encoded using HE or HEv2? Considering that -lc gives higher bitrates for the same quality LC file.

PNS is an encoder internal?

then how come it is enabled in the GUI on NERO 7.2?

this does not seem like it should be some super top secret option, all i and many more ask for it a more decent lowpass for this encoder, and PNS can help this.

please take this into consideration when coding the next build, thanks.

Just take the _sse2 part out of the filename.

Well... Only one thing is really needed - emulation of CreateFileW function...
Like this:
-----------
char szName[MAX_PATH];
WideCharToMultiByte(GetACP(),CP_ACP,lpFileName,-1,szName,1023,NULL,NULL);
return CreateFile(szName,dwDesiredAccess,dwShareMode,lpSecurityAttributes,dwCreationDisposition,dwFlagsAndA
ttributes,hTemplateFile);
------------
(Other ~7 W-function... just ignore it) You need create dll and force encoder to use it instead of kernel32.dll.. It's all, any average programmer can do it.
def-file must contains other 84 kernel functions used by encoder. (Implementation needed only for CreateFileW)
It's works... and works about 10% faster under W9x compared to Win2k... I don't know why... and don't want to know I'm compared results of W9x&W2k ecoding procceses... and it's match within round errors. And _SSE2 version match perfectly.

Another faux pas in the same thread!

But I'm still curious (considering that it is a quality-based system), why would adding the -lc command make the encoder think that it needs ~60 more kbps to achieve the same "quality" (even though everything else is the same)? And though I haven't done any testing to prove it, it's doubtful that a ~54kbps -q 0.4 -hev2 file is of equal quality to a ~185kbps -q 0.4 -lc file.

So (I think I finally understand this ) the -q # setting when used with the profile switches isn't based on absolute quality, but rather relative quality for each specific profile. -q 0.0 is the lowest quality that its respective profile is most optimal for, and -q 1.0 is the highest quality that its optimal for.

If I understand it correctly the -lc switch does not only give a higher bit rate but also higher quality (different quality scales are used). This should only be true for q values higher than the value where the encoder choses LC by itself.

My encodes seems to indicate that -q 0.31 -lc roughly equals -q 0.425.

its a different scale, thats it, i guess there is:

1. one scale for all (when just doing -q x.x) - that includes he, hev2, lc
2. 2nd scale for forced he
3. 3rd scale for forced hev2
4. 4th scale for forced lc

this 4 scales dont have any quality connections between them.

---
so 4 scales depending on the forced settings, hopefully devs can confirm or deny this?

If the meaning of the -q quality level changes whether or not -lc is used it really says quality level is not the only target but considerations about bit rate drop in as well.
This has always been my suspicion with vbr mode of many encoders, but in principal shouldn't be like that: quality is quality, and bitrate is bitrate, and bitrate oriented operation modes are available anyway.

A direct consequence is for instance my own little listening test with -lc has turned out worthless as I had in mind those average bitrates given at the table in this thread or the settings thread. This also shows information about this encoder can lead to a lot of confusion due to this concept. BTW: is there a corresponding -lc table?

This problematic meaning of 'quality mode' hurts this encoder more than other ones as the quality level of other encoders does not depend on further settings. With AAC however chosing the profile is essential as for targeting at playing systems.

In this sense a quality mode which choses the profile automatically (and when doing so can change choosing characteristics from version to version) is very questionable to me. And it looks like this is one of the major targets of current Nero AAC development: take a quality level as input and let the encoder choose all the other details like profile, PNS, etc.
While this is a good thing in theory in praxis we have to take into account what the target player is able to do.

I'd rather prefer to

• require a profile as an input parameter. If it's missing, LC-AAC is defaulted.
• give a quality level as an input parameter which tries to achieve a quality level in an absolute sense. This might be difficult to achieve in a general sense, but maybe a good-enough simplification is to do so for certain important quality values. Consistency of quality level throughout various versions is most important within the same profile, and should be roughly the same across the different profiles.
  As an alternative to quality mode, the bitrate oriented modes should also be available.
• have a restricted set of additional parameters available for user choice (PNS for instance). This sure is a sensible thing, but I guess the current not wanting at all to do so results from the current motivation for this problematic one and only quality level as input and letting the encoder decide on everything else.

Already answered. Anywhere. If foobar can't find the EXE where the preset says it is it will open a dialogue and ask you to specify the directory that contains the EXE.

Edit the preset and change the dropdown to "Custom". You can then change the filename from neroAacEnc.exe to neroAacEnc_sse2.exe.

While you are doing this you may as well just use the dialogue to point to your EXE, negating the first question/answer.

A truly horrible mistake that I hope will be fixed in the next version.




Wrong.



No.



No. Feel free to generate one.



Completely wrong.


The only thing I agree with is that device compatibility plays an issue. Which is why the next version will have a set of 4 simple compatibility profiles. If it depends on me, the possibility for the user to select the encoding mode (LC/HE) also goes away at that point.

This behaviour is actually a requirement in the MPEG-4 standard for PS capable decoders on mono files without explicit signalling of NO PS. Having said that, explicit signalling could be added to one of the next versions, we are considering this. However, "FAAD2, and everything based on it," does not have support for this explicit signalling.

As explained a few times already: forcing the encoder mode puts you on a different quality scale. How to achieve the same quality as at -q 0.5 -lc when switching to hev2? What's the equivalent LC quality for -q 0 -hev2? I don't think it's possible to make a scale that is and always consistent, and offers all quality/bitrate/mode options, even if it's possible to hack around the "-q 0.425 -lc" vs "-q 0.425" issue. So, I'd rather spend time to remove the need to use the "-lc/-he/-hev2" overrides instead.



Somewhat, but not entirely. -q is literally the switch that selects how "picky" or "sensitive" the psymodel is (are you hearing me, "-q is not quality mode and considers bitrate" trolls?). You can observe this for example by trying -q 1 -hev2. The encoder will just throw its hands in the air since it has no way to please the high demands when it has to use SBR and PS. Selecting for example -q 0.15 -lc, and then switching to -q 0.15 -he, will reduce in a large bitrate drop because the psymodel is only having to consider half of the spectrum anymore (the rest belongs to SBR).

Hence you get different quality scales. This is evil, because

1. It's confusing (that much is clear )
2. It's inconsistent with the expectation that same -q = same quality. (From the point of the psymodel it is true, but it isn't always seeing the entire spectrum.)

So, if you don't force the encoder to a specific mode, we internally remap everything to compensate for what the psymodel can't see, to present you with a single, fluid, consistent and correct quality scale which has optimal switching decisions between the modes and behaves like you'd expect.

If you do force the encoder to a specific mode, thereby indicating that you believe you are capable of handling the starship, be sure to understand that the Warp scale is not linear and that travelling at faster than light speeds brings unexpected results.

I'm wondering if I'm doing any good with these explanations, since it seems the more we explain, the more people keep asking the same thing over and over, or come up with totally weird theories which are entirely and completely wrong.

So, I think I'm going to have a bet with Ivan when the first person to explain to us that our encoder has a problem with it's dilithium crystals is going to show up.

"I'm giving it all she's got, Captain... but if I push her past -q 0.5, she's gonna overcompensate for too many command line switches..."

Does that make me the winner of the "Spot The Dilithium Crystal Encoder" contest?

Sorry, couldn't resist. Again, great work guys, I finally finished my 100 DVD FLAC > Nero mp4 conversion, boy that took a few days but it's nice to have a freshly formatted iPod with 9250+ songs on it all done nice and clean with the new encoder. And no, I won't be redoing it again just because an improved encoder might come out.

"It sounds fine to me as is, and that's all that matters."

Thanks...
bb

It is official,

Next revision of Nero AAC Encoder will in fact have explicit SBR signalling in a backwards compatible way.
Hopefully this will solve "mono decoded as stereo" problems, and also problems on some 3G phones not "seeing" SBR and decoding just LC.

As far as quality scale goes - we will consider the input from the communities and see if we can improve it even more - we will keep our HA friends posted here on any changes.

I'm in the process of completing the finishing touches on my 50 DVD (I'm catching up) FLAC > Nero MP4 conversion, and I've gotta say that I'm in complete agreement with you bb. It's going to take a fairly significant improvement in the encoder to make me go through that again.

Cheers again Garf, Ivan and team.

My guess is that it is there because of potential compatibility issues with some devices.

@Nero team: why not having a "portable device encoding wizzard", where the user first selects the device brand, then the model. This way, average Joe would not have to worry about selecting between mpeg2/4, LC/HE, PNS and the likes. (this could even produce old mp3 when selecting a legacy device)

>>So, I'd rather spend time to remove the need to use the "-lc/-he/-hev2" overrides instead.
Hmmm... Just noticed:
If I need 64Kbit LC file, if SBR will be automatically used, then I will receive shitty 11KHz sound when playing on lc only capable device, while it would be 16Khz "normal" sound...
So, disabling this switch can raise some problems, I think.
Am I right ?

Please read the other posts. I stated that I'd rather replace those swithes by a "profile" system.

And, Ivan, please, make possible other input files, not only WAV files. I can't convert my MP2, AC3 and other audio files to newest Nero AAC encoder.

I think this a truly incredibly outstanding and excellent idea, I could not agree more, and I think this needs to be implemented as soon as possible.

Now, if only I had one of each of the popular music player devices handy here, I could test them and implement this very easily.

Boss, boss, are you reading this?

huh ? you can do that easily with foobar and the right plugins.

@Kostarum Rex Persia,

I think I already replied to you on this question on some other forum.

No, we (Nero) cannot do that, because:

a) In that case product cannot be free anymore (many codecs, unlike AAC, require per-unit royalties to be paid and have no options of single annual payments)

b) This is an encoding, not a transcoding tool


And, as others pointed out - this makes no difference, as there are already bunch of tools that could use this encoder to do exactly what you want.

I'm just released my MPWGUI_v2.1 english version with iTunes/NeroAACEnc/FAAC support, you can convert MP2/AC3... and more with it: http://www.hydrogenaudio.org/forums/index....showtopic=44473
Read readme.txt carefully! It's really simple GUI... but it have unique feature - it can save your time.
Freeware.

I'll put a hardware request

sorry if this is a repost, simple gui for neroaacenc
credits to imcold

what, the omision of PNS will be fixed and available?

No, the fact that an encoder internal is exposed in the GUI.

Just where did you see that "internal" - as far as I know Nero 7.2 has a simple GUI with a slider, not a PNS checkbox.

If you got the old dialog, it must be that you have aac.dll installed still.

--

This does not apply to Recode, which is still using the old encoder.

Of course this suits perfectly your 'do absolutely everything internally' strategy.

But do you really want to do that? You have to update your encoder often, have to consider the specific side conditions of any device indidually. As I'm a developer myself I would never go into these dependencies. I would like to spent my time in a more productive way.
At the moment this might be manageable as there are not very many devices out there supporting AAC.
But this can change, and maybe is about to change for mobile phones already.

Moreover tailoring the encoded file to a specific device means restricted application for the encoded file.
The encoded files become at least potentially device-dependent.

Sorry, I'm thankful for your free encoder, but this is one of the worst ideas I've read in recent times.

PNS will be re-enabled in encoder soon, but not in the way some people proposed here.

There will be an option to disable PNS by selecting a special compatibilioty profile.

In other cases, PNS will be employed only where it brings benefits, and this is the job of encoder's psychoacoustic model to find out.

My best guess is that we will probably enable usage of PNS at bit rates <=80 kbps stereo for LC-AAC.

This will improve lowpass as well.

Oh come on, dude. Audio encoders take WAV files as input. Read around a bit, then come back.

Sorry. Didn't catch that.

Yes, it would be easy for user, but could be very complicated way for developer.
There are hundreds (at least) mobile players available worldwide and a new players became available every day/week. How could it be supported ?

well, there may be hundreds of devices, but they all support a common format (mostly). For example, older nokia phones support AAC-LC (64 quality would be fine), newer ones AAC+v2 (48 quality would do). iPods support AAC-LC. 128 quality would do. you just need a .txt file (to be read by NeroENC) with models/prefered encoding method listed, and this could be updated once a month or whatever.

(before anyone says "I'm not putting rubbishy 128kps on my iPod!!" well, if you're that picky about your music, then you're not the sort of person that would be using presets anyway)

As someone who regularly has to help out friends with putting music onto iPods/PVPs/phones, I would vote for this feature.

Every idea which ends up me with having a few hundred portable devices to play with is by definition brilliant

But yeah, it's not a very maintainable strategy.

At least for the "Nero Digital" players, this should be easy.
If I remember well, there was a list of drives able to change their speed on the cd-speed website. Situation was the same: hundred of potential devices, but it existed.

@ garf & ivan:

Obviously your strategy is to keep details away from the user and let the encoder decide to the utmost extent.
Taking this as a preposition my proposal is:

• Provide only the quality mode which is provided right now if no profile is given
• Give a simple advice for novice users like 'don't use q<0.31 if you're out for best compatibility'
• Define publicly the exact q-borders at which you switch to specific features (i.e. q>=0.31 yields LC_AAC).
• Preserve these switching limits as a function of the q-value definitely in future versions. In case it's necessary rather change the meaning of a q-level qualitywise a bit.
• Provide documentation for the features that are switched to at these boundary q-values.
  Only those internals should be published that are important to the user, especially with respect to usability on devices.

I understand your request for features, but we won't put features that could damage the encodings, and/or lead people to possible confusion.

With fixed quality params, we can be sure that every Nero AAC encoding that is produced is made with optimal quality for a given bit-rate.

Of course we will add features, and I promise some very very cool developments this year

Wasn't it easy to retain the quality scale ( q 0 , bad quality, q 1 best quality it can give ), and then let the user specify what he *doesn't* want?

Example :

By default, the encoder chooses, but the user has the option to disable the use of some of the internals, in order to maintain compatibility.

Examples:
player doesn't support HE-AAC , then : encode -q 0.3 --no-heaac

player support HE-AAC, but not PS, then : encode -q 0.2 --no-ps

Of course, this also would apply to cbr and abr (encoder choosing the best it knows)

This will even ease the profile system that you're describing.

<joke>
this would only mean that there wouldn't be 128kbps HE-AAC radio streams...
</joke>