AC3 to AAC conversion

[hello_hello]

As well as my double standard, you either kept what you could play or upgraded your players to match the files. Same Mary, different dress.

So no example then? I thought not.

I've been using MPC and MPC-HC for years (the oldest MPC installer I have on my hard drive is dated 2003). I don't recall ever having deleted (or converted) a video simply because I could no longer play it using the PC (I just found the appropriate codec or installed a different player), and even if I had, it wouldn't have been a video I'd re-encoded from DVD or Bluray. Aside from mpeg1/2, mpeg4 (Xvid/Divx) and h264, have there been other formats commonly used to re-encode video? Formats that can't be played today with most software players?
The most commonly used formats MPC-HC couldn't natively play would have been RealPlayer and QuickTime but it could use their codecs if the players were installed. These days, it can play them on it's own. I image VLC can do likewise and they'd have to be the two most popular freeware players.

You missed a lot of things, but you simply cannot more.
I changed the player for one that sends all data digitally (HDMI) to my AVR, instead of 6 analogue cables.
My problem was that I missed that my Pio can't do DVD-Audio.
This has nothing to do with the standards per se, just with the artificial segmentation of the market. Not a big deal, as I have only a few of them, and I will anyway buy no one in the future.

Yes, you forgot to mention industry standard players with drives for playing two generations of discs aren't necessarily going to be able to connect correctly to other previous/future/current generation devices.

I saved the music losslessly in a different format. One generation, bit-perfect, two in total if we count the digitization, three if the LFE is considered, too. And this will be bit-perfect also in the future, as it will be directly (losslessly, bit-perfect) repacked or used as such in the BD-audio or as the audio part of the BD-video, which is the current standard.

Yep, we all use PCs for that sort of thing despite the fact we're apparently only supposed to use hardware players to play them, but it's doubtful in the future we'll have to downgrade software to an older version to play/edit/convert it. More likely we could just play it as it is while remapping the channels on the fly and send it out in an AVR friendly format.

PS: I still burn CDs/DVDs/BDs in the old-fashioned, space-wasting, low-quality formats. And guess what, I can drop any of them in any player that belongs at least to the same generation or newer and can watch it on any TV compatible with the player. Two technical generations are always allowed.

And for devices without a disc drive? Bum up, head in the sand?
I can put my modern, compressed, space saving files on a USB stick and play them using any player in this house. I can still burn discs if necessary. I just rarely need to.

I understand your concerns. I also tend to stick to hardware compatible formats. Not the industry standard ones, but the commonly used formats most industry standard players can also play these days.
I can't form the conclusion a hardware player will play my video with a higher quality than my PC connected to my TV via HDMI though, because I can't see a quality difference. What am I missing?

[kuchikirukia]

The point is, I myself and 5 other people :) don't back lousy specifications nor lazy implementations ;) End-Of-OT.

I'm with you.
I refuse to use any hard drive, USB stick, SSD, tape, floppy, CD or DVD drive because they all neglect to support reading Edison phonograph cylinders and stone etchings.


Sent from my tin can over smoke signal.

[filler56789]

I'm with you.
I refuse to use any hard drive, USB stick, SSD, tape, floppy, CD or DVD drive because they all neglect to support reading Edison phonograph cylinders and stone etchings.


Sent from my tin can over smoke signal.

Thanks for completely misunderstanding what I wrote.

Or should I say, for *pretending* :devil: to misunderstand what I wrote?
After all, some people need some "good" (read: lame) excuses for postwhoring.

Actually, your reply was rather fallacious.

[hello_hello]

I'm still trying to understand why some encoders (FDK and QAAC) actively reject some channel layouts. Others simply remap to a channel layout they want to use (FhG and Nero) which to me seems a bit naughty. I'd rather have a "no I won't do that" error message.

I played around a little with QAAC as it's the only AAC encoder I have that'll reject channel layouts it doesn't like and let you specify exactly the layout you want. I used a 4ch audio file and the standard 4ch layouts listed at the bottom of this page: https://trac.ffmpeg.org/wiki/AudioChannelManipulation#Muteachannel

They are:

