search for: allcap

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

...ject? 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 > announcement? > To: Andrew Lentvorski <bsder at allcaps.org> > Cc: celt-dev at xiph.org > Message-ID: > <CAAS2fgSShUwdzPsGxPYy2cb42fRO0Pd9_uSc1Fyey1KWBGZBYA at mail.gmail.com > > > Content-Type: text/plain; charset=UTF-8 > > On Mon, Jul 11, 2011 at 6:02 AM, Andrew Lentvorski <bsder at allcaps.org> > wrote:...

...; 2. a new hard link should be created in backup.0/ to the copy in backup.1/ > > In fact, rsync (at least as of 2.5.6) seems to copy the full file: --link-dest is built on --compare-dest and behaves like --compare-dest as indicated in the manpage. Observe the description of --compare-dest (ALLCAPS added for emphasis): This option instructs rsync to use DIR on the des? tination machine as an additional directory to com? pare destination files against when doing transfers IF THE FILES ARE MISSING IN THE DESTINATION DIREC?...

...: opus-bounces at xiph.org [mailto:opus-bounces at xiph.org] On Behalf Of Edwin van den Oetelaar Sent: Saturday, June 07, 2014 5:22 PM To: Andrew Lentvorski Cc: opus at xiph.org; Jean-Marc Valin Subject: Re: [opus] High Sampling Rates On Sat, Jun 7, 2014 at 10:58 AM, Andrew Lentvorski <bsder at allcaps.org<mailto: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 &qu...

I downloaded wine but when I try to invoke it I get this message ... wine: could not load L"c:\\windows\\system\\program.exe": Module not found What does that mean? how can I fix it? and how can I get Wine to start running?

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

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

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 "mar...

Hi, This message is to let the R developers know that the pdfs for the first two volumes of the printed edition of R reference manual are available at, http://www.network-theory.co.uk/R/base/vol1.pdf http://www.network-theory.co.uk/R/base/vol2.pdf I've divided the manual into "core commands" of the base package (control flow, and related programming commands, etc) in Volume 1

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

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

...kup.0/ to the > > copy in backup.1/ > > > > In fact, rsync (at least as of 2.5.6) seems to copy the full file: > > --link-dest is built on --compare-dest and behaves like --compare-dest > as indicated in the manpage. > > Observe the description of --compare-dest (ALLCAPS added for > emphasis): This option instructs rsync to use DIR on the des­ > tination machine as an additional directory to com­ pare destination > files against when doing transfers IF THE FILES ARE MISSING IN THE > DESTINATION DIREC­ TORY. > > In other words, the files in the...

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

Is there are description somewhere of how CELT packs into the .oga file? Trying to reverse engineer it from the intertwined celtenc code is suboptimal. -a

I'd like to store all of my music in FLAC form; however, I would also like to stream the library as Vorbis. Is there a tool to do on the fly stream encoding to Vorbis from FLAC? Basically, I'm looking for something that is almost like a DJ application that lets you pull in the FLAC files, do whatever DSP algorithms you need, and then code them into Vorbis and shove them out a stream.

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

More data: On My OS X machine, with no ASM, I get the following result which agrees with the Raspberry Pi 2: $ ./encode_known_packet Encoded to bytes: 29 Packet size: 0x29 d0 7f 29 1a fa 2b 33 81 70 22 58 6a 3b 0f 3f b5 66 ff ce da 93 9b c2 e9 f1 7a d0 61 fc 0e a6 75 9c 2b 8e 14 92 d6 20 09 c6 00 00 00 00 00 00 00 "make check" indicates 12 tests all passed. It looks like this is an

On 8/25/15, 12:25 AM, Treuillard, Benjamin wrote: > The aim of my project is to transmit voice over CAN bus. CAN? 8 byte transactions. CRC. Bit stuffing on 5 bit repeats. Automatic retransmits. No ordering. Really? I guess if you *have* to, but I would pick pretty much *any* interface standard *other* than CAN for audio. > The main issue I have is that opus fail to allocate memory,