How to see a 5.1 file's channel layout? + Channel layout error with ffmpeg

[HoraceMcMahon]

What's the best way to determine a 5.1 file's channel layout?

Mediainfo's "Channel positions" (not the same as " channel layout" apparently) tells me "Front L C R, Side L R LFE" no matter what file I give it, and for files whose channel layout's are certainly different.

I've been experiencing some playback problems with 5.1 files converted from a 5.1 DTS-HD source using FFmpeg (scrambled channel layout). VLC and Quicktime seem to reproduce most if not all of the same errors. MPC-HC plays everything correctly, but because the other two have playback issues, I presume there's something incorrect with the files.

FFmpeg tells me that the channel layout of the original DTS-HD file is "5.1(side)" (which is, as I understand it, SMPTE "L R C LFE Ls Rs").
When I convert the .dts file to FLAC via FFmpeg, I get a 5.1 FLAC file that FFmpeg tells me is "5.1(side)", and it plays fine.
When I convert the .dts file to LPCM in an .mov container, I get an audio only .mov file that FFmpeg tells me is "5.1(side)" and it does not play fine. It sounds like, at the very least, the center is playing through the left channel speaker.
Using FFmpeg to make a 5.1 file from 6 mono wavs with the channel layout mapped for SMPTE "L R C LFE Ls Rs", aka 5.1(side), I get a file that FFmpeg tells me is "5.1" -- NOT "5.1(side)" -- and it also has the "center channel playing through the left speaker" problem.

Is FFmpeg doing some strange behind the scenes channel layout? Or is this a playback issue related to reading the files and their metadata or headers?

Can one specify channel layout in FFmpeg, beyond what I've already did unsuccessfully with the mono files (see below)?

ffmpeg -i front_left.wav -i front_right.wav -i front_center.wav -i lfe.wav -i back_left.wav -i back_right.wav \
-filter_complex "[0:a][1:a][2:a][3:a][4:a][5:a]amerge=inputs=6[aout]" -acodec pcm_s24le output.mov

It'd be nice to find a program that could tell me simply and directly what the channel layout is for all these files, from the .dts to the .flac to the audio .mov, using the letter abbreviations rather than the vague "5.1(side)" and "5.1" -- which make little sense as there are more than two standardized 5.1 channel layouts. It would be a big troubleshooting help.

Thanks, all.

[El Heggunte]

What's the best way to determine a 5.1 file's channel layout?

Use foobar2000.

Is FFmpeg doing some strange behind the scenes channel layout? Or is this a playback issue related to reading the files and their metadata or headers?

Very probably. There are tasks for which FFmpeg is not a reliable tool.

[pandy]

You can't as nobody can prevent malicious/wrong channel layouts - if you have this kind of situation and you now proper channel allocation you may try to perform channel layout manipulation supported by ffmpeg:
https://trac.ffmpeg.org/wiki/AudioChannelManipulation
https://ffmpeg.org/ffmpeg-filters.html#pan-1

[HoraceMcMahon]

Thanks so much for the feedback. I've taken a look at everything you've all said.

Reading your responses, and doing other research, I'm thinking my best bet is to use "-af pan", as suggested by pandy (or maybe "-map_channel").

My goal is to create an LPCM .mov in 5.1(side), otherwise known as SMPTE standard or "L R C LFE Ls Rs".

Starting with 6 mono wavs and using ffmpeg or some other program to map them to those positions seems the most exact way to do this.

I tried -af pan first, because one can specify 5.1(side) and exact channel positions, but I think my syntax is wrong. I'm not sure how to tell the pan filter to understand each separate input file as a channel. The below resulted in a 5.1 file with only a center/third channel and the other 5 channels muted/empty.

ffmpeg -i FL.wav -i FR.wav -i FC.wav -i LFE.wav -i SL.wav -i SR.wav -acodec pcm_s24le \
-af pan="5.1(side):c0=FL|c1=FR|c2=FC|c3=LFE|c4=SL|c5=SR" output.mov

In place of c0 etc should I be using something like "0:a" etc?

[El Heggunte]

You could use wavfix.exe for fixing — i.e., assigning a proper ``channel mask´´ to — a multichannel .WAV file created through ffmpeg or sox.

OR use an Avisynth script plus wavi.exe for generating a correct result from mono inputs
(yeah, sometimes I like to complicate things).

As for the compliance of ffmpeg's MOV muxer...
OR whether the .MOV container deals correctly with uncompressed multichannel audio...
I honestly don't know

[El Heggunte]

FWIW:

CHANNEL NAME --- Decimal Value
¯¯¯¯¯¯¯¯¯¯¯¯     ¯¯¯¯¯¯¯¯¯¯¯¯¯

FRONT_LEFT             1
FRONT_RIGHT            2
FRONT_CENTER           4
LOW_FREQUENCY          8
BACK_LEFT              16
BACK_RIGHT             32

FRONT_LEFT_OF_CENTER   64
FRONT_RIGHT_OF_CENTER  128

BACK_CENTER            256
SIDE_LEFT              512
SIDE_RIGHT             1024

*************************************

TOP_CENTER             2048
TOP_FRONT_LEFT         4096
TOP_FRONT_CENTER       8192
TOP_FRONT_RIGHT        16384
TOP_BACK_LEFT          32768
TOP_BACK_CENTER        65536
TOP_BACK_RIGHT         131072
RESERVED               262144

[HoraceMcMahon]

Unfortunately I can't use a wav container for the 5.1 due to file size. Total length of the 5.1 track is over 2 hours, and at 24 bit, the size is too much for a wav container (over 6GB, exceeding the 4GB limit). (BTW I haven't tried an .mp4 container; ultimately I'll be muxing this with an .mkv or .mp4, I figure it's better to not use .avi.)

