Let me introduse my frontend for Ahead Nero AAC Encoder. I's command line frontend and work directly with AACENC32.DLL (need only AACEN32.DLL & NeroIPP.DLL).

Ahead AAC Encoder Frontend by LoggerSoft v0.71 (238 Kb)

Note that aacenc32.dll does not provide a direct resampling, so using any illegal bit-rate and sampling-rate combination could result either in crash, invalid file or impaired audio quality (or all three)

Into problems, which solves AACENC32.EXE (my frontend), does not enter resampling. Value of frequency of digitization from initial .WAV-file is checked on an admissibility and will be worn out in ADTS heading of the each frame, and at creation of a stream by function aacStreamOpen32, transferred it in 3-rd parameter.
Similarly works NENCODE.EXE-> AAC.DLL-> AACENC32.DLL.
I have tested AACENC32.EXE on .WAV-files with various frequency of digitization and on different bitrates, resulting .AAC-files have turned out identical with .AAC-files created by NENCODE.EXE.

I release new version of my Ahead AAC Encoder Frontend v0.74.

Whats new:
* fixed bug with cuts frecuencies above 15500Hz. Now you may set lowpass filter by youself (new command line key -lowpass <freq> or -k keep all frecuencies, disable lowpass filter).
* supported PNS mode on low bitrates (-pns key).

Ahead AAC Encoder Frontend v0.74 (1 Mb)

Note - lowpass frequencies were pre-selected by listening tests.

By using your own cut-off frequencies you might make encoder work in suboptimal (non-tuned) mode, and thus having less quality.

To prevent this case, the lowpass fliter frequence selected automatic (if you don't set the -lowpass <freq> or -k key) by data from AAC.DLL 2.05.009.098.

Alexander,
Is there a way of disabling Nero LC AAC encoder to downsample input audio when low bitrates are targeted? For example, I would like to encode 44.1 kHz audio at 96 kbps without downsampling to 32 kHz (which encoder does by default).
Daniel

Where you encode .WAV file? In Nero Wave Editor, NENCode, in my frontend?

I have lead experiment:
1) Encode Sample.wav file (44.1kHz, 16bit, Stereo) in my encoder/fontend (aacenc32.exe -cbr 96 Sample.wav);
2) Decode Sample.aac in FreeAAC decoder (faad.exe Sample.aac or in WinAmp with in_mp4.dll);
3) Result: the decoded .WAV file was 44.1 kHz. Downsampling not present.

Sorry, I forgot to mention that I did not use your frontend but Nero 6.3.1.10.

However, I just tried your frontend and I see that Nero's aacenc32.dll does not downsample automaticaly, which is a pretty good thing. With your frontend I am able to encode some really crazy combinations of input sampling frequencies and output bitrates which I need for comparison purposes. Thanks!

Daniel

Alexander,

1. Nero gui supports bitrates 16, 20, 24, 28, 32, 40, etc... Why doesn't your front-end support very low bitrates? It supports 32 and above.

2. When I encode 16kHz stereo audio at (for example) 56 kbps using default settings, frontend says "lowpass filter 10500 Hz", which seams meaningless for this sampling rate. Who sets the default lowpass threashold frequency, your front-end or Nero?

3. I thing that encoder should issue an error or a worning when bitrate is too high for given sampling frequency. Instead it encodes to the highest bitrate alowed. This way I get 192 kbps for 16kHz stereo audio even though I asked 256 or 320 or higher. But this goes to Nero I think...

Daniel

edit: 3.

In new version (0.75) supports bitrate low than 32.


The lowpass threshold frequency set by values form pre-listen test table (it sets in AAC.DLL and similarly in my frontend) In AAC.DLL values from tables sets independently of sample rate, it’s not very well, I think . In new version I am fix this situation and use table of coefficients which multiply to (sample rate)/2 value.


It’s Nero Encoder problem, but I think not very seriously.

Thank you! If you want I may send you new version of my frontend by e-mail?

Alexander

Be carefull with the cut-off. If you cut at 15500 for fs=44100 to achieve transparency at 128 kbps, does it mean that you will cut at 31000 Hz for fs=88200 to achieve transparency at 256 kbps? I think not. Sole multiplication is simplification that won't do much good, it's much more complicated than that.

Daniel

For 256kbps (and above 256kbps) values of coefficient equally 1.0 => cut-off frequency equally 44100 for fs=88200 to achieve transparency.


I agree that it not an ideal variant. It would be the best way to have pre-listen tables of a cut-off frequency for each sample rate (or algorithm of an estimation of spectral structure of a signal), but in the Nero coder there is only one table for everything, here it (from AAC.DLL):
Bitrate (kbps) | Cut-off frequence (Hz)
448 | 22050
388 | 22050
320 | 22050
256 | 22050
224 | 18250
192 | 18250
160 | 17250
128 | 15750
112 | 15000
96 | 14500
80 | 13500
64 | 12500
56 | 10500
48 | 8500
40 | 7500
32 | 6000
28 | 5000
24 | 4500
20 | 4000
16 | 3400

