search for: bsder

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

...not completely stranded, but a two-step pplaying process is less than ideal, and will probably re-encode all my music to mp3s relatively soon. I hope for everyone's sake that this problem is fixed soon (before v1.0 is released) as it will seriously affect the adoptation of the format is all BSDers are unable to listen to their ogg files/streams. Despite annoyances I've experienced, I'm glad ogg exists, and hope it will take over as the dominant format soon. __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yah...

...r 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 > 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> &g...

...ls. From: 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...

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

Hello BSDers, I'm running Apache in a chroot jail with suPHP. It needs an /etc/ passwd in the chroot so that suPHP can setuid to the owner of the PHP script, but there's nothing that requires the passwords to be valid. Does anyone have a script strips passwords out of master.passwd, sets all sh...

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

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,

I get the following message when cross compiling Opus 1.2.1 for android with clang in a standalone build.   CC       src/opus_decoder.lo src/opus_decoder.c:37:10: warning: You appear to be compiling without optimization, if so opus will be very slow. [-W#pragma-messages] # pragma message "You appear to be compiling without optimization, if so opus will be very slow." Looking at the

Hi, folks, Silly question.  When I go to: https://git.xiph.org/?p=opus.git what is the program serving that up? Thanks, -a