I've never used SoX. Would it offer a benefit over ffmpeg?

El Heggunte, I'm sorry to admit I have no idea what to do with that decimal value chart. Is it related to using wavefix or wavi?

[El Heggunte]

Unfortunately I can't use a wav container for the 5.1 due to file size. Total length of the 5.1 track is over 2 hours, and at 24 bit, the size is too much for a wav container (over 6GB, exceeding the 4GB limit). (BTW I haven't tried an .mp4 container; ultimately I'll be muxing this with an .mkv or .mp4, I figure it's better to not use .avi.)

I've never used SoX. Would it offer a benefit over ffmpeg?

El Heggunte, I'm sorry to admit I have no idea what to do with that decimal value chart. Is it related to using wavefix or wavi?

3) Yep, wavfix, wavi and wavavimux use the channel mask values as defined by the Wave_Format_Extensible specification. So,
1+2+4+8+512+1024=1551 (= 0x060F, in hexadecimal notation).

2) sox is an audio-only application, so in theory at least, it should be more stable and less buggy than ffmpeg.

1) all of those tools have no problem in dealing with WAV files greater than 4GB. And BTW, if you don't mind a lossless audio format, ¿why not use ALAC? Its 5.1 layout is always interpreted /decoded as FL, FR, FC, LFE, SL and SR, and besides, ALAC is supported by all of those 3 containers — MOV, MP4, and MKV.

[HoraceMcMahon]

...if you don't mind a lossless audio format, ¿why not use ALAC?

Thanks for your help, El Heggunte. You make a good point. I'm now leaning toward using FLAC. In my ffmpeg trials it seems to reliably reproduce the correct channel layout creating 5.1 FLAC from the 6 mono wavs.

Though I still can't get 5.1(side) -- just 5.1 -- when going from the mono wavs to FLAC.Here's how FFmpeg defines 5.1 vs. 5.1(side):

5.1         FL+FR+FC+LFE+BL+BR
5.1(side)   FL+FR+FC+LFE+SL+SR

I'm not sure what difference the BACK left/right vs. SIDE left/right distinction makes in practice, but since the original DTS-HD file was 5.1(side), I'd like to end up there. Also, I know that ffmpeg does not apply "5.1" exclusively to the documented layout, because I created a track in the "L R Ls Rs C LFE" layout, confirmed by Adobe Audition, that ffmpeg read as "5.1".

Hoping someone will provide guidance regarding ffmpeg and the "-af pan" syntax, as referenced in my previous post, because I think it's the best tool to map the channels as I'd like to. Unless someone familiar with sox mapping 5.1 from 6 mono wavs has a better idea.

[pandy]

2) sox is an audio-only application, so in theory at least, it should be more stable and less buggy than ffmpeg.

Sox is OK for single file/source but it have few serious limitations and sometimes is even less useful than ffmpeg - main weakness is syntax even more weird and unpredictable than ffmpeg, side to this multiple file almost not work (no known workaround).

Hoping someone will provide guidance regarding ffmpeg and the "-af pan" syntax, as referenced in my previous post, because I think it's the best tool to map the channels as I'd like to. Unless someone familiar with sox mapping 5.1 from 6 mono wavs has a better idea.

ffmpeg -i front_left.wav -i front_right.wav -i front_center.wav -i lfe.wav -i back_left.wav -i back_right.wav -filter_complex "[0:a][1:a][2:a][3:a][4:a][5:a]amerge=inputs=6[aout]" -map "[aout]" output.wav

[CyberOtter]

Hey,
5.1 channel mapping with ffmpeg is a problem i had.
(Source of my problem was, that there are 2 standards with 5.1 mapping : , L C R SL SR LFE (AC3 type) and L R C LFE SL SR (wav type) )

Anyways, maybe try ClipToolz Convert. I use it sometimes, V2 is free and got this :



I also have a little routine with FFQueue and the 5.1 channel remap filter, if you feel like using it. ^^
But try Cliptoolz

[El Heggunte]

..........
Cliptoolz

Thanks for the info That program uses ffmbc, and AFAIR,
ffmbc was (/¿still is?) more reliable than ffmpeg in certain cases...

