Add --no-surround to disable surround channel mapping assumptions

[JamesDunne]

Added --no-surround command-line option to disable surround-sound channel mapping assumptions made end-to-end from input to output.

Added --coupled n,m,... command-line option to specify a custom set of coupled channels when --no-surround is used for arbitrary stereo processing within the input channel set. Couplings are specified by the first channel number (1-based) of the pair to couple; multiple couplings are delimited by commas. For example, --coupled 1,4 means to couple 1/2 and 4/5, --coupled 1 means to only couple 1/2, --coupled 1,3,5 means to couple 1/2, 3/4, and 5/6, etc. All remaining input channels are assumed to be uncoupled.

[rillian]

Would --discrete or --discrete-channels make more sense for this use case? I worry --no-surround doesn't really make sense with two input channels.

How do you use the --coupled option? It seems like you could make it more flexible, so you could say --coupled 1:4,2:7 to couple tracks which aren't adjacent in the input WAV or FLAC.

BTW, one of the reasons opusenc assumes surround is that's what the input formats represent by default. Does your DAW write any Broadcast WAV metadata we could use to select a discrete multichannel encoding automatically?

[JamesDunne]

I think --no-surround makes sense for the option name. Currently, opusenc always uses opus_multistream_surround_encoder_create to create an encoder so apparently the surround v. no-surround distinction is not that important for 1- or 2-channel input sources; the surround encoder can handle it just fine. The --no-surround option allows the user to use the alternative opus_multistream_encoder_create function as well as explicitly disabling all treatment of the incoming audio as surround. If you feel --discrete-channels is a more appropriate name, I'm certainly not opposed. I'm just explaining what my rationale was.

My initial plan for --coupled was to do pretty much what you said with the more flexible variant of 1:4,2:7 for coupling arbitrary channels together but then I probably got confused reading the spec and assumed all coupled channels had to be sequential in the input. I realize that's only true for the internal mapping array that separates coupled from non-coupled. I can rewrite that to be more flexible.

My preferred DAW, Reaper, does not appear to offer any render options like specifying discrete vs. surround channel mapping. It does offer a Write BWF ('bext') chunk checkbox with some metadata generated from the project but I don't see anything else of interest. It does offer the choice of what specific kind of WAV file to emit, be it RF64 or RIFF. I would guess that for RF64 it'll encode channelMask based purely on the number of channels in the mix. The DAW doesn't "know" whether the mix it's rendering is surround or not. It's purely convention based.

It seems in the RF64 format (WAVE_FORMAT_EXTENSIBLE), the presence of channelMask indicates the desired channel mapping of the multichannel audio. I'm not sure anything can be inferred from the lack of such information in a legacy RIFF file. The de facto choice seems to infer that multichannel audio in RIFF format is surround, which is a safe bet.

[JamesDunne]

I updated the --coupled option to allow arbitrary channel couplings.

[JamesDunne]

Are there changes required for this PR to be accepted?

[daniel-sherwood]

I ams interested in this functionality. Is there any reason this wasn't merged?

[chris-hld]

This simple fix at least provides an option for all uncoupled streams #80