So, that my table of coefficients:
Bitrate (kbps) | Coefficient
448 | 1.0
388 | 1.0
320 | 1.0
256 | 1.0
224 | 0.8277
192 | 0.8277
160 | 0.78232
128 | 0.7143
112 | 0.6803
96 | 0.6576
80 | 0.61225
64 | 0.5669
56 | 0.4762
48 | 0.3855
40 | 0.34014
32 | 0.27211
28 | 0.2268
24 | 0.2041
20 | 0.18141
16 | 0.1542

cut-off=(samle rate/2)*coef_table[bitrate index];

This most simple that has occurred to me, replacement of absolute values to relative, probably this disputable decision, but always it is possible to correct value of a cut-off by key -lowpass <freq> at own discretion. If you have the best ideas, please, share...

Well, the Nero default table seems quite good to me (even if I would limit upper range to 20kHz instead of 22kHz).

Why don't you use the default table?
You just have to check it against your input sampling freq:

lowpass = min( table(target_bitrate), (input_sampling_freq / 2));

After giving it a bit more thought - for now I would also go with Nero's default table (with no multiplication). Also, like Gabriel said, limit the cut-off to f_sampling/2 just to make it look nicer.

I'll think a bit more about this cause I'm still not quite sure if cut-off should be sampling frequency dependent or not.

Daniel

Well, cut-off should also depend on the number of input channels.
In lame if you use mono instead of stereo, lowpass is increased by a 1.6 factor.

Let's say that AAC stereo for 44100 sampling frequency is transparent at 128 kbps, having in mind the cut-off at 15500 Hz. Without the cut-off we would have 30% more data, so the transparency level would shift to approximately 180 kbps.

What would be the transparency level for mono AAC and where would be the cut-off frequency?

Without any cut-off, the transparency would be at (180/2)/joint_stereo_factor. If we predict that joint stereo coding saves us approximately 40% of the bitrate for stereo signal, than

joint_stereo_factor = 0.6

and mono transparency is achieved at

180/2/0.6=150 kbps (without high frequency cut-off).

If we cut at 15500 than we save 30% and transparency for mono goes down to
150*(15500/22050)=105 kbps.


You are saying that Lame cut-off is increased by a factor of 1.6 for mono, but what are the bitrates. I'd use same cut-off (at 15500 Hz) for 128 kbps/stereo and for 105 kbps/mono. Does this make sense?

Daniel

We are first considering bitrate or vbr level, then we determine (based on tables) the default lowpass for this bitrate/level.
Then if we are encoding to mono, the lowpass is multiplicated by a 1.6 factor, but without affecting bitrate or vbr level.
Then a "safe check" is done, by comparing the value against input_samplefreq/2 (the minimum of both is chosen).

Considering that a 22kHz cut-off is providing 30% more data than a 15.5kHz cut-off will not work. It is perhaps 30% more input data, but those additionnal frequencies have different masking properties than your lower freqs (mainly some higher ATH values).

Let's say Lame encodes stereo signal, bitrate is 128 stereo and cut-off is 15500. For mono and same bitrate Lame would use cut-off at 15500*1.6=24880, in fact 22050 - no cut-off used. Is that right?


I went for some kind of a worst case. What do you say would be the saving in bitrate cuting this 30% frequencies off since they are heavily masked anyway? 15 to 20%?

Yes, except the fact that we are limiting lowpass to 20.1kHz in every case, as we are not encoding for bats.
But you can check it at 64kbps: stereo will have about 11kHz but adding -m m will increase lowpass to about 17kHz.


For AAC probably. But anyway I think that basing your decision on the built-in tables, adsjuting according to number of channels and checking against input_freq/2 and against an high limit should provide reasonable parameters.

How are you supposed to use this thing? Anyone have a batch file?

Sure, that method would do the job, like it does for Lame and other (mp3 and non-mp3) encoders. But the problem with AAC is huge span of sampling frequencies and target bitrates. I am looking for a complete solution for the cut-off "problem".

For example... we concluded that cut-off at 15500 removes 30% of data for fs=44100, and that coresponding gain in bitrate is around 20%. Take a look at the same situation for extremely high and extremely low sampling rates.

