>On 11/20/2013 03:37 PM, O'Connor, Kevin wrote: >> I have an application I intend to use Opus for that involves creating >> recordings of two-party conversations where each party is saved as a >> separate channel. Audio may be later processed or analyzed on a >> per-party basis so if audio in one channel affects the other channel, it >> could create problems. My question is, if I use a single stereo Opus >> stream, how well will channel separation be maintained? Are there any >> other disadvantages to doing it this way? > >If you encode as stereo, you should still have perfect channel >separation. However, the encoding will likely be less efficient than >having two separate streams. How much is not clear -- you'll have to >experiment.I've run a couple quick tests with opus-tools 0.1.8 and it doesn't sound like the two channels are getting perfect channel separation. You can hear a faint version of the opposite channel after encoding to opus and then decoding. I have a couple of sample .wav files I can supply (before and after opus encoding/decoding) that show the affect. I can attach or upload them somewhere if someone wants to take a look, but it's pretty easy to see if you have a recording where one channel is silent for a few seconds. I'm encoding an 8kHz, linear, 16bit wave file that contains two channels (both with speech), using opusenc and opusdec with default settings. Opusinfo gives the following output for the encoded opus file: New logical stream (#1, serial: 00003419): type opus Encoded with libopus 1.1 User comments section follows... ENCODER=opusenc from opus-tools 0.1.8 Opus stream 1: Pre-skip: 312 Playback gain: 0 dB Channels: 2 Original sample rate: 8000Hz Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min) Page duration: 1000.0ms (max), 989.6ms (avg), 480.0ms (min) Total data length: 247227 bytes (overhead: 1.89%) Playback length: 0m:49.471s Average bitrate: 39.98 kb/s, w/o overhead: 39.22 kb/s Logical stream 1 ended Is this bleedover expected? I found an older copy of opus-tools (0.1.6, libopus 1.0.2) and it does not appear to have the bleedover between channels, so I think this was introduced in 1.0.3 or 1.1. Kevin O'Connor Interactive Intelligence, Inc.
O'Connor, Kevin wrote:> Is this bleedover expected? I found an older copy of opus-tools (0.1.6, libopus 1.0.2) and it does not appear to > have the bleedover between channels, so I think this was introduced in 1.0.3 or 1.1.This bleed-over should not be possible with the CELT layer (_especially_ not during silence), but it is possible with the SILK layer. 1.1 added automatic speech detection, so it is possible that this is caused by switching to SILK in places 1.0.2 would have defaulted to CELT based on your bitrate. Can you reproduce the issue when you encode with --set-ctl-int 4000=2051 ?
>This bleed-over should not be possible with the CELT layer (_especially_ not during silence), but it is possible with >the SILK layer. 1.1 added automatic speech detection, so it is possible that this is caused by switching to SILK in >places 1.0.2 would have defaulted to CELT based on your bitrate.Yes, I still hear the bleed-over with that option. Here's the output of opusinfo after encoding: New logical stream (#1, serial: 000012a5): type opus Encoded with libopus 1.1 User comments section follows... ENCODER=opusenc from opus-tools 0.1.8 ENCODER_OPTIONS=--set-ctl-int 4000=2051 Opus stream 1: Pre-skip: 120 Playback gain: 0 dB Channels: 2 Original sample rate: 8000Hz Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min) Page duration: 1000.0ms (max), 989.6ms (avg), 480.0ms (min) Total data length: 246911 bytes (overhead: 1.89%) Playback length: 0m:49.471s Average bitrate: 39.93 kb/s, w/o overhead: 39.17 kb/s Interestingly, this looks nearly identical to the first one I sent. I also tried --set-ctl-int 4000-2049 and got the same results (bleed-over in the audio). Here is the opus-info from that one: New logical stream (#1, serial: 000039cd): type opus Encoded with libopus 1.1 User comments section follows... ENCODER=opusenc from opus-tools 0.1.8 ENCODER_OPTIONS=--set-ctl-int 4000=2049 Opus stream 1: Pre-skip: 312 Playback gain: 0 dB Channels: 2 Original sample rate: 8000Hz Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min) Page duration: 1000.0ms (max), 989.6ms (avg), 480.0ms (min) Total data length: 247227 bytes (overhead: 1.89%) Playback length: 0m:49.471s Average bitrate: 39.98 kb/s, w/o overhead: 39.22 kb/s Logical stream 1 ended For completeness, I also tried --set-ctl-int 4000=2048 and, while it does sound like there may be slight artifacts from the other channel during silence, it's nowhere near as bad as the other two cases above. Here is the opus-info output: New logical stream (#1, serial: 000001e6): type opus Encoded with libopus 1.1 User comments section follows... ENCODER=opusenc from opus-tools 0.1.8 ENCODER_OPTIONS=--set-ctl-int 4000=2048 Opus stream 1: Pre-skip: 312 Playback gain: 0 dB Channels: 2 Original sample rate: 8000Hz Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min) Page duration: 1000.0ms (max), 989.6ms (avg), 480.0ms (min) Total data length: 234522 bytes (overhead: 1.99%) Playback length: 0m:49.471s Average bitrate: 37.92 kb/s, w/o overhead: 37.17 kb/s Logical stream 1 ended Kevin O'Connor Interactive Intelligence, Inc.
The bleed-over is actually possible with CELT because at low bitrates, the encoder will deliberately reduce the stereo image to reduce the coding noise. For 48 kHz/20 ms, the image reduction occurs below about 40 kbps. Any bitrate above that shouldn't have any leakage. Jean-Marc On 07/04/14 03:10 PM, Timothy B. Terriberry wrote:> O'Connor, Kevin wrote: >> Is this bleedover expected? I found an older copy of opus-tools (0.1.6, libopus 1.0.2) and it does not appear to >> have the bleedover between channels, so I think this was introduced in 1.0.3 or 1.1. > > This bleed-over should not be possible with the CELT layer (_especially_ > not during silence), but it is possible with the SILK layer. 1.1 added > automatic speech detection, so it is possible that this is caused by > switching to SILK in places 1.0.2 would have defaulted to CELT based on > your bitrate. > > Can you reproduce the issue when you encode with > --set-ctl-int 4000=2051 > ? > _______________________________________________ > opus mailing list > opus at xiph.org > http://lists.xiph.org/mailman/listinfo/opus >