similar to: "Official" libopus project for Android?

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

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

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

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

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

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

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.

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 >

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]    

? 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

Hi, I'm aware that the language definition states "R objects are often coerced to different types during computations". Two questions: 1. Is it possible to configure the R environment so that, for example, coercion from (say) numeric to integer will throw a warning or an error? I realize that in the base R code alone, there are thousands of calls to as.integer() which would

Hi All, We are using libopus 1.0.2 lib version currently and observing one crash issue in opus_encode() function some times. ------------------------------------------- (gdb) bt #0 0x00007fcdf7c90ea2 in opus_encode () from /usr/lib64/libopus.so.0 -------------------------------------------- Anybody faced this problem earlier and have any idea whether its solved in the latest version libopus

Hi Matěj, I had a look at your files and it seems like the issue is that the speech/music detector thinks that some segments are speech rather than music and at low bitrates SILK tends to significantly narrow the stereo image. We're planning on adding an option to opusenc to force it to treat the input as speech/music. Just to confirm that's the issue, can you try encoding with the

Hello, I'm not a programmer or Opus developer but I tried to test the sound quality of a music file (Nick Warren - Devil's Elbow, freely available from the author's Soundcloud account) encoded with libopus 1.2 RC1. I used Windows binaries from free-codecs.com. I noticed that in the case of my selected music file (which is generally harsh on lossy codecs as it's necessary to

The libopus encoder's opus_encode() method is documented as "Encodes an Opus frame". Does that mean that it always produces a single Opus frame (i.e. the number of frames in the TOC byte will always be 0)? It's not clear from the documentation, but the fact that it cannot produce a 120ms Opus packet makes me wonder if that was the intention and any multi-frame Opus packets must

I just recently found that opus_multistream_encode_float is returning -1 (OPUS_BAD_ARG) with the libopus 1.1 build but works just fine with the libopus 1.0.1 and libopus 1.1-beta builds. I tried using opus_multistream_encoder_create and opus_multistream_surround_encoder_create. Tried with coupled and uncoupled quadraphonic and uncoupled stereo encodes. I'm dynamically loading the libopus

Hi, I'm looking for the description of possible combinations of libopus parameters. For instance in case of low bitrate encoding (voip application, SILK part) it does not have sense to set 2 channels. Audio applications (CELT part) widely use 2 channels. What about HYBRID mode? Is it closer to voip or audio applications? What is the typical number of channels? Can constant bitrate be used in

I am developing an arm based application which is soon to be released. I noticed on this list mention of neon instruction optimisations in the git version of libopus (which I will be testing shortly) whose speed improvements I would very much like to benefit from in my application. However I would also very much like to be able to release my application based on an official libopus release,

how can i obtain an exe of the newest libopus? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20160716/c742a84a/attachment.html>