fs=88200: if cut-off is also at 15500 (why wouldn't it be!?), than cut-off removes (15500/44100 = 0.35) 65% of data - what's the bitrate gain in this case?

fs=8000: if cut-off is at 3000, than the cut-off removes (3000/4000 = 0,75) 25% of data - what's the bitrate gain in this case? Stereo and mono cases further complicate things...

Daniel

Maybe the cut-off subject deserves a separate thread...

But why do you want to know how much data the lowpass removed?
What is important is what frequency range the encoder can deal with at a specific bitrate/vbr level.
The encoder doesn't care about how much you removed. If you try to compute how much bitrate gain you are achieving based on how much freqs you removed, it will be quite hard.

The solution would be to have a table with frequency bands and psychoacoustical weights, like this one:

1000-2000Hz: 50
....
15000-18000Hz: 6
...
30kHz-40kHz: 0.00000001

But what would be the purpose?

What I am trying to do is to derive all cut-offs and transparency levels from the only known point that I can hold on to, and that is the transparency level for fs=44100-stereo-cutoff=15500, which is 128 kbps. However, since this work becomes too complicated I might just use what you suggested...

How are the cut-off tables used ba lame, nero, etc, derived? Listening tests? Also, from where does the 1.6 mono multiplication factor come from in lame?


Just one more question: if stereo 44100 is transparent at 128 with cut-off at 15500, where is the transparency level for mono 44100 also cut at 15500 and what logic stands behind that number?

Listening tests.
Tables can not be directly exchanged between encoders because they are based on the compressor efficiency.


I am sorry but I do not really understand your question.

Nothing special, I just asked what bitrate would it take to transparently encode mono signal since for stereo AAC achieves transparency at 128 kbps.

Well, if we consider a 1.6 (this is just an educated guess) factor between mono and joint stereo, you would have:

128/1.6 = 80

Same as eagleray............how does this thing work?

auldyin

Now I don't understand what you mean by "factor between mono and joint stereo".
I see it this way: mono is just half of the stereo but without joint stereo usage.

stereo with joint stereo - 128 kbps
stereo without joint stereo - 128 * 1.6 = 204 kbps
mono 204/2 = 102 kbps

I don't see the logic behind 128/1.6 = 80.

I would also like to know how to use this.

TIA

This is because I am considering that with mp3, mono is decreasing entropy by 1.6 compared to joint stereo.
Of course stereo WITHOUT joint stereo (but that would be inoptimal) has on average 2 times the mono entropy.

For AAC, as the joint stereo scheme is more efficient, using mono is probably decreasing entropy by only 1.5 compared to joint stereo.

If we keep the 1.6 (and not 1.5) factor, to convert between joint stereo and stereo we have:

stereo with joint stereo - 128 kbps
mono 128/1.6 = 80
stereo without joint stereo - 80 * 2 = 160kbps

With the 1.5 factor:

stereo with joint stereo - 128 kbps
mono 128/1.8 = 85
stereo without joint stereo - 80 * 2 = 170kbps

This means that for AAC, we can guess that a 128kbps joint stereo file would need 170kbps without using joint stereo, if we keep every other parameter identical.

Use a command something like this: aacenc32 -vbr normal -k infile outfile
Or type aacenc32 -help for complete usage information!

Can you (directly) compare mono (entropy) with joint stereo (entropy)? I would compare mono only to single stereo channel without joint stereo information.

That is, you first have two separate channels L and R each with its LE and RE entropy. After applying joint stereo you again have two entropies LEJ and REJ, and hopefully LEJ+REJ < LE+RE and mostly for AAC (LE+RE)/(LEJ+REJ)=1.6.

In our case (LE+RE)/(LEJ+REJ)=1.6
LE+RE = 200 (approx)
LEJ+REJ = 128

and
ME = (LE+RE)/2 = 100
(in fact ME=LE or ME=RE so ME=~100).

I don't see the conection between mono and joint stereo but only between mono and one stereo channel without joint stereo. And you say
"mono 128/1.6 = 80"
which, according to legend below is equivalent to
ME=(LEJ+REJ)/1.6 = 80.

To conclude,
is this right
(LE+RE)/(LEJ+REJ)=1.6
or is this right
(LEJ+REJ)/ME=1.6
?

Legend:
L = left
R = right
E = entorpy
J = joint
M = mono

Well, stereo (without joint) obviously needs twice the mono bitrate.
Joint stereo needs 1.6*mono bitrate.

After, you can twist those numbers the way you want...

Using your legend, you would have:
(LEJ+REJ)=ME*1.6
ie (LEJ+REJ)/ME=1.6

I definitelly don't agree, there is no logic explanation behind that.


First you say that 1.6 is a factor "to convert between joint stereo and stereo" and then you use that factor to convert between joint stereo and mono (128/1.6 = 80). And you end up with (stereo without joint stereo)/(stereo with joint stereo) = 160/128 (20% difference). It turns out that joint stereo saves only 20% of the bitrate (it follows from the quote above).

This is wrong.

When we'll try v.075? Realy in need of 16kbps encoding...

My mistake: the 1.6 factor is to convert between joint stereo and mono.

And yes, joint stereo (mid/side) is saving about 20% compared to plain stereo with mp3. With AAC it is probably a little higher (something like 25-30% savings).

A 20% saving seems coherent to me. This is already a huge saving.

Where is the latest version 0.75, i don"t see any download link...

Some problems with hosting today-tomorrow I shall put it, I can send any interested on e-mail...

I guess you use it as the other aac encoders, together with "tg.exe" to write the tags... Look at http://www.hydrogenaudio.org/forums/index....howtopic=17013# for instructions. On rarewares you'll find a bundle of this frontend and tg.exe.


edit: hmm, the above is not quite right. Since this app produces .aac files I guess you have to use something like mareo ( http://mareo.monkeydev.org/ ) to be able to execute all necessary commands for tagging the files. I couldn't write in all the commands in EAC, because it didn't allow that many characters!

And there's one setting I miss in this frontend: mono. I use it a lot for audiobooks.

Released new version of my frontend (v0.75.038).

Whats new:
* supported bitrates below 32kbps
* corrected algorithm of selecting cut-off value

Thanks all who has helped me to find and correct these mistakes!

Gabriel, things are clear now.

Throughout my posts I used 1.6 as a factor between "encoding with joint stereo" and "encoding without joint stereo", that is 40% gain with joint stereo:
with joint stereo 128
without joint stereo 204
(204 - 40%=128)

That led me to conclusion that mono takes 102 kbps (half of the stereo without joint stereo 204/2). Formulas are ok, but 1.6 factor seams wrong.

As you say, I should take 20% saving with joint stereo compared to no joint stereo. Than I would have
160 - 20% = 128
so mono would take 160/2 = 80 kbps.

That is exactly the same math as I used before but with 20% gain, not 40%, between stereo and joint stereo.

This is where we get YOUR factor that calculates mono from joint stereo as mono=joint stereo/1.6

1.6=128/80

So your mistake is that you replied to my posts without paying attention to what I wanted to say. Otherwise you would have warned me that 40% (factor 1.6) is a little bit to much:

Otherwise than that, we talked about the same thing: you calculated mono bitrate as
128/1.6=80
and I calculated it as
(128+20%)/2=80
but I got much higher numbers because I used 40%
(128+40%)/2=102

Daniel

I can't get the low-pass to work properly.

The following command lines:

aacenc32 -cbr 128 -lowpass 20000 c:\cast.wav c:\cast20000.aac
aacenc32 -cbr 128 -lowpass 4000 c:\cast.wav c:\cast04000.aac
aacenc32 -cbr 128 -lowpass 8000 c:\cast.wav c:\cast08000.aac

...all produce the same output, low-passed at around 16000 Hz.

Am I doing something wrong?

Daniel

The command line is set truly, but, I am afraid, the problem consists in work of the coder (aacenc32.dll). Cut-off frequency value is transferred one of parameters of function of creation of a stream (aacStreamCreate32), that then the coder does with this value I am don't known...

But the designated problem really exists, and in the following version I plan to add the FIR-filter, for preprocessing a signal...

Thanks Aleksander.
I think it would be better to resolve this with Nero developers first, before you start with your own preprocessing implementation.

Daniel

[/quote]
Thanks Aleksander.
I think it would be better to resolve this with Nero developers first, before you start with your own preprocessing implementation.

Daniel
[/quote]

I understand your doubts , but the FIR-filter the best of the thought up filters, it is not dangerous to a signal since does not bring phase/frequency distortions.

For realization of the filter I am going to use Intel® Integrated Performance Primitives Library - professional library with many functions to work with a signals and images, written by professionals and optimized for Intel CPU Architecture. Developers aacenc32.dll also use functions of this library (NeroIPP.dll a part of library). For realization of the FIR-filter in this library is involved more 400Kb a code!

In any case it will be optionally an opportunity which it will be always possible to disable, decide to use her whether or not to you...

This is (IIRC) because it maps all FIR filters to equivalent FFT filters, and hence it has to include optimized FFT code for all Intel processors.



You mean "pessimized for AMD Architecture". When it detects a non-Intel processor it will actually switch to a low speed version (you can work around this).

I wouldn't say "low speed" because the generic version of IPP is also optimized - the difference is that it doesn't target any specific processor family.

Daniel

The only use of doing that switch on a non-Intel cpu is to lower the speed. Many of the 'generic' implementations are not faster than what manual coding would produce.

Then to me it is not absolutely clear for what convolution values by function ippsFIRGenLowpass_64f is generated?

And how function ippsFIR64f_Direct_32f_I can work with any number of samples, distinct from 256, 512, 1024, etc., necessary for FFT?

In the user's guide of library, there is a description of work of FIR-functions, there is told, that they work by a principle of convolution...

Where you get such information, you saw source code of IPP library?