similar to: celt-dev Digest, Vol 34, Issue 2

? 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

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

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

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

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I believe what you want is called Opus custom (OPUS_CUSTOM in the code). With that you can compile only the contents of the celt/ directory and use it like the old CELT. Jean-Marc On 07/06/2015 06:48 PM, Andrew Lentvorski wrote: > Is there a configuration or compile flag that lets me disable the > SILK portion of the codec and use CELT

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

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

On Mon, Jun 02, 2003 at 03:32:04PM -0700, Michael Rubel wrote: > Hi J.W., > > Please pardon this intrusion on your private address; the rsync list seems > to be down (no messages since yesterday), so I'm forwarding this directly > to you. If you'd rather wait until the list restarts, that's fine too. I'm CCing the list. > > Best regards, > Mike >

I am aware of a couple CELT users running the codec across a bit-error channel where corruption takes the form of flipped bits (such as a raw wireless link) rather than a packet-loss channel (like ethernet or an IP network). CELT has been designed to work reasonably well on both kinds of channel. You can turn a bit-error channel into a packet-loss channel by including a CRC across the entire

On 07/06/14 02:35 AM, Andrew Lentvorski wrote: > 192KHz is useful for the same reason that 24 bits is useful. > Digital operations often need the extra margin for many of the > operations being carried out (IIR-type effects, mixing multiple > sources, etc.) This is especially true for the so-called "wet" > effects that tend to mangle phase vs frequency (vs "dry"

Andrew P. Lentvorski wrote: > I'm trying to do a standalone build of Opus and I get the following > messages when compiling for android arm64 using clang: What version?

On 25/03/16 14:15, Oliver Freyd wrote: > Hi samba folks, > > I'm running an NT$-style samba PDC and 2 BDCs. They are all on > samba 3.6.25 (the SERNET packages on debian wheezy) > > I have a domain trust with another server on another subnet, > I think they run samba 3.5, also NT4-style domain. > > Everything ran fine, they can login to our machines and vice versa,

Hi samba folks, I'm running an NT$-style samba PDC and 2 BDCs. They are all on samba 3.6.25 (the SERNET packages on debian wheezy) I have a domain trust with another server on another subnet, I think they run samba 3.5, also NT4-style domain. Everything ran fine, they can login to our machines and vice versa, winbind can resolve their usernames etc. Now I upgraded the PDC to debian jessie,

Way back: > > ---------- Forwarded message ---------- Date: Mon, 2 Jun 2003 > > 09:56:50 -0700 (PDT) From: Michael Rubel <mrubel at > > galcit.caltech.edu> To: rsync at lists.samba.org Subject: > > --link-dest when target and compare_dir both have file > > > > Hi J.W. et al, > > > > Kevin Everets was kind enough to inform me about some