Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Multi-channel encoding – rationale for re-mapping channels (Read 7734 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Multi-channel encoding – rationale for re-mapping channels

TLDR VERSION:
Can anybody here shed any light on the reason that the Opus (and Vorbis) encoder re-map side audio channels on a 5.1 audio stream?

VERBOSE VERSION:
As I'm sure many of you are aware, one of the compromises involved in maintaining a healthy relationship is that a man is often forced to sit and watch TV shows with his wife or girlfriend.  As someone who formerly didn't really watch any TV other than sport, I've endured some appalling rubbish over the years but it wasn't all wasted time; fortunately, I've uncovered some wheat amidst all the chaff.

What are they?  Well, in my experience, four shows stand head-and-shoulders above the rest and were truly beguiling, enriching experiences (for those interested, they are The Wire, The Sopranos, Breaking Bad and Game Of Thrones).  Nothing else came close.  So, much as I do with music, I purchased the media in the best quality available (Blu-ray in this instance) in order to add them to my digital library.

I went through the laborious process of backing-up each disc and ripping the content to make a personal copy for a home server (thankfully, I did this before the UK government changed the law on making private copies because, of course, that would have made an enormous difference to my behaviour).  I prefer free, open-source software so had some decisions to make when re-encoding the video and audio streams.  For video, I opted for the more mature x264 over VP9.  For audio I went with Opus over Vorbis or FDK AAC.

So, I took my many hard drives brimming with data, fired up the computer and set up a script to encode with ffmpeg.  Around half-way through the lengthy encoding process, a cursory check of mediainfo informed me that the original DTS-HD MA channel layout (Front: L C R, Side: L R, LFE) had been altered in the output files to Front: L C R, Rear: L R, LFE.  Odd, I thought to myself.

Whilst this isn't a problem for me, I wondered whether this was an ffmpeg quirk so ran a portion of the original stream through the standalone Opus encoder.  Sure enough, the terminal reported that the side channels were being re-mapped to the rear by the encoder.  Ditto for the Vorbis encoder.

Thus I have the following questions that perhaps someone here could answer:
- What is the rationale behind this re-mapping?  Am I right to assume it enforces some kind of 'correct' 5.1 audio standard?
- If so, should it be the job of the encoder to enforce such a standard?  Should an encoder's remit be to simply reproduce whatever is fed into it, and do so as accurately as possible unless specified?
- Is this re-mapping a purely nominal thing whereby only the word 'Side' has been changed to 'Rear', with little or no change to the audio streams?
- Is there a switch to toggle this arbitrary action that is not listed in the Opus man page?
- Could I possibly be the only person in the world who is interested in the answers to these questions?!

[Edit: added hyperlink]

Multi-channel encoding – rationale for re-mapping channels

Reply #1 –
Vorbis channel order:

Quote
Vorbis I specifies only a channel mapping type 0. In mapping type 0, channel mapping is implicitly defined as follows for standard audio applications. As of revision 16781 (20100113), the specification adds defined channel locations for 6.1 and 7.1 surround. Ordering/location for greater-than-eight channels remains ’left to the implementation’.

These channel orderings refer to order within the encoded stream. It is naturally possible for a decoder to produce output with channels in any order. Any such decoder should explicitly document channel reordering behavior.

one channel
the stream is monophonic
two channels
the stream is stereo. channel order: left, right
three channels
the stream is a 1d-surround encoding. channel order: left, center, right
four channels
the stream is quadraphonic surround. channel order: front left, front right, rear left, rear right
five channels
the stream is five-channel surround. channel order: front left, center, front right, rear left, rear right
six channels
the stream is 5.1 surround. channel order: front left, center, front right, rear left, rear right, LFE
seven channels
the stream is 6.1 surround. channel order: front left, center, front right, side left, side right, rear center, LFE
eight channels
the stream is 7.1 surround. channel order: front left, center, front right, side left, side right, rear left, rear right, LFE
greater than eight channels
channel use and order is defined by the application


As you see, there is no 5.1 layout with side channels.

Multi-channel encoding – rationale for re-mapping channels

Reply #2 –
Quote from: lvqcl on
Vorbis channel order:

Quote
Vorbis I specifies only a channel mapping type 0. In mapping type 0, channel mapping is implicitly defined as follows for standard audio applications. As of revision 16781 (20100113), the specification adds defined channel locations for 6.1 and 7.1 surround. Ordering/location for greater-than-eight channels remains ’left to the implementation’.

These channel orderings refer to order within the encoded stream. It is naturally possible for a decoder to produce output with channels in any order. Any such decoder should explicitly document channel reordering behavior.

one channel
the stream is monophonic
two channels
the stream is stereo. channel order: left, right
three channels
the stream is a 1d-surround encoding. channel order: left, center, right
four channels
the stream is quadraphonic surround. channel order: front left, front right, rear left, rear right
five channels
the stream is five-channel surround. channel order: front left, center, front right, rear left, rear right
six channels
the stream is 5.1 surround. channel order: front left, center, front right, rear left, rear right, LFE
seven channels
the stream is 6.1 surround. channel order: front left, center, front right, side left, side right, rear center, LFE
eight channels
the stream is 7.1 surround. channel order: front left, center, front right, side left, side right, rear left, rear right, LFE
greater than eight channels
channel use and order is defined by the application


As you see, there is no 5.1 layout with side channels.


Thanks for replying, lvqcl.  Yes, according to the Vorbis spec, there is no 5.1 layout with side channels but this just raises more questions for me.

My query is about the rationale behind the decision to use this 'channel mapping type 0', so I'm interested in who formulated it and why.  Searching appears to yield very little about 'channel mapping type 0' as a standalone concept, which leads me to wonder whether it is a generally accepted principle or specific to Vorbis/Opus spec.  Is it a purely arbitrary decision someone made early on or does it refer to some standardised principle?

Also, I've just done some further fiddling around with ffmpeg and MediaInfo and found the following behaviour:

- When fed a 5.1 source with Front: L C R, Side: L R, LFE
   -Opus and Vorbis re-map channels from 'side' to 'rear'
   -FLAC, FDK AAC and AC-3 perform no re-mapping

- When fed a 5.1 source with Front: L C R, Rear: L R, LFE
   -FDK AAC and AC-3 re-map channels from 'rear' to 'side'
   -FLAC, Opus and Vorbis perform no re-mapping

So it looks like Opus and Vorbis exclusively use the 'Rear' mapping layout (as defined in the Vorbis spec) while FDK AAC and AC-3 exclusively use the 'Side' mapping layout (as defined in ?).  FLAC simply takes what it's given and spits out the same layout.

Now this is all fine and dandy, but it still doesn't cast any light on who, how or why Vorbis/Opus decided on the 'type 0' layout, or indeed why FDK and AC-3 use a different layout.

Once again, it makes no difference to me whether output files use 'side' or 'rear'/'back' layout in practical terms.  I'm just curious about the decision-making process.

Multi-channel encoding – rationale for re-mapping channels

Reply #3 –
I know it won't help, but I can tell you the decision-making process for Opus: "don't reinvent the wheel, do what Vorbis does".

Multi-channel encoding – rationale for re-mapping channels

Reply #4 –
Quote
- When fed a 5.1 source with Front: L C R, Side: L R, LFE
-Opus and Vorbis re-map channels from 'side' to 'rear'

How can the 5.1 stream include side channels?
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

Multi-channel encoding – rationale for re-mapping channels

Reply #5 –
Quote from: jmvalin on
I know it won't help, but I can tell you the decision-making process for Opus: "don't reinvent the wheel, do what Vorbis does".

Thanks, jmvalin.  Yeah, I assumed that was the case.

As an aside, I wanted to ask you whether there is any recommended Opus bitrate setting for 5.1 and 7.1 audio streams.  I couldn't find anything specific so, for 5.1, I went with the ffmpeg equivalent of:
Code: [Select]
opusenc --bitrate 480 "$input" "$output"

I used the 'Example Bitrate Calculation' section from the FDK AAC wiki to arrive at this decision.  The output sounds great through my living room surround system (which I guess is ultimately what matters) but just wanted to check if there are any recommendations that might save me precious disk space.

Multi-channel encoding – rationale for re-mapping channels

Reply #6 –
Quote from: smok3 on
Quote
- When fed a 5.1 source with Front: L C R, Side: L R, LFE
-Opus and Vorbis re-map channels from 'side' to 'rear'

How can the 5.1 stream include side channels?


I know it seems odd so I just tried uploading some 5.1 test files to demonstrate what I'm referring to but it appears to be broken. [EDIT: Uploaded the test files here: https://www.hydrogenaud.io/forums/index.php?showtopic=110679]

DTS, AC-3 and FDK AAC appear to conform to a 5.1 standard which doesn't recognise rear channels, mapping in the following way: Front: L C R, Side: L R, LFE.

Conversely, Vorbis and Opus conform to a standard which does not recognise side channels in a 5.1 stream, mapping thus: Front: L C R, Rear: L R, LFE.

My usage involves encoding from DTS-HD MA to Opus, so I'm curious as to what, if anything, is happening with the channel mapping.

Are we allowed to post links to storage hosts in place of uploading?

[EDIT: Added question]
[EDIT 2: Added link to uploaded test files]

Multi-channel encoding – rationale for re-mapping channels

Reply #7 –
According to ISO 14496-3, AAC uses "left surround, right surround rear speakers" for 5.1 channels. Therefore, what mediainfo says seems incorrect. libavcodec maps 5.1ch AAC surround channels into WAV back channels.

Multi-channel encoding – rationale for re-mapping channels

Reply #8 –
Quote from: lothario15 on
My usage involves encoding from DTS-HD MA to Opus, so I'm curious as to what, if anything, is happening with the channel mapping.

It should simply treat side channels as rear channels.

BTW, some articles treat 5.1 as 3 front + 2 surround + 1 LFE. "Back" or "rear" is just a name for surround channel.
For example, http://www.aes.org/technical/documents/AESTD1001.pdf
Quote
The designation 3/2 therefore refers to the use of three front channels—left, center, right—and two rear/side channels—left surround and right surround.

Multi-channel encoding – rationale for re-mapping channels

Reply #9 –
If the Surround system is playing them correctly then that just should be fine.

My interpretation of it.

5.1 surrounds should be mapped to the side for anything related to movies on 7.1 system, but left alone on 5.1 surround system.  Based on speaker layout diagrams I've seen all over the web.

7.1 sides on 5.1 systems should be mapped to come between the front and surround channels with a -3 dB trim.  Not sure if this is even correct.

In 5.1 the so called sides or rears you're seeing are simply surrounds actually.

In 7.1 there is actually side and rear surrounds.

Multi-channel encoding – rationale for re-mapping channels

Reply #10 –
Thanks for the information, people.

Based on the evidence so far, it appears that use of the term 'rear', 'back' or 'side' doesn't necessarily represent speaker placement but is simply an arbitrary term relating to the 'surround' channels.

Additionally, it may all just be a quirk of mediainfo as to which term is actually used, possibly implying that the different terms all relate to the same channel mapping (i.e. the surround speakers are, in fact, always at the rear).

Reading through the 2001 AES paper, the reference 5.1 implementation places the surround speakers ever-so-slightly behind the target recipient of the sound.  This exactly mirrors the placement in my living room and, after playing samples of each type of mapping, I found there to be no perceptible difference between samples with 'rear', 'back' or 'side' surround mapping.

So I'm content to leave it at that and simply enjoy my encoded material.  Thanks everyone.

Multi-channel encoding – rationale for re-mapping channels

Reply #11 –
I guess, ffprobe certainly doesn't seem to bother to display either side or rear metadata (fdk_aac was used for encoding)
Code: [Select]
./ffprobe /Users/b/Downloads/5.1ch_test_file_rear.flac.mp4
ffprobe version N-76262-g2ccc1b3 Copyright (c) 2007-2015 the FFmpeg developers
  built with Apple LLVM version 7.0.0 (clang-700.0.72)
  configuration: --prefix=/Volumes/tempdisk/sw --enable-gpl --enable-pthreads --enable-version3 --enable-nonfree --enable-libx264 --enable-runtime-cpudetect --enable-libfdk-aac --cc=clang
...
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Users/b/Downloads/5.1ch_test_file_rear.flac.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    encoder         : Lavf57.11.100
  Duration: 00:00:09.10, start: 0.046440, bitrate: 37 kb/s
    Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, 5.1, fltp, 35 kb/s (default)
    Metadata:
      handler_name    : SoundHandler


or more with "ffprobe -select_streams a -show_streams file.mp4"
Code: [Select]
profile=LC
codec_type=audio
codec_time_base=1/44100
codec_tag_string=mp4a
codec_tag=0x6134706d
sample_fmt=fltp
sample_rate=44100
channels=6
channel_layout=5.1
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung