similar to: Opus

Thanks for the reply. For my application I unfortunately need a better signal reconstruction. It's not necessarily a problem that the constant DC voltage is removed, but the audio signal will need to be more exact because it's also studied visually. To be more exact, I need to record and transmit audio data recorded from animals (mostly birds). Are there ways to achieve a more similar

Thread-split from the vorbis-mailing list ("Vorbis determined to be as good as MPC at 128 kbps!") <p>On Sun, 30 May 2004, Segher Boessenkool wrote: [Steven So] SS>> If iTunes AAC can encode castanets with much less pre-echo at SS>> ABR 128 kbps, then hopefully there will be an imaginative SS>> (and non-patented) way of doing this in Vorbis without the SS>>

Hi everyone, I'd like to announce the release of Opus 1.2-rc1. It is the first release candidate of the upcoming Opus 1.2 release. If no issues are found with it, it will soon become 1.2-final, so we encourage everyone to give it a try. Changes compared to 1.2-beta include: * Improved quality on files with powerful tones that cause MDCT leakage * Improved bit allocation on mode transitions

On Thu, Nov 14, 2013 at 12:51 AM, Fredrik Bonde <Fredrik.Bonde at ascom.se> wrote: > 1. Is it possible to via SDP force the remote party to send a > specific mode of the 32 different possible modes or to force the remote side > to use CELT only? No, and if you cannot decode opus completely (all modes) your device is not conformant with the Opus specification. I'm

Yes, that's a start. Ultimately, though, I'm hoping to reduce the 80ms requirement, and am trying to get a handle on what state in the decoder must converge and what complications I might be up against. I'm also only considering CELT-based encodings if that simplifies things. I know that Opus can do inter-frame energy envelope prediction, but that dependency can be eliminated by

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

Dear all In the paper section describes how CELT and SILK had implemented a look/up head delay of (2.5ms), (5ms) respectively , could you explain me> 1) those values are fixed. 1) how you guarantee those values independent of the architecture's performance. Thanks so much On Tue, Apr 18, 2017 at 10:05 AM, Diego Alejandro Parra Guzman < daparrag at correo.udistrital.edu.co>

Good catch! I think gcc is just unable to make use of restrict for anything useful. Apparently your compiler does, so could you benchmark both patches below and see if it makes a difference in terms of speed. If it's worth it, I can keep the restrict and add the odd case handling, but if not I'll just remove the restrict. Thanks, Jean-Marc On 21/02/14 05:54 PM, Marcello Caramma

After a few experiments, I found that both alternatives are very similar, and 2~5% slower compared to the following: diff --git a/celt/mdct.c b/celt/mdct.c index 1634e8e..e490c3b 100644 --- a/celt/mdct.c +++ b/celt/mdct.c @@ -277,7 +277,7 @@ void clt_mdct_backward(const mdct_lookup *l, kiss_fft_scalar *in, kiss_fft_scala it in-place. */ { kiss_fft_scalar * OPUS_RESTRICT yp0 =

http://en.wikipedia.org/wiki/Modified_discrete_cosine_transform is an OK place to start. On Mon, Jul 8, 2013 at 7:33 AM, Mahantesh Belakhindi <girishec28 at gmail.com>wrote: > Dear Experts, > > Can anybody please direct me to proper MDCT theory reference which will > help me understand the code better? > > I'm trying to optimize MDCT for a embedded platform. So need

Hi, Can you apply this change to the MDCT test and run it again. See if more (all) sizes pass. Given the results, I strongly suspect an overflow. Jean-Marc On 08/05/15 01:21 PM, Viswanath Puttagunta wrote: > Hello Jean-Marc, > > Below are the results that show test_unit_dft passes, but > test_unit_mdct fails (only for nfft=480, 960, 1920) > Note: Tested on

Dear Experts, Can anybody please direct me to proper MDCT theory reference which will help me understand the code better? I'm trying to optimize MDCT for a embedded platform. So need good understanding about theory behind & implementation. Thanks in advance for your time. Warm Regards, Mahantesh -------------- next part -------------- An HTML attachment was scrubbed... URL:

I am attempting to port CELT to the TI C5515 DSP. I am compiling/assembling/linking with Code Composer Studio 4. I have enabled the TI_55 specific optimizations in my config.h file per this <http://lists.xiph.org/pipermail/celt-dev/2008-December/000033.html> post. However, I am getting several "undefined symbol" linking errors that do not make sense to me. According to the error

--- silk/NSQ.c | 18 ++------------- silk/NSQ.h | 27 ++++++++++++++++++++++ silk/arm/NSQ_neon.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++ silk/arm/NSQ_neon.h | 10 ++++++++ 4 files changed, 105 insertions(+), 16 deletions(-) diff --git a/silk/NSQ.c b/silk/NSQ.c index d8513dc..ec81f3b 100644 --- a/silk/NSQ.c +++ b/silk/NSQ.c @@ -205,7 +205,7 @@ void

--- silk/NSQ.c | 18 ++------------- silk/NSQ.h | 27 ++++++++++++++++++++++ silk/arm/NSQ_neon.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++ silk/arm/NSQ_neon.h | 10 ++++++++ 4 files changed, 105 insertions(+), 16 deletions(-) diff --git a/silk/NSQ.c b/silk/NSQ.c index d8513dc..ec81f3b 100644 --- a/silk/NSQ.c +++ b/silk/NSQ.c @@ -205,7 +205,7 @@ void

Dear all. According with my question. CELT CFFT size configuration I'm not completely sure about how the kiss_fft works for sizes which are not power of two, as occur in the case of celt which calculate the mdct using a fft sizes of 480, 240, 120, and 60, I guess that internally the input data is padded with zeros in order to compute efficiently the mdct using the Cooley and Tukey

Dear all I'm working on the implementation of the MDCT for the processor ARM-Cortex-M4 I'm trying to replicate the behavior of the MDCT for several overlapped values however I realized that current implementation of the MDCT is very close to the theory only in case in which we have and overlap exactly equal to N/2 where N is the size of the input vector as is shown in the examples for

Hi, Since our device can only handle the Celt part of Opus (due to a MIPS limitation), we have two questions: 1. Is it possible to via SDP force the remote party to send a specific mode of the 32 different possible modes or to force the remote side to use CELT only? 2. In the reference implementation of Opus it looks like the only way to force the encoder to use CELT only

Hello opus-dev, Can we please have review on RFCv2? We have quite a few optimizations (Eg: ifft/mdct_backwards, fixed point fft/ifft mdct_forward/backward etc) that are in my pipeline that depend on this patch series being accepted. Regards, Vish On 4 February 2015 at 12:21, Viswanath Puttagunta <viswanath.puttagunta at linaro.org> wrote: > Changes from RFC PATCH v1: > - passing

Felicia Lim wrote: > Hi Yves, > > At that time, the issue wasn't reproducible in opus master, but there > had been some significant changes since the last tagged release that > made it hard to pinpoint a single patch to cherry pick to Chromium, > hence this local fix. I'm not convinced that using a saturating add here is the correct thing to do, either (as opposed