7.1ch AAC encoding

[hello_hello]

I was experimenting with AAC and 7.1ch audio recently. https://hydrogenaud.io/index.php/topic,111454.0.html
What a mess..... I often ended up with the wrong layout or swapped channel assignments, or a combination of both, and it took me a while to work out what was happening. As this was all completely new to me I thought I'd share with the class. I was testing with Foobar2000 which uses ffmpeg for decoding.

For the purpose of this post
7.1ch (rear) = L R C LFE BL BR SL SR in wave file order.
7.1ch (front) = L R C LFE BL BR FCL FCR in wave file order.
In practice they both have the same combination of mono and stereo channels but 7.1ch (rear) has two pairs of rear speakers while 7.1ch (front) has two front pairs, where the additional pair are either side of the center speaker, between the left and right stereo speakers.

7.1ch (rear) would be the most common home theater format (Dolby, DTS) while I doubt 7.1ch (front) sees much home theater use, but it's the default for AAC.

A temporary problem: ffmpeg had a bug effecting 7.1ch (rear) audio encoded by FDKAAC, causing ffmpeg to decode it as 7.1ch (front). I think this was the bug, or something similar.
http://ffmpeg.org/pipermail/ffmpeg-cvslog/2015-June/090556.html
https://sites.google.com/site/qaacpage/news/fdkaac053
Fortunately foobar2000 1.10.3 beta 2 includes a newer ffmpeg so upgrading foobar2000 fixed that problem, once I eventually discovered the cause....

Because encoders such as Nero don't support 7.1ch (rear), as it requires the inclusion of a PCE (program config element) to specify a non-standard AAC channel layout, they've simply been remapping channels and encoding as 7.1ch (front). As this is often still the norm, decoders such as ffmpeg by default decode 7.1ch (front) as 7.1ch (rear), but when 7.1ch (front) AAC is really 7.1ch (front) it's not decoded correctly and the front stereo channels end up on the sides.

ffmpeg has an option "-strict 1" which I think could qualify as the least documented command line option in the history of the command line, which tells it to decode 7.1ch (front) AAC as it should be decoded. Unfortunately though it means foobar2000, LAV Filters and ffdshow etc don't decode real 7.1ch (front) AAC correctly.
https://sites.google.com/site/qaacpage/news/qaacrelease235refalac135

Edit: Foobar2000 can now decode 7.1ch AAC with ffmpeg's -strict 1 option. See post #3.

I found two other "gotchas".
FhGAAC encodes 7.1ch (rear) as 7.1ch (front) as Nero does, but with a different mapping, I'd imagine under the assumption it'll be decoded as 7.1ch (front). When it is, the SL and SR channels end up in FCL and FCR but the front stereo channels are where they should be.
As well as remapping 7.1ch (rear), NeroAAC must also remap 7.1ch (front), I'd imagine under the assumption it'll be decoded as 7.1ch (rear). When it is you end up with the FCL and FCR channels in SL and SR but the front stereo channels are where they should be.

To summarize:
QAAC and FDKAAC both encode 7.1ch (rear) correctly.
QAAC, FDKAAC and FhGAAC encode 7.1ch (front) correctly but ffmpeg requires "-strict 1" to decode it properly and software based on ffmpeg will probably decode it incorrectly.
NeroAACEnc encodes 7.1ch (rear) incorrectly as 7.1ch (front) but ffmpeg compensates and decodes it correctly.
NeroAACEnc encodes 7.1ch (front) incorrectly so it's decoded by ffmpeg with the original FCL and FCR channels in SL and SR instead.
FhGAAC encodes 7.1ch (rear) incorrectly but it's decoded by ffmpeg with "-strict 1" with the original SL and SR channels in FCL and FCR instead.

FFmpeg's native AAC encoder doesn't support PCEs and behaves the same way as Nero when encoding both 7.1ch (rear) and 7.1ch (front), so I guess non-compliant 7.1ch (front) decoding isn't going to go away any time soon.

It makes me wonder what hardware players might do with 7.1ch AAC (front) audio. Would they decode it according to spec or assume it's non-spec 7.1ch (rear) as ffmpeg does?

If you're going to encode 7.1ch (rear).... the most common type..... I'd only use QAAC or FDKAAC. Both will produce complaint 7.1ch (rear) AAC that should be correctly decoded by anything supporting 7.1ch AAC. The way the other encoders do it is really just a hack.
I'd consider 7.1ch (front) AAC to be non-supported due to the way encoders have creatively used it to encode 7.1ch (rear) and the way it's incorrectly decoded to compensate. Despite 7.1ch (front) being the default AAC layout, it's unlikely to be decoded correctly using a PC and I'm not sure if home theater systems support a 7.1ch (front) layout anyway.

Hopefully I got all that right.
I was going to test 6.0, 6.1 and 7.0 channel layouts too, but by the time I got my head around all that I'd had enough. It took a bit of time to check if the audio in each channel was where it was supposed to be, as well as check the input and output channel layouts.

[hello_hello]

Some general encoder behavior I discovered along the way:

FDKAAC is well behaved. It rejects any layouts it doesn't support properly rather than silently remapping them.
FFmpeg's native AAC encoder wildly remaps non-standard AAC channel layouts to standard ones. 6.0 channel is encoded as 5.1ch or 4.1ch as 5.0 channel etc. It'll only reject a layout with a total of 7 channels as there's no corresponding default AAC layout.
FhGAAC behaves in the same way as FFmpeg.
NeroAAC seems a bit schizophrenic. I haven't checked the channel mapping properly yet, but the output layout shows it supports some formats requiring a PCE such as 2.1, quad and 6.1, but for others it wildly remaps.
QAAC supports PCEs and is well behaved. It rejects layouts it doesn't support and remaps only when it makes sense. There's a list of supported layouts here. https://github.com/nu774/qaac/wiki/Multichannel--handling

[hello_hello]

foobar2000 1.3.10 now has a option in preferences (under Advanced) to set "-strict 1" so it'll decode 7.1ch (front) AAC correctly, or according to spec, rather than decode it as 7.1ch (rear).

Thanks Peter!