3.1: FL+FR+FC+LFE
4.0: FL+FR+FC+BC
Quad: FL+FR+BL+BR
Quad: (side) FL+FR+SL+SR

When specifying a channel layout QAAC encoded the 4.0 and Quad layouts correctly, and it didn't reject the Quad (side) layout (although the Apple encoder remaps "Quad (side)" to "Quad" as explained here (https://github.com/nu774/qaac/wiki/Multichannel--handling), but it completely rejects 3.1ch. Looking at the list of channel layouts on the QAAC page I linked to that's hardly a surprise, but as none of the AAC encoders will encode 3.1ch (they either reject it or encode is as 4.0) there must be a reason for it beyond Apple not having bothered implementing 3.1ch encoding, or there's an AAC conspiracy taking place, but I'm not sure what the reason is.

I didn't play around with too many channel number/layout combinations other than the 4ch ones, but so far all the AAC encoders either refuse to encode 4.1ch or they remap it to something else, but once again I'd assume there's a reason.

And of course there's always the exception that makes the rule. 2.1ch is either encoded as 3ch or rejected, except by Nero. The Nero encoder will happily distinguish between 2.1ch and 3ch and encode either correctly. I don't know why.

[Ghitulescu]

There is no problem to make a file with any channel configuration one would like.
That an encoder/muxer rejects a file, it does because their programmers consider that certain configurations have no sense (no HW supported), not because it cannot be done.

In a Jesusian parable: a computer may equally split an invoice among 3 people, just that in real life no one can pay 33€ and 33.33 cents.

[filler56789]

Some more food for the thought:

As AC3, DTS and MLP were designed to support 1.1, 2.1, two types of 3.0/3.1 and two types of 4.0/4.1, probably their designers were thinking about the needs of the content creators/producers; I mean, if someone wants to create, for example, a 4-channel-only audio track, fine, then he/she will not need to create 2 additional dummy channels because of half-assed format_specifications /firmware /software.

Now, regarding the AAC specs:
¿why define TWO methods for identifying a channel layout? What's the point?

[nevcairiel]

There isn't really two methods to define it, there is one method to explicitly define every single channel .. and one method to simply not define anything, and let the defaults apply.
In most cases, this is because at first, there was only the implicit defaults, and then someone thought it would be nice to have support for more, and the second method was born in a addendum to the original spec.

FWIW, encoding anything that is not a "default" channel layout will cause trouble sooner or later, and if only during playback as players get confused. Ever tried sending 4 channel audio over HDMI, without modification? Good luck communicating the speaker mask to the HDMI receiver. ;)
I gave my LAV Audio a special mode that remaps all "uncommon" channel layouts into a default layout with silent channels to combat such problems. Before, I've had problems with 5.0 missing a center, since it got interpreted as 4.1 over HDMI (and some other broken combinations, too).

[hello_hello]

The way I understand it the "default" layout is the layout for wave files, which is here (under default channel ordering):

https://msdn.microsoft.com/en-us/library/windows/hardware/dn653308%28v=vs.85%29.aspx
Here's the first six.

1. Front Left - FL
2. Front Right - FR
3. Front Center - FC
4. Low Frequency - LF
5. Back Left - BL
6. Back Right - BR
7. Front Left of Center - FLC
8. Front Right of Center - FRC
9. Back Center - BC

