similar to: OffTopic: What is the web git frontend you folks are using?

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

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

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.

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 >

? 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

Thanks for the input! --Albin On Sat, May 12, 2018 at 6:00 PM, Orestes Zoupanos <oresteszoupanos at hotmail.com> wrote: > Hi Albin! > > There may be some details at: https://tools.ietf.org/html/rfc7845#section-6 > > Otherwise, I hope someone else on this list might be able to give a better > formula for estimating packet size. > > Regards, > > Orestes >

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

Hello, I'm working on an Opus encoder block for GNUradio (a signal processing toolkit). I was wondering if there's some formula/heuristic for estimating the packet size average case / worst case given a certain encoder setting (assuming VBR). I need to provided a reasonable estimate to the GNUradio memory allocator. --Albin

Hey guys, Need an opinion on what to use for file versioning text conf files that get updated by scheduled rsync's etc. Need something that can watch the file, so it doesn't need an explicit checkin, and can be diffed by a web front end. I haven't any preference on backend either. Thanks for any suggestions, jlc

Firts of all Greetings From Cuba "Saludos" to all of the member of this list. My name it's Orestes Leal, at your service. Well, The problem it's the following: I have one ATI RADEON 200 Series Integrated into the mainboard (ATI Technologies Inc RC410 [Radeon Xpress 200]), the chip has 64 megs of Video and 64 shared from memory to a total amount of 128 megs, the Xorg says me

Note also that the packet size you give the encoder also acts as an absolute max on the bitrate. For example, if you ask for 32 kb/s VBR but give a max packet size of 120 bytes, then you're absolutely certain the bitrate will never go over 48 kb/s. Jean-Marc On 05/12/2018 12:42 PM, Albin Stigö wrote: > Just a follow up... I guess I was a bit confused about the VBR > setting. I realise

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

Not too sure what to think about this, considering M$'s track record with OSS and other competitors. Kind Regards, Keith Roberts ---------- Forwarded message ---------- To: opensuse-offtopic <opensuse-offtopic at opensuse.org> From: Basil Chupin <blchupin at iinet.net.au> Subject: [opensuse-offtopic] Microsoft struggles to get Hyper-V drivers in Linux kernel The

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

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]