similar to: Mailing list and project shutdown announcement?

On 6/7/14, 1:55 AM, Jean-Marc Valin wrote: > Actually... no! 24-bit can indeed be useful as extra margin and Opus > can actually represent even more dynamic range than 24-bit PCM. That's > not the case for 192 kHz. There's no "margin" that 192 kHz buys you > over 48 kHz. You can do as much linear filtering as you like, the > stuff above 20 kHz isn't going to

So, once all those things are in place what Andrew says WILL happen? I think plans as important as that deserves an announcement. Roadmap for the project? Future directions for the main committers? Are there patent issues? Date: Mon, 11 Jul 2011 20:45:14 -0400 > From: Gregory Maxwell <gmaxwell at gmail.com> > Subject: Re: [CELT-dev] Mailing list and project shutdown >

Is there a particular reason why CELT grabs 100KB of stack immediately? Is that really required or can that be trimmed down some/a lot? -a

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

I need to test the latency of a system that I ported CELT to. I'd like to set a flag when the stream "changes". In order to see the stream "change", I'd like to be able to scan the compressed CELT directly to set the flag. ie. I'd like to be able to find a byte or two that change reliably between two values when the stream "changes". I don't

All, Just a heads up that the IETF codec working group has issued a last call on the draft Opus specification. This means we think the draft adequately documents the format, and that we're willing to live with whatever bugs are present in the reference implementation, if they can't be fixed without breaking decodes. In turn, this means we could really use some feedback from implementers.

How does one deal with the case when an fread callback doesn't have any more data but is going to get more data in the future? In particular, this is an issue when reading an incoming Ogg stream from a socket (icecast2, in this case). The issue is that the fread can't return 0 (that signals EOF and hoses everything), and it doesn't have a negative code that says come back later

That article is a bit too dismissive. I agree that one cannot hear the difference between 48KHz/16bit and 192KHz/24bit if you just transfer the data directly to the audio output device. As such, there is no good reason for Opus to support higher than 48KHz (especially since this is lossy compression, anyway). However, in general, that's not all you do with audio data. 192KHz is useful for

Hi, folks, I have an old CELT thing that I'm updating to Opus and I'm trying to get individual pieces upgraded.  My first task is upgrading the CELT encoder to Opus. The old CELT thing treated the L and R channels as independent mono streams, encoded them somehow with CELT to form one bitstream, sent one bitstream across, and then unpacked it manually after the decoder. Can I do that

? Do you have any references for me to investigate, I am trying to understand how noise is reduced by introducing higher sampling rates. (I tried to search, but maybe it is so obvious that nobody even explains it) This is not very obvious. It requires you to understand basic signal processing theory. I will give some pointers below. Any physical signal (e.g. audio coming out of speaker, current

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

I have been trying some different sample rate and bitrate combinations to get a feel for how CELT behaves. I then encoded it with a couple of different frame sizes and sample rates. There were some small differences, but nothing horrible. So, I decided to run with 24KHz sample rate with 16 bit samples. This seemed like a reasonable tradeoff against the quality degradation that my folks

On Sat, Jun 7, 2014 at 10:58 AM, Andrew Lentvorski <bsder at allcaps.org> wrote: > > > On 6/7/14, 1:55 AM, Jean-Marc Valin wrote: > > Actually... no! 24-bit can indeed be useful as extra margin and Opus > > can actually represent even more dynamic range than 24-bit PCM. That's > > not the case for 192 kHz. There's no "margin" that 192 kHz buys

I was digging around and saw a bunch of different people have created ways of building libopus for android (even I did one back in the CELT days). Is there an official one somewhere that I missed? I even notice this is the Google sources, but it seems to be a touch long in tooth at this point: https://android.googlesource.com/platform/external/libopus/+/android-wear-5.1.1_r1 I am happy to build

Trying to figure out the best way to pull an active call out of a queue by unique id and put it on hold. I don't want to put it on hold on the agent's phone but I want it to be pulled away from the agent's phone and into Asterisk limbo somewhere. Shortly after I want to pull the same call out of limbo and redirect it back to either the same agent or another. I was thinking about call

Hi, I''m doing development with Mongrel 1.0.1 on Ruby 1.8.4 / OS X 10.4.10, and I''ve found that often when I shut down my server with ^C, it hangs for a while, gobbling up all CPU. Sometimes it stops after a few seconds, sometimes it''s run for several minutes at least. This happens across all the apps I develop on, but it seems to hang longer after

Hi folks. Is use Linux Mageia 2 Cauldron x86_64 and I install with repository wine. In system I have Code: wine64-1.3.25-2.mga2 wine64-gecko-1.2.0-1.mga1 wine32-1.3.25-2.mga2 lib64kwineffects1-4.7.0-3.mga2 wine-gecko-1.2.0-1.mga1 I installed 64-bit version because many applications ie Winrar 64bit I did not work. But now there are problems to me, I have a game Limbo

Hello, I am trying to create multiple matrices (to run a PVA) but can't import all of them from a .csv without the numbers treated as labels and not factors. I can enter the matrix slowly: Site05_96 <- matrix(c(0.07,0,0.03,0.00,NA,0.00, 0.09,0.166666667,0.31,0.42,NA,0.00, 0.00,0,0.00,0.00,NA,0.00, 0.00,0,0.00,0.00,NA,0.00,

<dynarray> was added to the C++14 standard, libc++ implemented it, and then it was removed. Now (from the standard’s point of view), it is in limbo. I would like to move it into std/experimental; to make it clear that it’s not a part of the standard. Any objections? Anyone using it? — Marshall

I'm trying to do a standalone build of Opus and I get the following messages when compiling for android arm64 using clang:   CC       silk/fixed/arm/warped_autocorrelation_FIX_neon_intr.lo silk/fixed/arm/warped_autocorrelation_FIX_neon_intr.c:43:37: warning: incompatible pointer types assigning to 'const long *' from 'long long *' [-Wincompatible-pointer-types]