similar to: CELT/Opus Status Update

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

Xiph.Org is pleased to announce that we've released Opus 1.2. The 1.2 release includes: . Speech quality improvements especially in the 12-20 kbit/s range . Improved VBR encoding for hybrid mode . More aggressive use of wider speech bandwidth, including fullband speech starting at 14 kbit/s . Music quality improvements in the 32-48 kb/s range . Generic and SSE CELT optimizations .

Hi everyone, I've just released Opus 1.2-alpha. It comes with many improvements, including: - Speech quality improvements especially in the 12-20 kbit/s range - Improved VBR encoding for hybrid mode - More aggressive use of wider speech bandwidth, including fullband speech starting at 14 kbit/s - Music quality improvements in the 32-48 kb/s range - Generic and SSE CELT optimizations - Support

hi, I am porting opus encoder to a low end device with 32K ram, 256K flash and 32MHz arm M3 mcu. But opus seems consume too much. To make it work , what I can think of 1, Only fixed point supported 2, Only mono voice application supported 3, Set complexity to zero 4, Support only one sample rate, like 16KHz 5, Silk mode only or Celt mode only My question is , before

Hello Thomas and Amit, Thanks for your notice and the detailed decode performance report. I describe the details of my encode/decode test on STM32F407ZG. A. opus version: latest 1.2.1 (TI: opus 1.1.2) B. KEIL 5.23 (TI: ARM compiler tool chain 5.2.7) C. setup the encoder as the below (fs is the sampling frequency) enc = opus_encoder_create(fs, chans, OPUS_APPLICATION_AUDIO, &opus_err);

--- win32/VS2015/opus.vcxproj | 2 ++ win32/VS2015/opus.vcxproj.filters | 6 ++++++ 2 files changed, 8 insertions(+) diff --git a/win32/VS2015/opus.vcxproj b/win32/VS2015/opus.vcxproj index d9aaa03..f55ea37 100644 --- a/win32/VS2015/opus.vcxproj +++ b/win32/VS2015/opus.vcxproj @@ -852,6 +852,7 @@ <ClInclude Include="..\..\celt\vq.h" /> <ClInclude

> As the thing is to encode for human ears (AFAIK), I'd say that 4kHz is already "quite high", > and I wonder who can actually hear pure 20kHz sine. If you read the beginning of RFC 6716, you learn that Opus never encodes any frequencies that are higher than 20 kHz. So at some medium or high bitrates, anything above 20 kHz is filtered out, not because of the bitrate but

Hi everyone, I'd just like to announce CELT 0.11.1 (sorry about failing to announce 0.11). The bit-stream is now is "soft-freeze", which means we won't change it unless we find bugs -- which we did between 0.11 and 0.11.1. The API should also be close to the final API. Compared to 0.10.x there are also small quality improvements, mostly at high bit-rate. I'd also like

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

Thanks Jean-Marc, I was able to get both encode and decode working the CC3220 device! But for bi-directional communication, I need decode and encode to occur in less time than the frame size I’m sending (20 ms). Currently decode takes 16~22 ms and encode is ~13 ms. What is the best way to try to reduce this time? Also, unsure why encode is taking less time than decode... I've also

I?m trying to build Opus (git master) for iOS, and it doesn?t build unless I disable the ARM assembly. It looks like the problem is that Apple?s assembler doesn?t support all the assembler directives that the GNU assembler does. I suspect this is a combination of the fact that Apple platforms are Mach-O rather than Elf, and just the fact that Apple?s assembler is extremely divergent from the

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, 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, I received feedback from engineers working on NE10 [1] that it would be better to use NE10 [1] for FFT optimizations for opus use cases. However, these FFT patches are currently in review and haven't been integrated into NE10 yet. While the FFT functions in NE10 are getting baked, I wanted to optimize the celt_pitch_xcorr (floating point only) and use it to introduce ARM NEON

From: Jonathan Lennox <jonathan at vidyo.com> * Makes ?enable-intrinsics work with clang and other non-GCC compilers * Enables RTCD for the floating-point-mode SSE code in Celt. * Disables use of RTCD in cases where the compiler targets an instruction set by default. * Enables the SSE4.1 Silk optimizations that apply to the common parts of Silk when Opus is built in floating-point mode, not

Viswenath, My patch should be against the tip, but it?s the very recent tip, including some changes this past Friday (27 Feb). I mentioned in the IRC room a problem I discovered in creating my patch, and then later improved the fix Tim had made for the problem. Where do you get conflicts merging it to tip? In terms of merging, you posted your patch before I posted mine, so probably I should be

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

On 21 November 2014 at 18:06, Timothy B. Terriberry <tterribe at xiph.org> wrote: > > Viswanath Puttagunta wrote: >> >> a. Simplest use case to validate this optimization for correctness. >> b. Simplest use case to validate this optimization for performance. >> >> Would prefer something like opusdec that can be executed on command >> line. > >

I know the focus for Opus is low delay, but I've been watching its development with interest because of the potential for audiobook/podcast use, where latency is practically irrelevant. I hear the upcoming USAC codec will give good results for this niche (though listening test results don't seem to be available to the public yet), but I also hear it'll be extremely patent