Implement --channels discrete format option

[chris-hld]

This implements an option to specify the channel format as individual, providing an alternative to the default and ambix format. Currently, input with up to 8 channels is interpreted as surround input triggering coupled channels. This behavior is, however, detrimental when using individual / discrete streams that should not be coded as stereo coupled, such as e.g. microphone array signals. The proposed format uses the channel mapping family 255, which is explicitly defined for such scenarios.

[vadimkantorov]

Btw may be better to not do changes to CI scripts within this same PR...

[chris-hld]

Btw may be better to not do changes to CI scripts within this same PR...

Ah yes, I was forking from the gitlab repo originally, which seems to have two more CI commits. Should be fixed now.

[chris-hld]

The documentation specifies mapping families:

255 | Discrete channels

Therefore, renaming to discrete

[chris-hld]

With the option, also channel counts <8 can be transported without stereo coding, correctly evoking mapping 255. It produces a valid file, according to opusinfo.

./../../opus-tools/opusinfo multiTC.opus                                     
Processing file "multiTC.opus"...

New logical stream (#1, serial: 76fcb206): type opus
Encoded with libopus 1.4-6-g9fc8fc4c, libopusenc 0.2.1-16-ge4285b5
User comments section follows...
    ENCODER=opusenc from opus-tools 0.2-30-g78b8127-dirty
    ENCODER_OPTIONS=--bitrate 288 --channels discrete
Opus stream 1:
    Pre-skip: 312
    Playback gain: 0 dB
    Channels: 6
    Original sample rate: 48000 Hz
    Streams: 6, Coupled: 0
    Channel Mapping Family: 255 Map: [0, 1, 2, 3, 4, 5]
    Packet duration:   20.0ms (max),   20.0ms (avg),   20.0ms (min)
    Page duration:   1000.0ms (max),  910.9ms (avg),   20.0ms (min)
    Total data length: 350465 bytes (overhead: 0.788%)
    Playback length: 0m:10.000s
    Average bitrate: 280.4 kbit/s, w/o overhead: 278.2 kbit/s
Logical stream 1 ended

Decoding needs the fix in https://github.com/xiph/opusfile/pull/45/files.

[vadimkantorov]

Curious, without the opusfile PR, will libopus-based libs not be able to decode properly?

Would ffmpeg be able to decode these "discrete"/"decoupled" audio files?

[chris-hld]

Would ffmpeg be able to decode these "discrete"/"decoupled" audio files?

Yes, it should be! Essentially this PR is just using channel mapping 255, which is defined and should be implemented by decoders. And opus info shows that the encoded file is valid, therefore any compliant decoder should be able to decode the file.

[vadimkantorov]

@mark4o Are PR's considered in this repo? Or should they be created in https://gitlab.xiph.org/xiph/opus-tools ?

[mark4o]

Thanks! Merged in a2be3388fb5905efa4652adf859ea3b7e1ceaea6 on https://gitlab.xiph.org/xiph/opus-tools/ (official repository). It looks like the mirroring to GitHub has stopped working; we'll get that fixed. Once that is working again this PR should get tagged and close automatically.

[vadimkantorov]

I also wonder, does gitlab ci / GitHub ci currently publishes any nightly binaries? (E.g. as some "nightly"-tagged release)

Additionally, having fully static musl/alpine binaries for opus-tools programs would be very nice to run on older systems

[mark4o]

The gitlab CI builds it for Debian but it doesn't retain the binaries. opus-tools is not very large so it doesn't take long to build.

[vadimkantorov]

I mean, god knows when a new release will happen :) So having the binaries from the same build process as release binaries is nice.

Yeah, static building is not difficult (I made the following GitHub Workflow file: https://gist.github.com/vadimkantorov/c2664ee326e1e929f2ab9fb5ac743d26), but for less build-savvy users, it would be helpful.