VideoHelp Forum

+ Reply to Thread
Results 1 to 9 of 9
Thread

Threaded View

  1. this is my ffmpeg command

    Code:
    -c:v copy -c:a aac -cutoff 20K -b:a 256K
    source audio
    Code:
    Channel positions                        : Front: L C R, Side: L R, LFE
    output audio
    Code:
    Channel positions                        : Front: L C R, Side: C, Back: L R
    any help please?
    Quote Quote  
  2. Can you upload small samples of the source and output?
    How are you determining the channel positions? Are you using an old version of MediaInfo?

    "Side L/R" and "Back L/R" are fairly interchangeable for 5.1ch audio.
    If you look at the wave file channel order here:
    http://dream.cs.bath.ac.uk/researchdev/wave-ex/wave_ex.html
    you'll see the first six channels cover the 5.1ch audio layout if "Back L/R" are used for the surround channels. These days (mainly due to 7.1ch becoming common) "Side L/R" are commonly used for the 5.1ch surround channels, but "Side L/R" or "Back L/R" shouldn't matter, which possibly just leaves "Side: C" as an apparently oddly labelled LFE channel.

    By the way, MediaInfo previously displayed the channel layout using the wave file channel order, regardless of the audio format. These days, it displays them in their encoded order (different formats use different channel orders).
    For example, AC3 looks like this.
    L R C LFE Ls Rs
    but after it's encoded as AAC it'll display as
    C L R Ls Rs LFE
    That sort of thing is normal and doesn't indicate the channels have been "swapped", so to speak.
    Quote Quote  
  3. sorry for late reply

    here is a sample file
    https://www45.zippyshare.com/v/DUvrbxOI/file.html

    as normal human listen, i can say there is a big difference output sounds direction
    Quote Quote  
  4. The LFE & surround channels are empty, but that doesn't matter, as everything seems okay.
    I used the following command line (you can ignore the -y and -threads arguments).

    -report -i "D:\TEST.mkv" -y -threads 1 -c:v copy -c:a aac -cutoff 20K -b:a 256K "D:\TESTed.mkv"

    The ffmpeg log file says the right thing (it's attached below).

    [aac @ 056dd740] Using a PCE to encode channel layout "5.1(side)"

    I checked the AAC audio with ffdshow and foobar2000. They display the channels in different orders, but both show the channels containing audio are where they should be.

    Both versions of MediaInfo I used to check the audio appear to be getting it wrong though.

    Channel layout : L R C Cb Lb Rb

    Channel positions: Front: L C R, Side: C, Back: L R

    Edit: There does seem to be something odd about the way the ffmpeg encoded AAC stores the channel layout, now I've delved into it some more with MediaInfo in debug mode, but I'm not sure if it'd generally cause problems other than MediaInfo getting the layout wrong. I'll play around some more later and post back if I discover anything interesting.

    Image
    [Attachment 59240 - Click to enlarge]


    Image
    [Attachment 59241 - Click to enlarge]
    Image Attached Files
    Last edited by hello_hello; 3rd Jun 2021 at 05:00.
    Quote Quote  
  5. I've added a ticket to the ffmpeg bug tracker regarding this issue, It's here.
    https://trac.ffmpeg.org/ticket/7384#comment:14

    From what I understand AAC audio is encoded as elements. SCE (single channel element), CCE (a stereo element) and LFE. The spec tells you what order they should be stored in. For 5.1ch order it's SCE, CCE, CCE, LFE. AAC encoded by ffmpeg seems to store them as CCE, SCE, SCE, CCE.
    Up until recently, I don't think ffmpeg used PCE's. They provide more info about the channel assignments, but there'd probably be enough information in the elements themselves for a decoder to assign them to the correct channels, probably even if they were in the wrong order. It appears some decoders don't bother looking at the PCE info and still decode it correctly, but I assume others must do it according to the spec. If you read the ticket I posted it'll hopefully be clear why using PCE's is causing a problem now (I think), although I saw closed tickets on this subject going back years, so I assume in the past there's been decoders sticking to the spec and sending the audio to the wrong channels.
    Mostly, those tickets were closed and the blame put on the ambiguity between the back and side channels in wave file format, and which should be used for the surround channels. I don't think that's the problem though. I think it's the order the AAC elements are stored in the AAC stream, but we'll have to wait for a developer to reply to find out.
    Last edited by hello_hello; 3rd Jun 2021 at 09:37.
    Quote Quote  
  6. thank you so much taking your time to find out the issue and submitting the ticket. i found few app using ffmpeg and using neroAAC.exe separately (megui.exe/xvid4psp) for those audio channel working fine though. anyway currently i using AC3 probably 10~15% extra space using.
    Quote Quote  
  7. You're welcome.
    If you're using MeGUI you can also use QAAC and FDKAAC. I think they both need to be enabled in preferences. QAAC requires the relevant file be extracted from the itunes installer (or to have itunes installed) and you have to download FDKAAC yourself.

    Or if you download this version of foobar2000, it comes ready to encode with all five AAC encoders (it also includes FhGAAC).
    foobar2000 portable (for audio encoding)
    I mostly use foobar2000 for audio conversion myself.

    For the record, if you're encoding 7.1ch audio, use QAAC. It does it correctly.
    I researched it a while back and 7.1ch encoding was a serious mess. The only encoders being updated are QAAC and FDKAAC, so nothing will have changed. FFMPEG is obviously updated but I wouldn't trust it yet.
    7.1ch AAC encoding
    Quote Quote  
  8. thanks again for your all suggested app.
    Quote Quote  



Similar Threads