Another flexible and extensible way of multi channel audio encoding using Avisynth.

The foobar2k v0.83 has been stable(in 6ch decoding & encoding) until nero released the nero 7 with different channel mapping(!) and realizing the next version of foobar has been in beta state very long. The videolan supports variety of formats of decoding but somewhat lacks in bitrates and formats for encoding. The ffdshow is only good for wav, ac3 and some few other format dsfilter encoders. And other tools require lots of broken steps and spaces until to get the final results, which is where we are asking desperately for good feature-rich flexible comprehensive integrated tools.

While reviewing the Avisynth section, thread by thread, I found there already have been good efforts and solutions for multichannel audio encoding for variety of effects and formats which only requires some integrations. The avs2wav is an avsynth client application which can toss multi channel WAV stream to other pipe capable encoders and the avisynth can perform some basic functionalities such as channel remapping and volume gaining. The avisynth can also read virtually all the formats through own plugins, dsfilters and graphedit files. For an example you need the graphedit .grf file to feed to serve the audio frame(dtsac3 source-> ffdshow to decode the dts signal in the dtswav). But for DTS files you cannot use the directshow filter directly or indirectly because of the wrong 48k sample rate information for 44.1k 6ch streams(don't know which tool is responsible), which require the NIC's plugin to be used. Also you may need a hexeditor to extract some blocks of preceding filler(after the header) to make the dtswav decoders(videolan, foobar, ffdshow) seek properly.

Below are the tools and scripts required for my tests encoding with correct channel mappings for different decoders and encoders. The 6ch ac3 speaker test file would be useful to identify the channels correctly by playing the avs script using MPC or any dsfilter enabled players. The encoders are in the same folder and the avsynth plugins are installed in its own plugin folder.
The launcher user interface(shell or gui) wouldn't be that hard to make, for those who transcode a lot, which is left for who actually need it while I am more focused on the existing and ever-growing features of avisynth.

My poor ears cannot find any differnce between vbr he q6 and q8(forced) of nero aacenc, except the result file size..
And the v7 aacenc32.dll is almost half the size of the latest v6 version, which looks like nero excluded all the test routines or actually OPTIMIZED it?(no it requires mfc71.dll).

I corrected some small mistypings and YES i've tested the aac(mp4,m4a) encoding with foo_naac.dll/foo_nero.dll/naac.exe and version 6/7 of aacenc32.dlls. It's easy to detect the difference although I am not sure which is causing it : foobar encloder plugins/cli or nero encoders. When I used the above described method, both v6 and v7 of nero encoder dlls reqired the same channel mappings. Maybe the foobar aac encode-interface routine is checking the nero dll version(i.e. to be v6)?

For your own prompt verification (I am off the test machine ), I think you can install the trial version on any computer and copy the aacenc32.dll from the program files nero common folder to the local script folder to override the existing nero dlls until you get the nero digital, recode 2 or any seperate version equivalent to v7.

I agreed the foobar2k v0.83 had been very satisfactory with the decent multi-channel aac encodings and I actually liked it(and it's gui!).
But I have no idea about the nero's strategy on the v7 aac encoder but am sure the channel mapping is different from the old stable setup and found there is an alternate & more flexible method as I described above.

Now the foobar2k beta 0.9 version stdinput plugin read the aac stream correctly and we may be having the correct channel mappings interface from the v0.9 regardless of the nero aac encoder version.
My feeling is that the foobar nero aac encoder interface is somewhat hardcoding the channel order somewhere inside. What I've been missing with the foobar is an explicit channel remapping plugin for the flexibility.

Also I think the stream passing between the dlls would be somewhat faster than between the processors through pipe, but not that significantly in processing and the lightweight feature seems to be more from the user interface than the actual processing. The above method uses only two EXEs and some DLLs, less than 3 maybe including the avisynth.dll itself, also it would be worthwhile to check how many dlls and memory are actually used with foobar encoding...

Let me remind you this is a thread about a new method practically providing a flexible environment for any type of source and target format with correct channel order, where includes the v7 nero aac encoder.

Actually, as for the foobar2k v0.83, they are all known issue, the only way to encode to nero 6ch aac without channel messup, as well as the only player with the messed up channel order in aac decoding.

The channel order FL_FR_C_LFE_SL_SR looks like for the WAV every decoder should line up to decode or play.
The order FR_C_FL_SR_LFE_SL stands for the remapping a=GetChannel(a,2,3,1,6,4,5) in above script and seems to be the actual channel order for AAC in both nero aac versions.

Then what would be the problem?
Why they needed a new nero7 encoder plugin for besweet?
I guess something hardcoded hidden depending on the aac encoder version.

While I understand what you are saying, unfortunately there are many posts on this forum from members asking why there AAC channel orders are messed up!

Some of these channel order problems seem to be associated with people converting AC3 to WAV and then AAC. This approach always waves "red flags" to me, as it opens up two potential places to "cock up" the channel order.

The first "cock-up" area is getting the AC3 to WAV channel mapping right. The second "cock-up" area is getting the WAV to AAC channel mapping right.

As Foobar2000 removes the need to convert to WAV first, it illiminates these two "cock-up" areas!

While I understand what you are saying, ..
The first "cock-up" area is getting the AC3 to WAV channel mapping right. The second "cock-up" area is getting the WAV to AAC channel mapping right.

As Foobar2000 removes the need to convert to WAV first, it illiminates these two "cock-up" areas!

Unfortunately, it seems not. Every trancoding includes these two steps(decoding & encoding) internally or externally.
Hiding things(black box), is what the users cannot control at all, must be used only for something stable or are abused when the author want an everlasting provider position, very opposite to what we are looking for.

Unfortunately, it seems not. Every trancoding includes these two steps(decoding & encoding) internally or externally.
Hiding things(black box), is what the users cannot control at all, must be used only for something stable or are abused when the author want an everlasting provider position, very opposite to what we are looking for.

So have you (or anybody else) tried generating an 6Ch AAC encode using my suggested method, or not?

..YES i've tested the aac(mp4,m4a) encoding with foo_naac.dll/foo_nero.dll/naac.exe and version 6/7 of aacenc32.dlls. It's easy to detect the difference although I am not sure which is causing it : foobar encloder plugins/cli or nero encoders. When I used the above described method, both v6 and v7 of nero encoder dlls reqired the same channel mappings. Maybe the foobar aac encode-interface routine is checking the nero dll version(i.e. to be v6)?

For your own prompt verification (I am off the test machine ), I think you can install the trial version on any computer and copy the aacenc32.dll from the program files nero common folder to the local script folder to override the existing nero dlls until you get the nero digital, recode 2 or any seperate version equivalent to v7.

I will try to send you the result even if I believe myself has done the best to explain.

OK. let us conclude. I did some more test based on the 6ch ac3 speaker test file I have from nforce 2 speaker setup directory.

naac.exe required two files from nero plugin directory, which can be overrided by the local folder placement : aac.dll and aacenc32.dll.
aac.dll seems to be responsible for the channel lineup from the assigned decoded wav buffer and can be used with any combinations of these two files.

But the channel line ups are different :
.v6 aac.dll : no need for channel remapping : FL_FR_C_LFE_SL_SR or a=GetChannel(a,1,2,3,4,5,6)
.v7 aac.dll : need the channel remapping : FR_C_FL_SR_LFE_SL or a=GetChannel(a,2,3,1,6,4,5)

So the conclusion is :
.nero changed the aac channel order from v7 by mistake or new policy, potentially a big confusion anyway.
.you can use the v6 aac.dll + v7 aacenc32.dll(actual encoder) with existing transcoding environment such as foobar2k v0.83 or besweet.

Thanks for being able to finish the side story of nero 7 channel mapping change, roles of these two nero dlls and walkaround by overriding the v6 aac.dll, which does not depreciate the avisynth's flexibility.

I worried about the LFE and corresponding channel behavior by using the v6 aac.dll for v7 encoder. But it turned out to be safe.

Thanks again for your interest in the introduced avisynth method. period.