To whom this may interest, here is a download link for ClipToolz v2
(because the HDCinematics site doesn't have the binary anymore):

http://www.mudgee.net/ClipToolz-Convert-V2.msi

Notice: I have not tested it yet.

[CyberOtter]

Yup, FFMBC

and wow, i just went to the website (and FB page), and as there is now a released V3, free V2 has indeed been removed from DL on february 28th.

Good thing someone (you?) made a mirror. Thx.

I'm definitely gonna check V3 new features, coz it's a very cool piece of software, that use not only for 5.1 mapping

[HoraceMcMahon]

ffmpeg -i front_left.wav -i front_right.wav -i front_center.wav -i lfe.wav -i back_left.wav -i back_right.wav -filter_complex "[0:a][1:a][2:a][3:a][4:a][5:a]amerge=inputs=6[aout]" -map "[aout]" output.wav

Thanks, pandy. You'll see, though, in the OP that I've already tried the -filter_complex method. It never returns 5.1(side) -- for FLAC or LPCM .mov -- just 5.1. The pan filter allows you to specify 5.1(side) as well as specific channel mapping. I'm not clear on the syntax though.

Thanks Cyberotter for the ClipToolz Convert tip. I'll try that out later today.

[pandy]

ffmpeg -i front_left.wav -i front_right.wav -i front_center.wav -i lfe.wav -i back_left.wav -i back_right.wav -filter_complex "[0:a][1:a][2:a][3:a][4:a][5:a]amerge=inputs=6[aout]" -map "[aout]" output.wav

Thanks, pandy. You'll see, though, in the OP that I've already tried the -filter_complex method. It never returns 5.1(side) -- for FLAC or LPCM .mov -- just 5.1. The pan filter allows you to specify 5.1(side) as well as specific channel mapping. I'm not clear on the syntax though.

Thanks Cyberotter for the ClipToolz Convert tip. I'll try that out later today.

My point was that first you can control input and map explicitly trough merge however if you need remap channel you may use regular pan after amerge.

Individual channels:
NAME DESCRIPTION
FL front left
FR front right
FC front center
LFE low frequency
BL back left
BR back right
FLC front left-of-center
FRC front right-of-center
BC back center
SL side left
SR side right
TC top center
TFL top front left
TFC top front center
TFR top front right
TBL top back left
TBC top back center
TBR top back right
DL downmix left
DR downmix right
WL wide left
WR wide right
SDL surround direct left
SDR surround direct right
LFE2 low frequency 2

Standard channel layouts:
NAME DECOMPOSITION
mono FC
stereo FL+FR
2.1 FL+FR+LFE
3.0 FL+FR+FC
3.0(back) FL+FR+BC
4.0 FL+FR+FC+BC
quad FL+FR+BL+BR
quad(side) FL+FR+SL+SR
3.1 FL+FR+FC+LFE
5.0 FL+FR+FC+BL+BR
5.0(side) FL+FR+FC+SL+SR
4.1 FL+FR+FC+LFE+BC
5.1 FL+FR+FC+LFE+BL+BR
5.1(side) FL+FR+FC+LFE+SL+SR
6.0 FL+FR+FC+BC+SL+SR
6.0(front) FL+FR+FLC+FRC+SL+SR
hexagonal FL+FR+FC+BL+BR+BC
6.1 FL+FR+FC+LFE+BC+SL+SR
6.1(back) FL+FR+FC+LFE+BL+BR+BC
6.1(front) FL+FR+LFE+FLC+FRC+SL+SR
7.0 FL+FR+FC+BL+BR+SL+SR
7.0(front) FL+FR+FC+FLC+FRC+SL+SR
7.1 FL+FR+FC+LFE+BL+BR+SL+SR
7.1(wide) FL+FR+FC+LFE+BL+BR+FLC+FRC
7.1(wide-side) FL+FR+FC+LFE+FLC+FRC+SL+SR
octagonal FL+FR+FC+BL+BR+BC+SL+SR
hexadecagonal FL+FR+FC+BL+BR+BC+SL+SR+TFL+TFC+TFR+TBL+TBC+TBR+WL +WR
downmix DL+DR

This may help you also: https://ffmpeg.org/ffmpeg-filters.html#channelmap

To fix a 5.1 WAV improperly encoded in AAC’s native channel order

ffmpeg -i in.wav -filter 'channelmap=1|2|0|5|3|4:5.1' out.wav

[El Heggunte]

Hmmm, I *suppose* that I have started to understand what is the _actual_ problem......

.......
I'm not sure what difference the BACK left/right vs. SIDE left/right distinction makes in practice, but since the original DTS-HD file was 5.1(side), I'd like to end up there.

Mediainfo's "Channel positions" (not the same as " channel layout" apparently) tells me "Front L C R, Side L R LFE" no matter what file I give it, and for files whose channel layout's are certainly different.

MediaInfo and/or FFmpeg and/or whatever appear to be just following a convention invented in the "post-5.1 era"
Namely, unless the 5.1 audio stream is inside an uncompressed .WAV /.AVI /.ASF /.WMA /.WMV file,
it is always assumed to be FL+FR+FC+LFE+SL+SR.

AFAIK, only uncompressed 5.1 audio inside a WAV /AVI /ASF container,
or a Windows Media Audio stream inside an ASF container,
can be properly-flagged as anything different than "FL+FR+FC+LFE+SL+SR".

For example, in DTS-HD (and in TrueHD too, I presume), only the 7.1 channel layout may have the «side» channels. The official DTS-HD encoder has only one option for the 5.1 channel layout, and that option does not use Side-Left and Side-Right. The same thing happens with the formats MLP, AC3 and lossy DTS. In other words, it's up to the decoder or/and the end-user to decide whether the 'surround channels' in a 5.1 audio stream will be directed to the rear speakers (old-school preference) or to the lateral speakers (new convention).

[Cornucopia]

No, this has been discussed before: the MOV container (and by extension, MP4) has NAMED channels and so will tell you exactly how (in what order) those channels are listed, whether using industry convention order (SMPTE/AES/EBU) or not. Unless I'm mistaken, for those formats, the order does not matter, as they are retrieved by name, not number.

All other formats, with the partial/possible lone holdout of DTS, has acquiesced to follow the industry convention (though older files may still appear having used a different convention), and should retrieve channels by order #. MKV may be able to do both/either.

Scott

[hello_hello]

According to someone here, there's only one 5.1ch format for DTS, and that's FL+FR+FC+LFE+SL+SR. The actual encoding order is FC+FL+FR+SL+SR+LFE.

I think AC3 is also technically FL+FR+FC+LFE+SL+SR. Maybe like DTS that's from a bygone era when the "S" meant "surround" and not "side".

AAC supports FL+FR+FC+LFE+SL+SR and FL+FR+FC+LFE+BL+BR. For 5.1ch at least, the encoding order is the same as DTS.
https://github.com/nu774/qaac/wiki/Multichannel--handling.

Edit: Well there's something I didn't know. Looking at the info in the previous link, QAAC supports SL+SR and BL+BR as input but the output is always SL+SR. MediaInfo seems to be able to distinguish between the two for QAAC encoded files, but foobar2000 treats 5.1ch AAC as RL+RR either way. I tested an AAC file encoded with both ffmpeg and Nero with the same result, so maybe it's an AAC thing and only SL+SR is officially supported? Anyone know?

FLAC seems to support SL+SR and BL+BR, but once again foobar2000 displays both as RL+RR.

I'm pretty sure most container formats would be agnostic. If they can be used to store a particular flavour of audio they'd let it specify it's own channel layout.

HoraceMcMahon,
I think the golden rule is to never remap anything unless you know you need to. If you convert from one format to another the remapping process should be taken care of automatically. The source is decoded in standard wave file format and the encoder remaps as it sees fit.

ffmpeg detected my DTS test file as 5.1ch(side) and all that was required to convert it to PCM in a MOV container was this:

ffmpeg -i test.dts -acodec pcm_s24le output.mov

For my AAC 5.1ch(side) test file, I had to inform ffmpeg of the distinction:

ffmpeg -i test.aac -filter "channelmap=channel_layout=5.1(side)" -acodec pcm_s24le output.mov

For combining six individual wave files:

ffmpeg -i FL.wav -i FR.wav -i FC.wav -i LFE.wav -i SL.wav -i SR.wav -filter_complex "join=inputs=6:channel_layout=5.1(side):map=0. 0-FL|1.0-FR|2.0-FC|3.0-LFE|4.0-SL|5.0-SR" output.flac

Thinking about it, if the input files are in the correct order the mapping is probably redundant:

ffmpeg -i FL.wav -i FR.wav -i FC.wav -i LFE.wav -i SL.wav -i SR.wav -filter_complex "join=inputs=6:channel_layout=5.1(side)" output.flac

By the way, I noticed the part of the command line specifying 24 bit signed PCM is being ignored when the output is a MOV container and what you get is 24 bit unsigned PCM instead. I don't know why. Maybe it's a limitation of the MOV container but 16 bit behaves and the output is 16 bit signed. Just thought I'd mention it....

[HoraceMcMahon]

Wow, lots of great replies. I appreciate everyone's feedback and expertise.

According to someone here, there's only one 5.1ch format for DTS, and that's FL+FR+FC+LFE+SL+SR. The actual encoding order is FC+FL+FR+SL+SR+LFE.

What is the "encoding order" distinction, practically? Do you mean to say that any program playing/decoding DTS will read it as FL+FR+FC+LFE+SL+SR, but the order within the file is different?

ffmpeg it detected my DTS test file as 5.1ch(side) and all that was required to convert it to PCM in a MOV container was this:

ffmpeg -i test.dts -acodec pcm_s24le output.mov

In my case, as mentioned in the OP, using just that command, I get a 5.1 -- not a 5.1(side) -- file, and channels play back scrambled: the center channel when played back through VLC and Quicktime seems mapped to the left channel. I have no idea why this is, as it plays fine in MPC-HC and everything is in the right order when checked in Adobe Audition.

By the way, I noticed the part of the command line specifying 24 bit signed PCM is being ignored when the output is a MOV container and what you get it 24 bit unsigned PCM instead. I don't know why. Maybe it's a limitation of the MOV container but 16 bit behaves and the output is 16 bit signed. Just thought I'd mention it....

I didn't notice that before, but true in my case as well.

For combining six individual wave files:

ffmpeg -i A.wav -i B.wav -i C.wav -i D.wav -i E.wav -i F.wav -filter_complex "join=inputs=6:channel_layout=5.1(side):map=0. 0-FL|1.0-FR|2.0-FC|3.0-SL|4.0-SR|5.0-LFE" output.flac

You placed the LFE channel at the end rather than in the 4th channel spot, but this code works for my purposes! I get a FLAC that's 5.1(side), not 5.1 (not possible without the channel_layout and map parameters, it seems). I'm still not 100% on what practical difference there is on a 5.1 system between "side" and "back," but I'm glad to have this edited version of the original DTS-HD file mapped as was the original.

[hello_hello]

Wow, lots of great replies. I appreciate everyone's feedback and expertise.

According to someone here, there's only one 5.1ch format for DTS, and that's FL+FR+FC+LFE+SL+SR. The actual encoding order is FC+FL+FR+SL+SR+LFE.

What is the "encoding order" distinction, practically? Do you mean to say that any program playing/decoding DTS will read it as FL+FR+FC+LFE+SL+SR, but the order within the file is different?

Correct. If you look at the QAAC link I posted, you'll see the same applies. As it does for AC3. The wave file format is the common "intermediate" format. http://avisynth.nl/index.php/GetChannel

ffmpeg it detected my DTS test file as 5.1ch(side) and all that was required to convert it to PCM in a MOV container was this:

ffmpeg -i test.dts -acodec pcm_s24le output.mov

In my case, as mentioned in the OP, using just that command, I get a 5.1 -- not a 5.1(side) -- file, and channels play back scrambled: the center channel when played back through VLC and Quicktime seems mapped to the left channel. I have no idea why this is, as it plays fine in MPC-HC and everything is in the right order when checked in Adobe Audition.

I'd put the scrambled issue down to the audio being unsigned and the player having a hissy. Try the same thing again but with a 16 bit output so it's signed and see what happens. I'm not sure about the 5.1ch(side) issue.

For combining six individual wave files:

ffmpeg -i A.wav -i B.wav -i C.wav -i D.wav -i E.wav -i F.wav -filter_complex "join=inputs=6:channel_layout=5.1(side):map=0. 0-FL|1.0-FR|2.0-FC|3.0-SL|4.0-SR|5.0-LFE" output.flac

You placed the LFE channel at the end rather than in the 4th channel spot, but this code works for my purposes! I get a FLAC that's 5.1(side), not 5.1 (not possible without the channel_layout and map parameters, it seems). I'm still not 100% on what practical difference there is on a 5.1 system between "side" and "back," but I'm glad to have this edited version of the original DTS-HD file mapped as was the original.

My bad. It looks like I edited my previous post while you were writing yours and I still got it wrong. I'll go back and fix it, but I probably should have put the input files in the standard wave file order. I had to mess around a bit to get it to work myself, and I'm easily confused.....

For combining six individual wave files:
ffmpeg -i FL.wav -i FR.wav -i FC.wav -i LFE.wav -i SL.wav -i SR.wav -filter_complex "join=inputs=6:channel_layout=5.1(side):map=0. 0-FL|1.0-FR|2.0-FC|3.0-LFE|4.0-SL|5.0-SR" output.flac

Thinking about it, if the input files are in the correct order the mapping is probably redundant:
ffmpeg -i FL.wav -i FR.wav -i FC.wav -i LFE.wav -i SL.wav -i SR.wav -filter_complex "join=inputs=6:channel_layout=5.1(side)" output.flac

I think that's correct now, but obviously if you keep the mapping part, the order of the input files doesn't matter because the mapping can be used to change it.

I'm still not 100% on what practical difference there is on a 5.1 system between "side" and "back," but I'm glad to have this edited version of the original DTS-HD file mapped as was the original.

I'm really not sure what the distinction is between "side" and "back", or "rear" as I've always called it. I've never been into surround sound myself.... having the sound surround me is just a constant reminder the picture doesn't.... but I suspect back when it all began SL and SR meant surround left and surround right and the meaning has changed over time to accommodate more speakers. Just a theory....
I asked Dolby, and from the picture it looks like they consider the other pair of stereo speakers in a 5.1ch setup belong either side of the listener.
http://www.dolby.com/us/en/guide/surround-sound-speaker-setup/5-1-setup.html

Mediainfo's "Channel positions" (not the same as " channel layout" apparently) tells me "Front L C R, Side L R LFE" no matter what file I give it, and for files whose channel layout's are certainly different.

I think changing the order according to the format would confuse things. It'd be like having input or output meters on an amplifier that keep changing. For the record, MediaInfo uses the internal order for AC3 5.1ch encoding, although it does distinguish between "side" and "back" for formats that can be either. Most programs use the wave file channel order. If you import a 5.1ch file into Audacity it'll always be imported as individual channels in wave file order regardless of the format. FL FR FC LFE SL SR.

[Cornucopia]

but I suspect back when it all began SL and SR meant surround left and surround right and the meaning has changed over time to accommodate more speakers. Just a theory....

No, that pretty much nailed it.
Only with the advent of 7.1, 9.1...was it necessary to specify B=Back and S=Side. IMO, given the expansion beyond to 22.2, etc. it might even make more sense to do away with that and give clock or radial positions.

MediaInfo just gives a "listing", not actually correctly describing (numerical) order. It is still quite incomplete in this area.

Remember: how would one describe a supposed "order" to a 3dimensional physical placement? Which one has "precedence" and is the starting point? It's only because of its outgrowth from 1 & 2 channel tape-based origins that it makes any sense, And once multi-channel appeared, it needed to be incorporated as "pairs" of channels, so for backward-compatibility purposes, it makes much sense to use the SMPTE (WAV, AC3, FLAC...) ordering. FL + FR (- stereo front pair), C + LFE (- extra pair), SL + SR (or BL + BR if you want - stereo surround pair).

As far as whether the surround should be placed on the side or in the back, that is partly determined by the intention of the mixing engineer/producer, partly by the layout of your environment, and partly by your own tastes. But there are recommended practices, based on whether you intend to use it more for music or movie reproduction, or something entirely different. IMO, that is one of the major cool features of object-based formats such as Atmos: the receiver/amp takes into account your own environment (room & speaker placement) for rendering the proper phantom imaging.

Scott

[pandy]

DTS use name side for effect channels located between front and rear, Dolby is less obvious - for side they use name surround channel but for rear surround they are consistent with DTS and they use name rear.

[hello_hello]

And once multi-channel appeared, it needed to be incorporated as "pairs" of channels, so for backward-compatibility purposes, it makes much sense to use the SMPTE (WAV, AC3, FLAC...) ordering. FL + FR (- stereo front pair), C + LFE (- extra pair), SL + SR (or BL + BR if you want - stereo surround pair).

I think I had a dream about this last night.

There probably is a reason why AAC and DTS use the channel ordering they do. I'd mostly forgotten about it, but if I've remembered correctly there's three types of audio elements for multichannel AAC. There's a SCE (single channel element) a CPE (channel pair element) and the LFE (low frequency element). The LFE element is independent of the others.
AAC also has strict but slightly convoluted rules regarding the order of elements, although the basics of it are.....
CPEs are left and right channels, and SCEs are also paired left and right, with a possible exception when they're first or last. If a stream begins with an odd number of SCEs the first one is the center channel, if it begins with an even number, they're the left and right channels. That covers all the predefined AAC channel layouts (although in theory an encoder can use a custom channel order) and it probably increases the likelihood of broken streams being decoded correctly. The audio always starts in the center channel if it begins with an odd number of SCEs and then expands to front stereo, sides, rear, and rear center etc.... The LFE is a special type of SCE. For DTS I think it's even a separate stream.
http://hsevi.ir/RI_Standard/File/8898

And not that I know anything about writing software, but it did occur to me the encoding layouts probably make creating the encoder itself easier.
https://github.com/nu774/qaac/wiki/Multichannel--handling
Most of the layouts are a combination of stereo channels with a single channel tacked on the front and maybe one on the end. Only 6.1ch deviates from that which is maybe why FDKAAC doesn't support it. http://wiki.hydrogenaud.io/index.php?title=Fraunhofer_FDK_AAC#Channel_Layouts
It's probably why when I tried to create some 3.1ch AAC files a while back I couldn't do it. There's nothing in the AAC spec preventing it that I know of, but the encoders wouldn't do it. I guess none of them are "wired" for random channel orders because they don't need to be.

[mulvya]

It's probably why when I tried to create some 3.1ch AAC files a while back I couldn't do it. There's nothing in the AAC spec preventing it that I know of, but the encoders wouldn't do it. I guess none of them are "wired" for random channel orders because they don't need to be.

Pretty much: Native AAC encoder does not respect channelmap assignments.

[hello_hello]

It's probably why when I tried to create some 3.1ch AAC files a while back I couldn't do it. There's nothing in the AAC spec preventing it that I know of, but the encoders wouldn't do it. I guess none of them are "wired" for random channel orders because they don't need to be.

Pretty much: Native AAC encoder does not respect channelmap assignments.

I thought I'd give it a spin, given it's pretty easy to matrix a multichannel file into the quad(side) layout for testing using foobar2000.

FDKAAC spat it out.
FhGAAC silently remapped it to 4ch. I think that's a bit naughty.
NeroAAC gave me a quad(side) file as requested.
QAAC was happy to produce a quad(side) file.
ffmpeg spat it out while converting to AAC, but happily gave me a quad(side) FLAC or AC3 output.

[mulvya]

Does ffmpeg preserve quad(side) when muxing the Apple or Nero output into a mp4 container?

[hello_hello]

Yes. Well I didn't try muxing as such, just piping ffmpeg's output to NeroAacEnc. I can't imagine why it wouldn't keep the channel layout when just muxing.

For a quick test with a flac quad file that MediaInfo says looks like this:

Front: L R, Back: L R

The following three command lines all produced the same result, according to MediaInfo:

ffmpeg -i test.flac -f wav - | neroAacEnc.exe -q 0.5 -ignorelength -if - -of test.m4a
ffmpeg -i test.flac -filter "channelmap=channel_layout=quad" -f wav - | neroAacEnc.exe -q 0.5 -ignorelength -if - -of test.m4a
ffmpeg -i test.flac -filter "channelmap=channel_layout=quad(side)" -f wav - | neroAacEnc.exe -q 0.5 -ignorelength -if - -of test.m4a

which was:

Front: L R, Side: L R

It looks like AAC can't distinguish between quad and quad(side), but quad(side) is what you want anyway.

To double check MediaInfo was getting it right I tried this command line:

ffmpeg -i test.flac -filter "channelmap=channel_layout=4.0" -f wav - | neroAacEnc.exe -q 0.5 -ignorelength -if - -of test.m4a

and the result was this:

Front: L C R, Side: C

[hello_hello]

"Surround" vs "Side" vs "Back".

I spent a bit of time chatting with the internet about AAC 5.1ch audio today, and then that flash player crap crashed the browser, and I couldn't be bothered hunting for all the links again, but......

I did find out when MediaInfo stopped using the description "surround" and replaced it with "side". March 2010..... there was some method to the madness.

The internet didn't supply me with any real connection between 5.1ch audio and a layout using the "back" speakers in wave file format.
FL+FR+FC+LFE+BL+BR
Except the EBU specification for multichannel Bwav files which says 5.1ch uses "back" for surround in wave file format, but that's the only connection I found.
I discovered today the WAVE-FORMAT-EXTENSIBLE system includes a few pre-defined layouts. "5.1ch" is one, and "5.1ch surround" is another. The latter uses the "side speakers"
FL+FR+FC+LFE+SL+SR

Back in the dark ages, before WAVE-FORMAT-EXTENSIBLE was the norm, when 5.1ch mapping was almost as messy as 7.1ch is today, encoders sometimes decided on the layout according to the number of input channels, and I expect they sometime still do, so in that respect FL+FR+FC+LFE+BL+BR probably made sense, but it's becoming more common for surround to be mapped to side.

For codecs such as AAC that use the SMPTE channel layout (nothing to do with the actual encoding order) the surround channel layout accepted as input (back or side) seems to be up to the encoder and how it's decoded is up the the decoder. The current convention is to accept both "back" and "side" as surround and to decode surround as "side". All the lossy encoders I've tested, everything from AC3 to Ogg to Opus.... accept either.

As best as I can tell (and I'm restricted to what the internet will tell me or what I can work out by decoding), none of the lossy formats distinguish between "back" and "side". I said in an earlier post I thought QAAC did, but I must have been confused as now I'm sure that's wrong.

(Stuff deleted here as the next post has a more accurate list of how 5.1ch is decoded, hopefully)

So how do you encode 5.1ch audio as specifically either "side" or "back"? By encoding it losslessly with an encoder that keeps the WAVE-FORMAT-EXTENSIBLE layout rather than assuming it's SMPTE, and even then you've got to hope the decoder respects that. The official flac encoder and wavepack make up the entire list so far.


A couple of fun things I discovered along the way..... as far as I can tell there's only two ways to compress every single channel layout from mono through to 7.1ch correctly, and that's with flac and wavepack. The latter seems to be trouble free, but for ffmpeg's flac it's a little decoder dependent for some formats. ie 5.1ch.

By default, the official flac doesn't support a lot of layouts. Just the standard SMPTE ones, although it does distinguish between "side" and "back".
However I stumbled on an old forum post. It mentioned a command line option "--channel-map=none". The way I interpreted the post it tells flac to ignore any channel mapping and use the default wave file layout according to the number of input channels, but I discovered it makes flac completely giddy over the WAVE-FORMAT-EXTENSIBLE system, so from that perceptive "--channel-map=none" seems to tell flac to ignore it's own predefined list of channel mappings when there's WAVE-FORMAT-EXTENSIBLE info and use that instead. That way it'll encode every layout from mono up to (and including) the three pesky 7.1ch layouts and they're all decoded correctly.... so far. I didn't know flac could do that. I haven't been able to find mention of "--channel-map=none" anywhere else, and it's not in the official documentation.

[hello_hello]

I discovered I'd made a mistake today, which %^$%ed me off enough to check everything thoroughly. Probably a complete waste of human endeavour, but I did it so for the sake of correctness, so here's what I discovered in case it helps anyone else. Hopefully it's correct. I'll check my previous post and edit it where it's wrong and I'll let my brain re-group and probably double check all this later.

For 5.1ch:
ffmpeg decodes the following by mapping the surround channels to the back channels in wave file format. ie L, R, C, LFE, BL, BR
AAC (M4A) - (FDKAAC, ffmpeg's AAC, NeroAAC, FhGAAC, QAAC)
Apple Lossless (M4A)
Opus
Ogg
WMA 9.2 (WMAEncode)
WMA 10 (WMAEncode)
ffmpeg decodes the following by mapping the surround channels to the side channels in wave file format ie L, R, C, LFE, SL, SR
AC3
DTS
ffmpeg decodes the following by mapping the surround channels to the channels specified in the file (back or side)
FLAC
Wave
Wavepack


ffdshow decodes the following by mapping the surround channels to the back channels in wave file format ie L, R, C, LFE, BL, BR
AAC
AC3
DTS
FLAC
OGG
WMA 10
ffdshow decodes the following by mapping the surround channels to the side channels in wave file format ie L, R, C, LFE, SL, SR
Apple Lossless (M4A)
Opus
ffdshow decodes the following by mapping the surround channels to the channels specified in the file (back or side)
Wave
ffdshow wouldn't decode wavepack for me and WMA 9.2 was only decoded as stereo.


MediaInfo mostly identifies 5.1ch as "side" (Front: L C R, Side: L R, LFE), except.....
Apple Lossless, ffmpeg encoder - identified as 6ch without channel assignments
Ogg - identified as 6ch without channel assignments
WMA 9.2 - identified as 2 ch without channel assignments
WMA 10 - identified as 6ch without channel assignments
MediaInfo identifies the following 5.1ch formats according to the channel mapping in the file (back or side)
Flac
Wave
Wavepack
MediaInfo completely breaks with it's own tradition for Opus, by identifying it as 5.1ch (rear)


Foobar2000 decodes the following so the surround channels are labelled "rear" ie L, R, C, LFE, RL, RR
AAC
AC3
Apple Lossless
FLAC - ffmpeg native encoder
OGG
Opus
QAAC
WMA 10
Foobar2000 decodes the following so the surround channels are labelled "side" ie L, R, C, LFE, SL, SR
DTS
Foobar2000 decodes the following by mapping the surround channels to the channels specified in the file, although instead of "back" it uses "rear".
FLAC - Official encoder
Wave
Wavepack
Foobar2000 would only decode WMA 9.2 as stereo.


The LAV Audio decoder always decodes to "side" by default, with a setting to change that to "back". It only decodes to one or the other regardless of the input type.

I'm still fairly sure none of it actually matters anyway. The surround channels are the surround channels and whether they're mapped to back or side in PC-Land doesn't seem to make any difference. I only have stereo speakers attached to this PC but as an experiment I put my sound card in 5.1ch mode and assigned the speakers to the surround channels. When I played a 5.1ch wave file I couldn't hear the front left/right, centre or LFE channels but I could hear the surround channels in both 5.1ch (side) and 5.1ch (back) wave files.

[overlookmotel]

Horace did you ever get to the bottom of this? I'm having exactly the same problem, with a 5.1 MOV file created in FFMPEG playing back in VLC with the centre channel coming through the left speaker only. (this is with VLC downmixing the 5.1 to stereo - I only have 2 speakers).

The input to FFMPEG is a ProRes MOV with 3 x stereo audio streams making up the 6 channels of the 5.1 mix. The ProRes was exported from Final Cut Pro 7. The output is ProRes MOV with 1 stream with 6 channels.

Input and output files and both definitely have the tracks ordered correctly - L R C LFE Ls Rs. I've checked this in both Final Cut Pro 7 and DCP-o-matic.

I've tried setting FFMPEG's output layout to 5.1 and 5.1(side) and it makes no difference. In VLC it plays back with the centre channel being played through left only.

Here's my FFMPEG command:

ffmpeg -i input.mov -filter_complex "[0:1]pan=FL|c0=c0[ch0];[0:1]pan=FR|c0=c1[ch1];[0:2]pan=FC|c0=c0[ch2];[0:2]pan=LFE|c0=c1[ch3];[0:3]pan=SL|c0=c0[ch4];[0:3]pan=SR|c0=c1[ch5];[ch0][ch1][ch2][ch3][ch4][ch5]amerge=inputs=6[aout]" -c:v copy -c:a pcm_s16le -map 0:0 -map [aout] output.mov
# NB stream 0 is video, streams 1-3 the 3 x stereo audio streams

Cornucopia mentioned earlier in this thread that "MOV container (and by extension, MP4) has NAMED channels and so will tell you exactly how (in what order) those channels are listed, whether using industry convention order (SMPTE/AES/EBU) or not. Unless I'm mistaken, for those formats, the order does not matter, as they are retrieved by name, not number."

Sounds like quite possibly the cause here is that the Quicktime metadata naming the channels isn't being created by FFMPEG. Any idea how to fix that?

If anyone can help, would hugely appreciate it.

Full FFMPEG console output:

ffmpeg -i Maya\ 5.1\ fixed\ 3x2ch.mov -c:v copy -c:a pcm_s16le -c:d copy -filter_complex "[0:1]pan=FL|c0=c0[ch0];[0:1]pan=FR|c0=c1[ch1];[0:2]pan=FC|c0=c0[ch2];[0:2]pan=LFE|c0=c1[ch3];[0:3]pan=SL|c0=c0[ch4];[0:3]pan=SR|c0=c1[ch5];[ch0][ch1][ch2][ch3][ch4][ch5]amerge=inputs=6[aout]" -map 0:0 -map [aout] Maya_merged2.mov;
ffmpeg version 2.8.5 Copyright (c) 2000-2016 the FFmpeg developers
built with Apple LLVM version 7.0.2 (clang-700.1.81)
configuration: --prefix=/usr/local/Cellar/ffmpeg/2.8.5 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-opencl --enable-libx264 --enable-libmp3lame --enable-libvo-aacenc --enable-libxvid --enable-vda
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 60.100 / 56. 60.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 40.101 / 5. 40.101
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Guessed Channel Layout for Input Stream #0.2 : stereo
Guessed Channel Layout for Input Stream #0.3 : stereo
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Maya 5.1 fixed 3x2ch.mov':
Metadata:
major_brand : qt
minor_version : 537199360
compatible_brands: qt
creation_time : 2016-05-10 19:30:51
Duration: 00:15:46.79, start: 0.000000, bitrate: 110268 kb/s
Stream #0:0(eng): Video: prores (apcn / 0x6E637061), yuv422p10le(bt709), 2048x858, 105641 kb/s, 24 fps, 24 tbr, 24 tbn, 24 tbc (default)
Metadata:
creation_time : 2016-05-10 19:30:51
handler_name : Apple Alias Data Handler
encoder : Apple ProRes 422
timecode : 00:00:00:00
Stream #0:1(eng): Audio: pcm_s16le (sowt / 0x74776F73), 48000 Hz, 2 channels, s16, 1536 kb/s (default)
Metadata:
creation_time : 2016-05-10 19:30:51
handler_name : Apple Alias Data Handler
Stream #0:2(eng): Audio: pcm_s16le (sowt / 0x74776F73), 48000 Hz, 2 channels, s16, 1536 kb/s (default)
Metadata:
creation_time : 2016-05-10 19:30:51
handler_name : Apple Alias Data Handler
Stream #0:3(eng): Audio: pcm_s16le (sowt / 0x74776F73), 48000 Hz, 2 channels, s16, 1536 kb/s (default)
Metadata:
creation_time : 2016-05-10 19:30:51
handler_name : Apple Alias Data Handler
Stream #0:4(eng): Data: none (tmcd / 0x64636D74) (default)
Metadata:
creation_time : 2016-05-10 19:35:04
handler_name : Apple Alias Data Handler
timecode : 00:00:00:00
[Parsed_pan_0 @ 0x7f8188423da0] Pure channel mapping detected: 0
[Parsed_pan_1 @ 0x7f8188424160] Pure channel mapping detected: 1
[Parsed_pan_2 @ 0x7f81884244c0] Pure channel mapping detected: 0
[Parsed_pan_3 @ 0x7f8188424820] Pure channel mapping detected: 1
[Parsed_pan_4 @ 0x7f8188424b80] Pure channel mapping detected: 0
[Parsed_pan_5 @ 0x7f8188424e60] Pure channel mapping detected: 1
[mov @ 0x7f8189000000] Codec for stream 0 does not use global headers but container format requires global headers
Output #0, mov, to 'Maya_merged2.mov':
Metadata:
major_brand : qt
minor_version : 537199360
compatible_brands: qt
encoder : Lavf56.40.101
Stream #0:0(eng): Video: prores (apcn / 0x6E637061), yuv422p10le, 2048x858, q=2-31, 105641 kb/s, 24 fps, 24 tbr, 12288 tbn, 24 tbc (default)
Metadata:
creation_time : 2016-05-10 19:30:51
handler_name : Apple Alias Data Handler
encoder : Apple ProRes 422
timecode : 00:00:00:00
Stream #0:1: Audio: pcm_s16le (sowt / 0x74776F73), 48000 Hz, 5.1(side), s16, 4608 kb/s (default)
Metadata:
encoder : Lavc56.60.100 pcm_s16le
Stream mapping:
Stream #0:1 (pcm_s16le) -> pan
Stream #0:1 (pcm_s16le) -> pan
Stream #0:2 (pcm_s16le) -> pan
Stream #0:2 (pcm_s16le) -> pan
Stream #0:3 (pcm_s16le) -> pan
Stream #0:3 (pcm_s16le) -> pan
Stream #0:0 -> #0:0 (copy)
amerge -> Stream #0:1 (pcm_s16le)
Press [q] to stop, [?] for help
frame=22723 fps=176 q=-1.0 Lsize=12742555kB time=00:15:46.79 bitrate=110253.4kbits/s
video:12209495kB audio:532570kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.003845%