similar to: Opus 1.3 is out!

Hi, I just released Opus 1.3-beta. This is a beta release towards the upcoming Opus 1.3. Changes include: - The spec fixes in RFC 8251 are now enabled by default - Improvements to the VAD and speech/music classification using an RNN - Improvements to stereo speech coding at low bitrate - Added support for ambisonics projection using mapping 3 (disabled by default) - Fixes to the CELT PLC

Thanks for all the amazing work with ambisonics Drew et al. We're looking forward to the 1.3 final release and have already been successfully using the ambisonic work in production code. Varun -- Engineering Manager Facebook Audio ---------------------------------------------------------------------- Message: 1 Date: Sun, 3 Jun 2018 13:02:18 +0100 From: Peter Robinson

Hi, I just released Opus 1.3-rc. This is a release candidate for the upcoming Opus 1.3. Changes include: - Making it possible to use SILK down to bitrates around 5 kb/s - Using wideband encoding down to 9 kb/s - Improving security (including a new --enable-hardening option) - Minor quality improvement on tones - Improving Ambisonics support (still experimental) - Minor bug fixes It's likely

Hi Jean-Marc, gdb out is "Program terminated with signal 8, Arithmetic exception." most likely this division by zero. you're right, this crash is reproduce on seq number 4294967265 (20ms rtp packet). This is about 994 days. "Jean-Marc Valin" <jmvalin at jmvalin.ca> писал(а):Hi Dmitry, > >So it's not explicitly in your report, but it looks like the crash

Stack: (gdb) bt #0 0x0000000000aaf38a in silk_VAD_GetNoiseLevels (pX=pX at entry=0x7f26740297a0, psSilk_VAD=psSilk_VAD at entry=0x15897c38) at silk/VAD.c:315 #1 0x0000000000aa4a9d in silk_VAD_GetSA_Q8_sse4_1 (psEncC=0x15897c18, pIn=<optimized out>) at silk/x86/VAD_sse.c:177 #2 0x0000000000a9f92b in silk_encode_do_VAD_FLP (psEnc=psEnc at entry=0x15897c18) at

Hi Jean-Marc, We're exposing the opus_internal_flags data structure so that we can access the value assigned to prevSignalType. Here's a snippet of our code: error = opus_encoder_get_internal_flags(vad->opus, &internalflags); if (error != OPUS_OK) { return OPUSVAD_OPUS_ERROR; } cur_signal_type = internalflags.prevSignalType; if

Hi Jean-Marc, Thank you for the valuable feedback. You're correct in that we focused on enabling this just for SILK. Because our solutions are focused on voice, we did not explore doing the same in CELT mode, but we can certainly look into the details of analysis.c. Regarding the concern of exposing internals, do you have a specific proposal in mind? We've been sharing this patch with

Hi Peter, Can you say a little bit more about what you're doing exactly with the information you're exposing and how? unfortunately, I don't have a concrete proposal in mind right now. That's in part because I don't quite understand the use case, but also because it's really hard to expose this kind of information in a way that both avoids breaking application with new

Hi Dmitry, So it's not explicitly in your report, but it looks like the crash is due to a divide-by-zero at: min_coef = silk_DIV32_16( silk_int16_MAX, silk_RSHIFT( psSilk_VAD->counter, 4 ) + 1 ); which happens because counter is -16 (which means (-16 >> 4) + 1 == 0). Now, this could be caused by an integer wrap-around, but it should only happen after encoding around

On 2017-11-01, Jean-Marc Valin wrote: > I'm not sure, but my best guess would be "because MP3's window is very > leaky and MP3 has to waste a lot of bits in the LF because of that". > It could also be just the MP3 encoder being silly, or other things. Was the original poster speaking about the SILK or the CELT derived mode? Because at least wrt SILK (and the rest of

Hi Mark, Jean-Marc, Thanks for your comments. On Sun, Jun 12, 2016 at 6:34 AM Mark Harris <mark.hsj at gmail.com> wrote: > Hi Felicia, > > A few comments: > > > - /* CELT can only support up to 20 ms */ > > subframe_size = st->Fs/50; > > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > > + nb_subframes =

Hi! A note on style: Looking at this chunk of the patch -- @@ -382,9 +382,15 @@ int main(int argc, char *argv[]) frame_size = sampling_rate/25; else if (strcmp(argv[ args + 1 ], "60")==0) frame_size = 3*sampling_rate/50; + else if (strcmp(argv[ args + 1 ], "80")==0) + frame_size = 4*sampling_rate/50; +

We have found that it is possible to achieve a 30 to 50% reduction in MHz requirement for implementation of OPUS on Cortex M4 compared to the public version (v1.3 beta/v1.2.1). For the CELT configuration you mention (complexity 0, 16kHz, mono, 20ms) we are measuring a 4ms encode time and a 3ms decode time for that platform (32kbit/s). An important issue that I haven't seen much discussion

Hi Peter, There's two main issues with a patch like the one you're proposing. First, the data is only valid when SILK is being used and is essentially undefined in CELT mode. The second issue is that by exposing internals, it makes it impossible to improve these algorithms since it would break API compatibility. I'm not fundamentally against trying to expose some information, but

Hi Ulrich, thanks for the suggestion. My concern is that one of the valid inputs is "2.5", which would require conversion to an int, e.g. x10, but doing something like this would start to affect the code readability. On Mon, Jun 27, 2016 at 3:02 PM Ulrich Windl < Ulrich.Windl at rz.uni-regensburg.de> wrote: > Hi! > > A note on style: Looking at this chunk of the patch

Hi Felicia, A few comments: > - /* CELT can only support up to 20 ms */ > subframe_size = st->Fs/50; > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > + nb_subframes = frame_size/subframe_size; This will use six 20ms frames to make a 120ms packet, even for SILK-only mode where frames can be up to 60ms. For SILK, two 60ms frames would be a more

Attached is the amended second patch. It now extends the multistream API as well to 80/100/120 ms and incorporates changes based on Mark's comments. Thanks, Felicia On Mon, Jun 13, 2016 at 4:21 PM Felicia Lim <flim at google.com> wrote: > Hi Mark, Jean-Marc, > > Thanks for your comments. > > On Sun, Jun 12, 2016 at 6:34 AM Mark Harris <mark.hsj at gmail.com>

Just to make sure, what's the goal here? Is the goal 1) to have a fast Opus implementation or are you 2) looking for an interesting FPGA implementation project? If 1), then an FPGA is most likely not necessary since Opus is not computationally expensive. If 2), then it depends on the desired size of the project and the desired quality. The simplest encoder possible is indeed simpler than the

Hi everyone, I've made several posts recently about CELT being "replaced" by the Opus codec ( http://opus-codec.org/ ) and I thought it was time to give an update on what's going on. As many of you know, I've been involved at the IETF on this new Opus codec, which essentially merge (a modified version of) Skype's SILK codec with CELT. This is more than just two codecs

I have difficulties to understand how to use Silk GNC. I have enabled GNC (and VAD) something like this: param.setting.vad = 1; param.setting.cng = 1; param.setting.plc = 1; param.setting.penh = 1; status = pjmedia_codec_opus_set_default_param(&config, &param); I used debugger and printf to see that code executes in Opus CNG.c silk_CNG function noise generation loop. But still I cannot