similar to: CELT 0.8.1, IETF codec

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

Hi folks, here's a press release (yes, sorry, sorry) regarding what's going on with Xiph at the current IETF meeting. Every time we're asked 'why haven't you standardized any of your codecs through the IETF?' we explain that we've been trying for coming up on ten years. This release is about the latest step. If we (along with the other companies supporting

Hi folks, here's a press release (yes, sorry, sorry) regarding what's going on with Xiph at the current IETF meeting. Every time we're asked 'why haven't you standardized any of your codecs through the IETF?' we explain that we've been trying for coming up on ten years. This release is about the latest step. If we (along with the other companies supporting

Hi everyone, I'm pleased to announce version 0.6.0 of CELT, with many quality improvements. This includes better stereo coupling, better handling of transients, and better handling of highly tonal signals. In addition, packet loss robustness has been improved through the optional use of independent (intra) frames. CELT now supports a larger dynamic range, suitable for encoding 24-bit audio

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

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

Hi everyone, Just to let you know that Opus 1.2 is finally here. This major release brings many quality improvements, new features, and bug fixes. You can read all the details (and hear audio samples) in this release demo page page: https://people.xiph.org/~jm/opus/opus-1.2/ Changes since 1.1.x include: - Speech quality improvements especially in the 12-20 kbit/s range - Improved VBR encoding

Hello, I would like to point everyone's attention to a proposal to create a new IETF working group dedicated to standardising unencumbered audio codecs. There will be a BoF at the next IETF meeting (26-31 July) in Stockholm to discuss that. I encourage those interested in taking part in the mailing list discussion ( https://www.ietf.org/mailman/listinfo/codec ) and/or attending the BoF in

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

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

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

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

Hello, This is a first patch which add macros for ARMv5E. Also, I copy headers from other files and add company name, tell me if I'm wrong. Also, if you have any question or comment about it, feel free to contact me. Best regards, -- Aur?lien Zanelli Parrot SA 174, quai de Jemmapes 75010 Paris France -------------- next part -------------- diff --git a/celt/fixed_arm5e.h

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

--- Makefile.am | 8 +++-- silk/NSQ.c | 37 ++++++++-------------- silk/NSQ.h | 70 +++++++++++++++++++++++++++++++++++++++++ silk/arm/NSQ_neon.c | 64 +++++++++++++++++++++++++++++++++++++ silk/arm/NSQ_neon.h | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++++ silk/x86/NSQ_sse.c | 2 +- silk/x86/main_sse.h | 3 +- silk_headers.mk | 2 ++ silk_sources.mk

--- Makefile.am | 5 +-- silk/NSQ.c | 37 ++++++++-------------- silk/NSQ.h | 70 +++++++++++++++++++++++++++++++++++++++++ silk/arm/NSQ_neon.c | 64 +++++++++++++++++++++++++++++++++++++ silk/arm/NSQ_neon.h | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++++ silk/x86/NSQ_sse.c | 2 +- silk/x86/main_sse.h | 3 +- silk_headers.mk | 2 ++ silk_sources.mk

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

Hi everyone, I've just made the first public release of some new *experimental* codec work I've been doing (part of the vague Ghost project) with help from Monty and Timothy. This is mainly intended with developers with DSP knowledge, not for doing anything useful with it (but it does encode and decode already). Also, the main idea is *not* to replace either Speex or Vorbis, but to code

Hi everyone, I've just made the first public release of some new *experimental* codec work I've been doing (part of the vague Ghost project) with help from Monty and Timothy. This is mainly intended with developers with DSP knowledge, not for doing anything useful with it (but it does encode and decode already). Also, the main idea is *not* to replace either Speex or Vorbis, but to code