similar to: Silk Decoding Question

I am pleased to announce that functional Java ports of both the Opus encoder and decoder are now available, with code derived from the existing C# implementation. As of now it should be considered an "experimental" release, pending some cleanup of the API functions, documentation, and more extensive parity verification. There is also at least 1 known issue which causes minor noise in the

Hello all, I am a very stubborn programmer who, in an attempt to avoid compiling C code for a phone app, instead decided it would be easier to port the entire opus codebase to C#. That was 3 months ago. I believe the fruit of my efforts is now ready for at least an alpha release to the public: this repository contains a fully functional Opus encoder/decoder written in portable .NET:

Hi, Can anyone let me know if this is a bug? Thank you, Chandrakala ----- Original Message ----- From: "Logan Stromberg" <loganstromberg at gmail.com> To: "Chandrakala Madhira" <chandrakala.madhira at soctronics.com> Cc: opus at xiph.org Sent: Wednesday, November 22, 2017 12:12:39 PM Subject: Re: [opus] Reg an issue with smoothing factor in VAD

Hi Chandrakala, Logan, Can you confirm that the attached patch fixes the overflow problem? Koen, can you confirm the fix makes sense? Cheers, Jean-Marc On 11/27/2017 12:10 PM, Logan Stromberg wrote: > Sorry, long holiday weekend in America. > I can say with pretty high certainty that there is an overflow occurring > and it is flipping smooth_coef_Q16 to be negative when it probably

Sorry, long holiday weekend in America. I can say with pretty high certainty that there is an overflow occurring and it is flipping smooth_coef_Q16 to be negative when it probably shouldn't be. I had originally thought it was only an issue where it was overflowing the 15th bit but not the 16th, which might still preserve the intended value for operations that ignore the sign bit (in cases

Yes, yes, I can reproduce it now, but only on platforms that define a 16-bit int by default (SA_Q15 is an opus_int rather than opus_int32). What system are you compiling this for? On Tue, Nov 21, 2017 at 8:34 PM, Chandrakala Madhira < chandrakala.madhira at soctronics.com> wrote: > Hi Logan, > > Please find attached the input stream we are using testing. > > Thank you, >

Just for fun, I tried to reproduce such an overflow. I turned on all debug macros, assertions, and checked arithmetic and then encoded 2 hours of mixed speech/audio with these parameters: Sample rate = 48000 Channels = 1 Application = OPUS_APPLICATION_AUDIO Bitrate = 24 KB/s Force Mode = MODE_SILK_ONLY Signal Type = OPUS_SIGNAL_AUTO Complexity = 10 Frame size = 480 samples (10ms) No errors came

> I don't believe this is an actual error. If it's truly possible for > these areas to overlap (I don't think it is), then something much more > serious than using memmove instead of memcpy needs to be done about it. In the C# version of this code, these two copy regions are stored in separate arrays entirely. I agree that there should be no normal way to have the memcpy

Hi I am building an opus decoder (java) and I am currently working on the Silk decoding. I am working through the spec and using the reference implementation to check things as I go along. I am up to the silk reconstruction part (4.2.7.9) and I have a few questions. I'm assuming there are 4 subframes in the 2nd part just to look at the widest possible case. 1) The spec says "Although

Hi! I can't find this info anywhere. What is the minimum CPU requirement for Vorbis playback ? Regards, David --------------------------------------------------------------------- http://noepatents.eu.org/ Innovation, not litigation ! --- David Balazic mailto:david.balazic@hermes.si HERMES Softlab http://www.hermes-softlab.com Zagrebska

I need to extract SILK only FIXED POINT code. I have a couple of questions in this regard. 1. Is it enough to enable compile time flag (FIXED_POINT) in the config.h, include silk_fixed library and exclude silk_float in the opus_demo project. I am working in the MSVC framework. Anyone has tried this before? 2. It seems there is no compile time flag to enable SILK only code, the core

Ashutosh- It sounds like you're trying to implement an Opus-like application but you have a very constrained environment. If you just want the Silk portion of the codec, then why not just ignore opus and use the silk codec directly? The old SDK is still available in some places, like here: https://code.google.com/archive/p/bkvoice/downloads (Keep in mind that Opus uses a modified version of

Fixes build failure on platforms with MAY_HAVE_SSE4_1 (but not PRESUME_SSE4_1) with --enable-intrinsics. --- silk/fixed/main_FIX.h | 11 +++++++++++ silk/x86/x86_silk_map.c | 2 ++ 2 files changed, 13 insertions(+) diff --git a/silk/fixed/main_FIX.h b/silk/fixed/main_FIX.h index ffeb4f3..375b5eb 100644 --- a/silk/fixed/main_FIX.h +++ b/silk/fixed/main_FIX.h @@ -97,6 +97,17 @@ void

Dear all: I want to formulate couple of questions about SILK codec: 1. I've seen the documentation to the SILK codec that is part of the OPUS exactly the paper with title "The opus codec voice coding with opus, and the "RFC 6716 specification of opus" . Well, I detected that in both is defined a High-Pass filter as part of SILK; however in the paper you put the following

Hi, I stumbled upon mentions of a "SILK" codec last night on skypes "skype for sip" information page. I tried looking into it further and found some blog and mailing list posts from 2009 but I can't find any mentions of anything other than skype using the codec. Has the codec not gotten anywhere so far? http://en.wikipedia.org/wiki/SILK

Fixes build failure on platforms with MAY_HAVE_SSE4_1 (but not PRESUME_SSE4_1) with --enable-intrinsics. --- silk/fixed/main_FIX.h | 11 +++++++++++ silk/x86/x86_silk_map.c | 2 ++ 2 files changed, 13 insertions(+) diff --git a/silk/fixed/main_FIX.h b/silk/fixed/main_FIX.h index ffeb4f3..375b5eb 100644 --- a/silk/fixed/main_FIX.h +++ b/silk/fixed/main_FIX.h @@ -97,6 +97,17 @@ void

--- silk/macros.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/silk/macros.h b/silk/macros.h index 1ba614a..e1e05b9 100644 --- a/silk/macros.h +++ b/silk/macros.h @@ -48,14 +48,14 @@ POSSIBILITY OF SUCH DAMAGE. /* (a32 * (opus_int32)((opus_int16)(b32))) >> 16 output have to be 32bit int */ #if OPUS_FAST_INT64 -#define silk_SMULWB(a32, b32)

Fixes CID 1227580 --- silk/process_NLSFs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/silk/process_NLSFs.c b/silk/process_NLSFs.c index c27cf03..d9123ef 100644 --- a/silk/process_NLSFs.c +++ b/silk/process_NLSFs.c @@ -100,6 +100,6 @@ void silk_process_NLSFs( } else { /* Copy LPC coefficients for first half from second half */ - silk_memcpy(

Using 11.4.0, trying to use SILK on the cell phone to ulaw over gv, but no success: [Jun 10 16:18:22] WARNING[4090][C-0000000a]: channel.c:6164 ast_channel_make_compatible_helper: No path to translate from SIP/ng-00000000 to Motif/+12025551212 at voice.google.com-da3c [Jun 10 16:18:22] WARNING[4090][C-0000000a]: app_dial.c:3032 dial_exec_full: Had to drop call because I couldn't make

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