similar to: Confusion on CELT or Silk

Hello Joshua, I understand. My main aim to first understand the processing overhead when decisions have to be made for a fixed audio in signal, reduce it so that I can then begin making an update to reduce the memory (on chip flash and RAM) footprint. Thanks Amit On Thu, Dec 31, 2015 at 7:58 PM, Joshua Bowman <silverbacknet at gmail.com> wrote: > Opus will always use whatever mode it

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I believe what you want is called Opus custom (OPUS_CUSTOM in the code). With that you can compile only the contents of the celt/ directory and use it like the old CELT. Jean-Marc On 07/06/2015 06:48 PM, Andrew Lentvorski wrote: > Is there a configuration or compile flag that lets me disable the > SILK portion of the codec and use CELT

I saw the custom API, but nothing explicitly says "CELT-only" just "custom sample rate and frame size". I'll dig further now that you've pointed me in a direction. Thanks, -a On 7/6/15, 6:18 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I believe what you want is called Opus custom (OPUS_CUSTOM in the > code).

Is there a configuration or compile flag that lets me disable the SILK portion of the codec and use CELT only? I could have sworn that there is something, but I can't seem to find it in the mailing list archives. The application here is that I am attempting to update from the old CELT codec to OPUS. Unfortunately, the CELT codec was running *very* close to the CPU (MIPS32--80MHz) limit

On 10/26/2013 01:11 PM, Wang, Chris wrote: > A simpler question. How does opus_encode() generate packets of 20ms > (SILK-only or Hybrid)? Concatenating two 10ms frames or doing it > straight with just one 20ms frame? Just one 20 ms frame. It always returns a single frame except when it just can't (e.g. 60 ms CELT). > From your explanations below, opus_encode() will concatenate

Thanks Jean-Marc and Benjamin for the answers. One follow-up question. If I use a repacketizer as Jean-Marc suggested by combining two 60ms frames to form a 120ms frame, without extracting individual frames and using a new TOC, I would need to have a "de-packetizer" that does the exact opposite of repacketizer. De-packetizer would need to separate this 120ms frame into two 60ms frames

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

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 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

Hello Benjamin, The original WAV file I have is linear 8-bit PCM. I want to ensure that original linear formats are kept as is. Later I will add support for ulaw. Regards Amit On Fri, Jan 8, 2016 at 5:34 PM, Benjamin Schwartz < benjamin.m.schwartz at gmail.com> wrote: > Do you really need linear 8-bit PCM or do you want ulaw? Linear 8-bit is > ... pretty rare. > > On Thu,

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

The patch prevents KEIL MDK compile warnings, like:   warning:  #1035-d: single-precision operand implicitly converted to double-precision Actually ARM Cortex-M4F has only a *single precision* (float) FPU. It's suit for all platforms. See the comment at the begin of patch file. Sincerely Forrest Zhang -------------- next part -------------- Specify the floating point constant with single

--- celt/arch.h | 5 +++++ silk/macros.h | 4 +--- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/celt/arch.h b/celt/arch.h index 9f74ddd..670527b 100644 --- a/celt/arch.h +++ b/celt/arch.h @@ -78,6 +78,11 @@ static OPUS_INLINE void _celt_fatal(const char *str, const char *file, int line) #define UADD32(a,b) ((a)+(b)) #define USUB32(a,b) ((a)-(b)) +/* Set this if opus_int64

Hi everyone, Just to let you know that CELT 0.8.1 is out. It's mostly a bugfix release. The bit-stream is compatible with 0.8.0 with the only exception that CELT no longer supports weird frame sizes that have prime factors above 5. This shouldn't really affect anyone. For those of you unaware of the current effort to standardize an audio codec at the IETF, we have recently created a

Hi all, thanks a lot for your replies! Sorry for my typo, the flash size is 8MB (Byte) :-) Unfortunately I cannot use another flash because I'm working on a proprietary board. Jean-Marc, thanks for your suggestions. I thought to use fixed point for convenience, but I can work on floating point too, so I will take in account the codec2 (I didn't know it). Moreover, if you all have

Hi, I'd like to know the reasons why CELT supports only signals with sampling frequency in the range of 32-96 kHz. In effect, it can clearly outperform speex at high bitrates, and has potential to be used in high quality voice communications even for 11, 16 and 22 kHz speech signals. It could also compete with SILK codec (to be soon released by Skype). See this page for more specifications

Hello Ralph, > Likewise opus_encode() takes 16 bit samples, so you need to extend each > sample from an 8 bit source before encoding. Two questions 1. In opusenc.c which API does the extending the 8-bit to 16-bit? 2. If that is the case then how will 24 bit PCM sample work? Regards Amit On Thu, Jan 7, 2016 at 12:21 PM, Ralph Giles <giles at thaumas.net> wrote: > On 07/01/16

I too would like to know the status of the opus IP holders. From what I've seen on the CELT and opus lists, it seems that the CELT part of opus is covered by patents from Xiph and Broadcom, and the SILK part of opus is covered by the rest. All of the IP holders except Qualcomm and Huawei have released their patents to the public as far as opus is concerned, and the general consensus from

Hello Daniele It would be worthwhile to attach an external serial flash or USB thumb drive, if the intent is store data. This allows for far more flexibility in storage Regards Amit On Fri, Aug 26, 2016 at 11:02 AM, Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > On 26/08/16 11:40 AM, Daniele Barzotti wrote: > > You're right! I forgot to say that I need only the encoder