similar to: CELT grabbing 100KB of memory right off the top

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

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

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

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

Hello, I want to use the CELT codec in an embedded solution. For the embedded solution, the processor speed is of great importance. In the documentation (the presentation of Dr. Jean-Marc Valin, Gregory Maxwell and Dr. Timothy B. Terriberry) the CELT LC (low complexity) mode is mentionned. The LC mode should use half the memory recources and half the MIPS. My question is how to tell the CELT

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

If everything has moved and this mailing list has gone dormant, how about an official announcement as well as official pointers to the new stuff? It would also be good to have some sort of "migration document" given that you have to do specific things to OPUS in order to get the old CELT behavior. Thanks, -a

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.

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

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

Dear all, I am reading with R some measurements vectors from an external device. The length of each vector (containing numbers) is not constant. I would like by doubling the numbers of elements I select to shrink the vector to a new one Let's call the vector I read from the device as oldvector and the shrinked version of it as newVersion I want to have newVersion[1]<-

Found this code: ftp://ftp.samba.org/pub/unpacked/ntdb/lib/ccan/ilog/ilog.c Tests show that it's faster to use the following code in FLAC__bitmath_ilog2_wide(): static const unsigned char DEBRUIJN_IDX32[32]={ 0, 1,28, 2,29,14,24, 3,30,22,20,15,25,17, 4, 8, 31,27,13,23,21,19,16, 7,26,12,18, 6,11, 5,10, 9 }; FLAC__uint32 v; int m;

Hi all ! I just learned about the Opus codec and would like to try it out on my NRF52 (Cortex-M4) target.   I've been struggling a bit with the "trival_example.c" setup but repeatedly run into "hard fault" crashes when stepping through the code. Firstly; for a "bare bone" configuration, does the following compiler directives make sense ? UDEFS =

I have undertaken a small project of writing a Vorbis decoder completely from the spec, with the goal of catching any errors, both typographically and algorithmically, in the spec. My "reference" decoder is also being written in an extremely methodical style, with practically no algorithmic optimization, such that it will be clear that every step has been copied exactly from the spec.

Dear all, I have a large vector (lets call it myVector) and I want to plot its value with the logic below yaxis<-myVector[1] yaxis<-c(xaxis,mean(myvector[2:3]) yaxis<-c(xaxis,mean(myvector[4:8]) yaxis<c(xaxis,mean(myvector[9:16]) yaxis<c(xaxis,mean(myvector[17:32]) this has to stop when the new ..... yaxis<c(xaxis,mean(myvector[1024:2048]) will not find the correspondent number

Dear all, I'm working with Cox-regression, because data could be censored. But in this particular case not. Now I have a simple example: PRO and PRE are (0,1) coded. The response is not normal distributed. We are interested in a model which could describe interaction. But my results are depending strongly in the choose of the contrast option. It is clear that there is some dependence in

Dear All,   I have difficulty in installing the package of Rcplex. Its description web is at http://cran.r-project.org/web/packages/Rcplex/index.html   First, I tried -------------------------------------------------------------------------------------------------- url <- "http://cran.r-project.org/src/contrib/Rcplex_0.3-0.tar.gz"; download.file(url, basename(url),

Dear all Below is the code for "scriptPreFilter.R" which gives the following result: > source("scriptPreFilter.R") > prefltr <- new("PreFilter", mad=c(0.5,0.01)) [1] "------initialize:PreFilter------" [1] "------initialize:Filter------" > str(prefltr) Formal class 'PreFilter' [package ".GlobalEnv"] with 2 slots

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#ffffff" text="#000000"> Hi,<br> <br> I''ve been working on seamless looping of our CELT encoded sound banks.<br>

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