VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 31
Thread
  1. 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)?

    Code:
    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.
    Quote Quote  
  2. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by HoraceMcMahon View Post
    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.
    Last edited by El Heggunte; 13th Mar 2016 at 05:08. Reason: clarification
    Quote Quote  
  3. 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
    Quote Quote  
  4. 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.

    Code:
    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?
    Quote Quote  
  5. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    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
    Quote Quote  
  6. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    FWIW:

    Code:
    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
    Quote Quote  
  7. 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?
    Quote Quote  
  8. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by HoraceMcMahon View Post
    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.
    Last edited by El Heggunte; 13th Mar 2016 at 21:43. Reason: damn typos :-/
    Quote Quote  
  9. Originally Posted by El Heggunte View Post
    ...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):
    Code:
    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.
    Quote Quote  
  10. Originally Posted by El Heggunte View Post
    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).

    Originally Posted by HoraceMcMahon View Post
    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.
    Code:
    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
    Quote Quote  
  11. Member
    Join Date
    Jul 2012
    Location
    FrogLand
    Search PM
    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 :
    Click image for larger version

Name:	5.1.PNG
Views:	2567
Size:	43.9 KB
ID:	36157


    I also have a little routine with FFQueue and the 5.1 channel remap filter, if you feel like using it. ^^
    But try Cliptoolz
    Last edited by CyberOtter; 14th Mar 2016 at 04:02. Reason: details
    Quote Quote  
  12. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Originally Posted by CyberOtter View Post
    ..........
    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):

    Code:
    http://www.mudgee.net/ClipToolz-Convert-V2.msi
    Notice: I have not tested it yet.
    Last edited by El Heggunte; 14th Mar 2016 at 04:41. Reason: rectification
    Quote Quote  
  13. Member
    Join Date
    Jul 2012
    Location
    FrogLand
    Search PM
    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
    Quote Quote  
  14. Originally Posted by pandy View Post
    Code:
    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.
    Quote Quote  
  15. Originally Posted by HoraceMcMahon View Post
    Originally Posted by pandy View Post
    Code:
    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

    Code:
    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
    Quote Quote  
  16. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    Hmmm, I *suppose* that I have started to understand what is the _actual_ problem......

    Originally Posted by HoraceMcMahon View Post
    .......
    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).
    Last edited by El Heggunte; 14th Mar 2016 at 16:17. Reason: typo
    Quote Quote  
  17. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    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
    Last edited by Cornucopia; 14th Mar 2016 at 17:47.
    Quote Quote  
  18. 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....

    Click image for larger version

Name:	mov.gif
Views:	1673
Size:	33.7 KB
ID:	36185
    Last edited by hello_hello; 17th Mar 2016 at 14:32.
    Quote Quote  
  19. Wow, lots of great replies. I appreciate everyone's feedback and expertise.

    Originally Posted by hello_hello View Post
    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?

    Originally Posted by hello_hello View Post
    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.

    Originally Posted by hello_hello View Post
    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.

    Originally Posted by hello_hello View Post
    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.
    Quote Quote  
  20. Originally Posted by HoraceMcMahon View Post
    Wow, lots of great replies. I appreciate everyone's feedback and expertise.

    Originally Posted by hello_hello View Post
    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

    Originally Posted by HoraceMcMahon View Post
    Originally Posted by hello_hello View Post
    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.

    Originally Posted by HoraceMcMahon View Post
    Originally Posted by hello_hello View Post
    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.

    Originally Posted by HoraceMcMahon View Post
    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

    Originally Posted by HoraceMcMahon View Post
    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.
    Last edited by hello_hello; 15th Mar 2016 at 00:04.
    Quote Quote  
  21. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    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
    Quote Quote  
  22. 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.
    Quote Quote  
  23. Originally Posted by Cornucopia View Post
    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.
    Last edited by hello_hello; 17th Mar 2016 at 06:16.
    Quote Quote  
  24. Member
    Join Date
    Aug 2014
    Location
    India
    Search Comp PM
    Originally Posted by hello_hello View Post
    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.
    Quote Quote  
  25. Originally Posted by mulvya View Post
    Originally Posted by hello_hello View Post
    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.
    Quote Quote  
  26. Member
    Join Date
    Aug 2014
    Location
    India
    Search Comp PM
    Does ffmpeg preserve quad(side) when muxing the Apple or Nero output into a mp4 container?
    Quote Quote  
  27. 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
    Quote Quote  
  28. "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.
    Last edited by hello_hello; 31st Mar 2016 at 20:54.
    Quote Quote  
  29. 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.
    Last edited by hello_hello; 1st Apr 2016 at 03:09.
    Quote Quote  
  30. 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%
    Quote Quote  



Similar Threads