similar to: Stereo changes in exp_stereo

Thank you. Very helpful. > On Jan 27, 2017, at 12:40 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > > On 27/01/17 12:29 PM, Jon Lederman wrote: >> Thank you. Yes, we do need both channels independent. So, if we >> encode each channel separately, we will be sacrificing the >> compression ratio we would achieve with stereo encoding, correct? > > Not

Hi Jean-Marc, Thank you. Yes, we do need both channels independent. So, if we encode each channel separately, we will be sacrificing the compression ratio we would achieve with stereo encoding, correct? So, based on what you say here is my understanding. Please confirm this is correct or not: 1) If we use fec, we can reduce cross-talk but increasing bitrate. However, that should result in

On 27/01/17 12:29 PM, Jon Lederman wrote: > Thank you. Yes, we do need both channels independent. So, if we > encode each channel separately, we will be sacrificing the > compression ratio we would achieve with stereo encoding, correct? Not necessarily. Stereo makes two assumptions: 1) It assumes the two channels are somehow correlated 2) It assumes the two channels are meant to be

Hi, One other question I was wondering about. Is the reason that we hear the crosstalk with fec and packet loss percentage>0 is that Opus uses information from the left channel to try to error correct the right channel and vice versa? I am trying to understand the origin of the crosstalk. Thanks. -Jon > On Jan 27, 2017, at 12:29 PM, Jon Lederman <jon at soniccloud.com> wrote: >

Hi Everyone, I just merged a lot of changes in the CELT master branch. This should solve the following issues: - tonal artefacts (birdies) at low bit-rate - tonal artefacts in stereo at all rates - low-frequency noise (roughness) on low bit-rate speech The code has been simplified a lot, but there's lots of changes, so please give this a try and see if anything got broken. Cheers,

Hello Jean-Marc, yes, it works for both 32 and 48 kb/s. Also this option marginally increases the size of the file which is understandable. I tried a few other music files and found that this stereo narrowing happens not only in the case of track I submitted (although in smaller scale) so it would be great if the final libopus 1.2 had officialy a parameter to force music "mode" of

On 27/01/17 12:16 PM, Jon Lederman wrote: > When you say that with fec enabled, the threshold is increased, do > you mean the bitrate - i.e., you need higher bitrate with fec enabled > to suppress crosstalk? Correct. Another effect I forgot to mention is that Using FEC will actually force SILK/hybrid rather than CELT, so it's possible that disabling FEC makes you use CELT, which

Thanks. When you say that with fec enabled, the threshold is increased, do you mean the bitrate - i.e., you need higher bitrate with fec enabled to suppress crosstalk? Also, can you make any recommendations to decide whether to use fec or not? We are trying to tune the parameters appropriately. Audio quality and reduction of crosstalk are critical for us. Thanks again. Jon Sent from my

Hi, Two related news here. First, I've merged in support for stereo (or more channels) acoustic echo cancellation in mainline. The standard AEC remains the same, but I added a speex_echo_state_init_mc() call that takes the number of speakers and microphones. Now, one of the consequence of this new work is that by merging this work into the main tree, I had to do things in git that svn just

Hi Jean-Marc, I looked at that but importantly these streams need to remain absolutely independent, Further they may have been encoded at some previous time. So my question stands. Thanks, Marc On Jul 26, 2013, at 9:10 PMEDT, Jean-Marc Valin wrote: > Hi Marc, > > I recommend you have a look at the multistream API and how we use it for > surround in the Ogg Opus draft. Sounds

Hi everyone, I've just changed the API for CELT, but at least there's a good reason for that. It's now possible to use the same mode data for both mono and stereo. So here's the change: - The celt_mode_create() function has a "channels" parameter - The celt_encode_create() and celt_decoder_create() functions now have an additional "channels" parameter. - I

Hey Jean-Marc, sorry about that... extra lines... was it whitespace? If so, sorry about that. Thanks! Cheers, Drew Cheers, Drew On Fri, Apr 28, 2017 at 2:43 PM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Oops, looks like we both should have been more careful. The patch had > some extra lines that shouldn't have been there. > > Jean-Marc > > On

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

Hi Matěj, I had a look at your files and it seems like the issue is that the speech/music detector thinks that some segments are speech rather than music and at low bitrates SILK tends to significantly narrow the stereo image. We're planning on adding an option to opusenc to force it to treat the input as speech/music. Just to confirm that's the issue, can you try encoding with the

Hi Jon, On 27/01/17 08:31 AM, Jon Lederman wrote: > We are trying to use Opus in a VoIP environment for sending stereo > audio. We have noticed a phenomenon where when FEC is enabled and > packet_loss_percentage>0, that there is a mixing of audio from the > left channel into the right channel and vice versa. That is, rather > than hearing each channel in its pristine form as

My apologies for the confusion, I think I have the mapping layout correct in this patch. Cheers! On Tue, Apr 25, 2017 at 10:07 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 25/04/17 10:12 AM, Drew Allen wrote: > > We assume that the input file is ordered first by ACN ambisonic channels > > followed by a (possible) stereo track, and we want to swap the order for

Hi Jean-Marc, Thanks again for your comments. Attached is a revised patch. On Mon, Apr 24, 2017 at 1:08 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > I think your revised patch looks good overall. Just two comments: > > 1) In opus_multistream_encoder_init_impl(), rather than use a huge > condition with two ORs for the return OPUS_BAD_ARG, maybe you can

Oops, looks like we both should have been more careful. The patch had some extra lines that shouldn't have been there. Jean-Marc On 28/04/17 12:59 PM, Drew Allen wrote: > My apologies for the confusion, I think I have the mapping layout > correct in this patch. > > Cheers! > > > > On Tue, Apr 25, 2017 at 10:07 AM Jean-Marc Valin <jmvalin at jmvalin.ca >

Hello All, We have been doing an optimised port of OPUS to a ARM Cortex A9. We are currently measuring between 20 and 90 MCPS for our code running on a Panda board (single core), this covers all bit-rates,sample rates for stereo coding (encode + decode) under normal operation. As Marc says complexity can be controlled via the API with our higher figure corresponding to the default setting of

HI All, We are trying to use Opus in a VoIP environment for sending stereo audio. We have noticed a phenomenon where when FEC is enabled and packet_loss_percentage>0, that there is a mixing of audio from the left channel into the right channel and vice versa. That is, rather than hearing each channel in its pristine form as it was in the file, there is a combination of right and left