You can't omit a channel as such, as the following channels would then "move up" one, so for example if you had a 3ch wave file that was actually channels 1, 2 and 4 you'd end up with the LFE channel in the centre channel. To enable specifying any channel configuration, the ChannelMask system is used (there's a list further down the page I linked to). The channel order remains exactly the same as above, but now you can specify which channels a wave file consists of. Without a channel mask, the default order is assumed.

The QAAC encoder is the only AAC encoder with a --chanmask command line option allowing you to over-ride the channel mapping of the wave file and set your own. For 4 channel configurations......

3.1: FL+FR+FC+LFE - 0x00000015
4.0: FL+FR+FC+BC - 0x00000107
Quad: FL+FR+BL+BR - 0x00000033
Quad: (side) FL+FR+SL+SR - 0x00000603 (QAAC remaps this to the Quad channel layout internally)

Please feel free to check I'm using the correct channel masks, but QAAC will accept any of the above channel masks in the command line except the first, which it rejects. It encodes the rest correctly (aside from internally remapping SL+SR to BL+BR). If you try to encode a 4ch wave file with the 3.1ch mask using any of the AAC encoders, it'll either be remapped to the 4.0ch mapping without warning, or it'll be rejected (depending on the encoder).

I'm not yet subscribing to an AAC conspiracy theory, so I'm trying to understand why that'd be when I don't see any reason why AAC couldn't be used to encode 3.1ch (or any channel mask you care to specify), at least in theory, yet all the AAC encoders refuse to do so. There must be a reason for it. A reason why 3.1ch AAC must be a bad thing..... I assume?

It might relate to hardware players/receivers generally not knowing what 3.1ch is and assuming it's some other 4ch configuration, although that'd mean hardware players would be similarly ignorant of 4.1ch, and those designing the specs for AAC decided that'd be a good reason for those formats to be illegal. That still leaves the 2.1ch exception unexplained though, in respect to why Nero will encode 2.1ch correctly but the rest of the AAC encoder won't.

Now, regarding the AAC specs:
¿why define TWO methods for identifying a channel layout? What's the point?

Other than the above, is there another method? The post you linked to earlier (http://forum.videohelp.com/threads/333743-Aac-7-1?p=2158472&viewfull=1#post2158472) refers to a "program_config_element()" or lack thereof, and how AAC channel ordering is handled without it.
I'd been working under the assumption it's used to specify the default AAC channel ordering for encoding, but now I think it's just specifying the default mapping for decoding when there's none specified in the AAC stream itself.

The link refers to SCE's, CPE's and LFE's and how they're assigned to channels when no assignment is specified.
Understanding AAC (http://wiki.multimedia.cx/index.php?title=Understanding_AAC)
SCE = single channel element
CPE= channel pair element
LFE = low frequency element

If the number of single channel elements is odd they're output starting at the centre speaker and from there in pairs outwards (front left+right, back left+right etc). If there's an even number they start with left and right.
A CPE seems to be counted as two SCE's so the same method of assigning channels is still used when there's a combination of SCE's and CPE's.
I'm thinking it even conforms to the wave file channel order with the LFE channel removed (although I'm not 100% sure there). It seems AAC knows the difference between a SCE and a LFE but there's no default speaker mapping for multiple LFE's.

And that makes sense when you look at the order in which AAC stores encoded audio (for 5.1ch).
FC FL FR SL SR LFE
It'd be encoded as a SCE, two CPEs and a LFE.

Mind you even the implicit channel ordering seems to indicate not only is 3.1ch AAC possible, if there's no explicit channel mapping, three channels and a LFE should result in 3.1ch output, the way I read it.......
There must be a reason.....

[Ghitulescu]

Unfortunately, there was no intention from Microsoft to finalize things.

Historically they may suggest they intend to finish the things, for instance to set legal values for the myriad of RESERVED fields and values all over their data structures, but they never did this. They simply created a new, usually incompatible format, and went along.

I don't know why hello_hello considers that particular sequence to be THE ONE, namely FL, FR, FC, LFE, BL, BR, when some of the first creators of a multi channel sound files, eg Dolby, specified a different order, namely L, C, R, BL, BR, LFE in 1991, when Microsoft just finished to set the RIFF adaptation to WAV.

So, once again, Microsoft comes 2007 and stir the standards to a new assignment (when she realised multichannel audio is the future). Why did she this? Because she could. Microsoft showed people that she'll not obey other party standards but her own. That's the power of a (quasi)monopole. Those that impose the rules always win.

Concerning the HW players and unusual channel configurations. Well, these had no problems to map correctly the channels, as no Microsoft "imagination" was involved in this. A DVD-Audio player would play 4.1 files perfectly (L,R,LFE,Ls,Rs). A computer relying on Microsoft code and formats would have a problem, unless the programmers managed to get workarounds (like custom channel mapping and stuff).

[hello_hello]

Unfortunately, there was no intention from Microsoft to finalise things.

Mono and stereo wave files have been around for a long time. I think the idea behind the wave file channel ordering was simply to increase the number of channels without making too much of a mess. When the two channels in a stereo wave file are left and right, why when you add a third (ie centre) would it be logical to put it in the middle?

I don't know why hello_hello considers that particular sequence to be THE ONE, namely FL, FR, FC, LFE, BL, BR, when some of the first creators of a multi channel sound files, eg Dolby, specified a different order, namely L, C, R, BL, BR, LFE in 1991, when Microsoft just finished to set the RIFF adaptation to WAV.

The wave file format is THE intermediate PC format used when converting between one format and another. Import a 5.1ch AC3 file into Audacity and then do the same for 5.1ch AAC file. They'll both be imported using the wave file channel order.
Re-encode from one format to another and it'll be decoded using the channel order for wave files and a wave file channel mask for the encoder to know which particular channels are included. I don't know why that needs explaining to Ghitulescu unless some decoders decode use a different channel order and encoders accept different channel masks to define the input channels.

Concerning the HW players and unusual channel configurations. Well, these had no problems to map correctly the channels, as no Microsoft "imagination" was involved in this. A DVD-Audio player would play 4.1 files perfectly (L,R,LFE,Ls,Rs). A computer relying on Microsoft code and formats would have a problem, unless the programmers managed to get workarounds (like custom channel mapping and stuff).

So your recent efforts to convert 4.1ch audio to 5.1ch audio? That was all Microsoft's fault and nothing to do with your hardware not decoding 4.1ch correctly?

[Ghitulescu]

I think the idea behind the wave file channel ordering was simply to increase the number of channels without making too much of a mess.
The original RIFF/WAV specs allowed for this.
When the two channels in a stereo wave file are left and right, why when you add a third (ie centre) would it be logical to put it in the middle?
No. When stereo appeared (stereo doesn't mean 2 channels but spatial), people put a number of speakers around the listener. It was the need of a researcher and his paper to demonstrate that stereophonic image can be obtained with only 2 speakers. So 3 speakers were a triangle. Like 4 channels in the '70ies were placed around the listener not all in front of him. Therefore a third channel is more logical to be Center-Back rather than Center-Front.
The wave file format is THE intermediate PC format used when converting between one format and another. Import a 5.1ch AC3 file into Audacity and then do the same for 5.1ch AAC file. They'll both be imported using the wave file channel order.
It is not. Audacity does not need AFAIK to convert to WAV any file it processes. It converts them however to raw (L)PCM which is not WAV.

I wonder how the engineers at Dolby or in Hollywood converted the audio to Dolby 5.1 when WAV lacked this possibility. Hm, Hm, Hm :)
I don't know why that needs explaining to Ghitulescu unless some decoders decode use a different channel order and encoders accept different channel masks to define the input channels.
Half-knowing is dangerous, as I see :)
Channel mask is the MS invention. Dolby had presets: 4 channels could only mean L,R,Ls,Rs, and this could be combined with LFE to get 4.1.
So your recent efforts to convert 4.1ch audio to 5.1ch audio? That was all Microsoft's fault and nothing to do with your hardware not decoding 4.1ch correctly?
No, the hardware correctly decoded the files that were not WAV, but I could not get there without passing through WAV due to the tools I am allowed to use. 4.1 it is allowed in Dolby Digital (also in real life, as the video part was dolbidised), see above.

[hello_hello]

Anyway......

After a bit more research it seems the info in the post filler56789 (http://forum.videohelp.com/threads/333743-Aac-7-1?p=2158472&viewfull=1#post2158472) linked to is correct, only maybe it's been interpreted backwards.
The conclusions was:
"As already expected, most encoders and decoders use only the "implicit channel mapping"".
However I think it's exactly the opposite. They'll mostly only use the "explicit" channel mapping, because the "implicit" channel mapping implies 3.1ch AAC encoding is possible. The "explicit" channel mapping however only includes a pre-defined set of channel mappings.

The info in the above link refers to "16 available PCE’s" to define channel mappings. The first seven are listed here:
http://spectralhole.blogspot.com.au/2010/08/aac-bistream-flaws-part-1-channel-model.html

Just as I thought I was onto a logical explanation it occurred to me there seems to be only one official PCE for 4ch audio, and that's for a 4ch layout consisting of front stereo, front centre and a rear surround channel (the 4.0ch layout mentioned in my earlier post), yet QAAC will still accept and encode the two 4ch QUAD mappings, but not 3.1ch...... there must be a logical reason for that.

[hello_hello]

No. When stereo appeared (stereo doesn't mean 2 channels but spatial), people put a number of speakers around the listener. It was the need of a researcher and his paper to demonstrate that stereophonic image can be obtained with only 2 speakers. So 3 speakers were a triangle. Like 4 channels in the '70ies were placed around the listener not all in front of him. Therefore a third channel is more logical to be Center-Back rather than Center-Front.

I'm not talking about the position of speakers, I'm talking about the physical wave file itself. You can sit on the third speaker for all it matters, but when you add a third channel to a wave file consisting of two channels that'd normally be decoded as stereo, why would you put it in the middle? Why wouldn't you keep the first two channels as stereo channels and add the third channel as a third channel?

It is not. Audacity does not need AFAIK to convert to WAV any file it processes. It converts them however to raw (L)PCM which is not WAV.

Why is it so hard for you to understand a simple point? I never said they're imported as wave files. I said they're imported using the wave file channel order.
Import a 5.1ch file into Audacity and look at the physical order. ie the order the channels appear in the GUI. It's the wave file channel order. It doesn't matter what format you import or the channel order that format uses, they're imported using THE common channel order. The channel order for wave files.
And no, I didn't say they were imported as wave files, in case you're still confused.

I wonder how the engineers at Dolby or in Hollywood converted the audio to Dolby 5.1 when WAV lacked this possibility. Hm, Hm, Hm :)

I don't know, but you're telling the story and it's not going to be satisfying until we learn how it ends. How did they do it?

Half-knowing is dangerous, as I see :)
Channel mask is the MS invention. Dolby had presets: 4 channels could only mean L,R,Ls,Rs, and this could be combined with LFE to get 4.1.

Nobody said it wasn't a Microsoft invention, but HHEELLOO!!!!! We're referring to using a PC and for a PC when decoding different formats and/or encoding using different codecs it's standard to use the wave file channel ordering and wave file channel mask as an intermediate format. I've never said anything different.

No, the hardware correctly decoded the files that were not WAV, but I could not get there without passing through WAV due to the tools I am allowed to use. 4.1 it is allowed in Dolby Digital (also in real life, as the video part was dolbidised), see above.

Did you need to convert your 4.1ch files to 5.1ch for you AVR to decode them correctly as per your thread, or was there really some other reason for it you're now only just revealing?

[filler56789]

........
......
..........

there must be a logical reason for that.

There must be a reason? Surely.
But does that reason have to be *logical*? Not at all.

Human beings are notorious for being illogical and irrational. And unfortunately, becoming a (self-declared) "champion of (PSEUDO-)skepticism and (Illuminist) rationality" invariably only makes the disease worse :D

[hello_hello]

Well I tried, but so far nothing as simple as "the freeware AAC encoders don't support 3.1ch audio because....." on any web page I've looked at. I still think there must be a logical explanation, if for no other reason than they're all the same. It's not like one encoder encodes it while another won't, but no matter how rational or irrational that reason may be, I'm yet to find it. :(

[Ghitulescu]

Did you need to convert your 4.1ch files to 5.1ch for you AVR to decode them correctly as per your thread, or was there really some other reason for it you're now only just revealing?
My AVR works just fine. But I was in need to convert a 4.1 (no centre) audio to something I can use. And ran into WAV peculiarities and software shortcoming.

In case you overthink instead of reading, I changed the player and not double checking some information.

The AAC standard 13818-7 allows for whatever channel combination and order. If one particular encoder does not like a particular configuration it's entirely its (encoder) fault.

In the case of 3.1 the standard does not allow it if the configuration is Left, Right, Centre and LFE the can only be one single channel, and this is the LFE. All others must be paired. The trick would be to allocate two channels (center left and cenjter right) to represent C (dual mono).

[hello_hello]

My AVR works just fine. But I was in need to convert a 4.1 (no centre) audio to something I can use. And ran into WAV peculiarities and software shortcoming.

In case you overthink instead of reading, I changed the player and not double checking some information.

I'm not over-thinking anything. I'm trying hard not to think about your logic behind having to convert formats that you claimed were being decoded correctly.

The AAC standard 13818-7 allows for whatever channel combination and order. If one particular encoder does not like a particular configuration it's entirely its (encoder) fault.

There must be an AAC encoder conspiracy taking place then.

In the case of 3.1 the standard does not allow it if the configuration is Left, Right, Centre and LFE the can only be one single channel, and this is the LFE. All others must be paired. The trick would be to allocate two channels (center left and cenjter right) to represent C (dual mono).

So the standard allows for any channel combination, and if an encoder doesn't like a configuration it's the encoder's fault, except for 3.1ch because the standard that allows for any configuration doesn't allow for 3.1ch. Is that how it works?

That definitely sounds like something you just made up again. How do you explain 5.1ch? Doesn't it consist of 2 pairs of channels and two single channels? What about 4ch? Doesn't it have two single channels? Front left and right (paired channel) plus front centre and rear surround, both being single channels? According to Table 42 on page 61 of this pdf, (www.nhzjj.com/asp/admin/editor/newsfile/201031816243950.pdf) the 4.0ch configuration definitely contains two single channel elements.

[Ghitulescu]

I'm not over-thinking anything. I'm trying hard not to think about your logic behind having to convert formats that you claimed were being decoded correctly.
It is a behaviour at you NOT TO understand what is written. I mean to try to twist what has been said in order to make you like having right when you're obviously wrong. I changed the player and the DVD-A was not supported in the new one (although some reviewers mentioned it). DVD-A and SACD are rather dead and toys implementing both are rare. It is my fault for not double checking this. Since I own olny a few DVD-A discs I decided to convert them to a format my new player accepts, either a DVD-V with lossless audio, or a collection of FLACs, rather than to buy a new, universal player, matching my existing rig.
But when the pieces of gear work - they work. They can't afford to wait for a firmware upgrade or to ask for downloading of a new codec or codec-pack as on a computer. They have to work right out-of-the-box. Besides, a 4.1 DVD-A disc would not be sold if this combination of channels would be unsupported by the players it is designed for.
According to Table 42 on page 61, the 4.0ch configuration definitely contains two single channel elements.
Table 42 reads, for 4 channels, the following and only configuration
4 ¦ 4 ¦ single_channel_element(center front speaker), channel_pair_element(left, right center front speakers), single_channel_element(rear surround).

So it's a 3 center front-speakers and a single rear one configuration. Hardly a real-life configuration (unless one implements true L and R to be stored as LFC and RFC). This is how I read them. I am not sure this configuration has anything to do with your expectations of a 3.1 configuration (most probably L, R, C and LFE).
But this are the implicit/default matrixes. In other words, if you send a 4-substreams file to any AAC-encoder that encoder has to use the default matrix (table 42) to assign the channels.
If you don't want this stupid 4-chn matrix you have to use a custom assignment, as per clause 8.5.3.2. Wherein Any SCE’s except the last SCE must be paired, and the presence of exactly two SCE’s (alone or preceeded by a CPE) indicates that the two SCE’s are Left and Right Rear center, respectively.So, you may have: CPEs (already paired) and paired SCEs but only the last SCE in the list may be a "bachelor" (usually LFE).

Because LFE always was a single channel (since Dolby implemented it in 1991).

Why this strange pairing? For encoding economy - in short, pair channels may be encoded as MS (Mid+Side), known as joint stereo in MP3.
Single channels are reserved for channels carrying important information, like L and R, although they can also be present as a pair (probably to allow an even lower bitrate).

[hello_hello]

It is a behaviour at you NOT TO understand what is written. I mean to try to twist what has been said in order to make you like having right when you're obviously wrong.

I understand exactly what's written and I don't need to try to twist anything.
I'm fully aware you had to convert the 4.1ch audio to 5.1ch. I never said you didn't. I just don't know why it requires references to Microsoft when you're using a hardware player and it's got nothing to do with the topic. It's just you once again dragging a thread off on a tangent because you like to pretend you know what you're talking about and you thought my references to the wave file format was an opportunity to display how clever you think you are, only once again you didn't understand what was being said and the result was another of your tangents.
Stating I'm obviously wrong is hilarious coming from you when you've ignored almost entire posts in this thread because they've proved you wrong.

Table 42 reads, for 4 channels, the following and only configuration
4 ¦ 4 ¦ single_channel_element(center front speaker), channel_pair_element(left, right center front speakers), single_channel_element(rear surround).

So it's a 3 center front-speakers and a single rear one configuration. Hardly a real-life configuration (unless one implements true L and R to be stored as LFC and RFC). This is how I read them.
I am not sure this configuration has anything to do with your expectations of a 3.1 configuration (most probably L, R, C and LFE).

Foobar2000 displays 4.0ch audio consisting of a front centre channel, front left and right channels, and a rear centre channel.
Whether it's labelled as rear centre or rear surround I don't see how it's any different to 3.1ch except there's a rear centre channel instead of a LFE channel. It's specified as two single channel elements and one channel pair element, a configuration you said wasn't allowed because only one unpaired SCE was allowed.

But this are the implicit/default matrixes. In other words, if you send a 4-substreams file to any AAC-encoder that encoder has to use the default matrix (table 42) to assign the channels.
If you don't want this stupid 4-chn matrix you have to use a custom assignment, as per clause 8.5.3.2.

So it can use the stupid 4ch matrix despite your claim there can only be one unpaired single channel, or is that somehow still true even while we talk about the 4ch configuration with two unpaired SCEs?

Any SCE’s except the last SCE must be paired, and the presence of exactly two SCE’s (alone or preceeded by a CPE) indicates that the two SCE’s are Left and Right Rear center, respectively.

Let's include the part of 8.5.3.2 you ignored because it didn't suit you.

Included in the PCE are “list of front channels”, using the rule center outwards, left before right. In this list, a center channel SCE, if any, must come first, and any other SCE’s must appear in pairs, constituting an LR pair.

After the list of front channels, there is a list of “side channels” consisting of CPE’s, or of pairs of SCE’s. These are listed in the order of front to back. Again, in the case of a pair of SCE’s, the first is a left channel, the second a right channel.

After the list of side channels, a list of back channels is available, listed from outside in. Any SCE’s except the last SCE must be paired, and the presence of exactly two SCE’s (alone or preceeded by a CPE) indicates that the two SCE’s are Left and Right Rear center, respectively.

Obviously you can start with a non-paired SCE and end with a non-paired SCE and every time I add one single SCE to another single SCE I get two single SCEs. Didn't you say there could only be one?
The default 4ch matrix follows the rule exactly as described. Unpaired SCE (centre), paired SCE(L&R), unpaired SCE (rear).

So, you may have: CPEs (already paired) and paired SCEs but only the last SCE in the list may be a "bachelor" (usually LFE).
Because LFE always was a single channel (since Dolby implemented it in 1991).

The AAC spec clearly distinguishes between a LFE and a SCE so the last SCE in the chain is not assumed to be an LFE channel. That's just something new you've made up. Only a LFE channel is assumed to be an LFE channel.
You only have to think about 5.1ch audio for ten seconds to see your claim makes no sense. Front LR is a pair, rear LR is a pair, the LFE channel is unpaired, so where does that leave the centre channel when there can't be another unpaired SCE? Obviously 3.1ch is the same as 5.1ch with a pair of SCEs removed. How then can 3.1ch not be allowed??

Other elements are also specified. A list of one or more LFE’s is specified for application to this program.

Why this strange pairing? For encoding economy - in short, pair channels may be encoded as MS (Mid+Side), known as joint stereo in MP3.
Single channels are reserved for channels carrying important information, like L and R, although they can also be present as a pair (probably to allow an even lower bitrate).

You sure you're not making it up as you go again? Why have SCEs if they're going to be encoded as joint stereo? It seems more likely that the definition of a pair of SCEs encoded using joint stereo would be a CPE.
And why can't you encode important channels like L and R using joint stereo? Wouldn't that kind of be the point of it?

[tebasuna51]

Please guys let's go.

Last posts are useless for others users.