similar to: opusfile 0.8 release

I'm pleased to announce the release of opusfile v0.7. The opusfile and opusurl libraries provide a high-level API for decoding and seeking within .opus files on disk or over http(s). Changes since the v0.6 release: - Add API to access and preserve binary metadata. - Add support for R128_ALBUM_GAIN metadata tag. - Better seeking with continued packets and multiplexed streams. - Portability

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 opusfile version 0.6 I'm pleased to annouce the latest development release of the opusfile playback library. Changes since the v0.5 release: - Fix bugs with comment handling - Fix build for BSD - Fix bugs handling invalid and non-opus streams Some of these bugs kept basic functionality of the APIs from working at all, so we recommend all

opusfile version 0.9 is availble. Thanks to everyone who contributed! The opusfile and opusurl libraries provide a high-level API for decoding and seeking within .opus files on disk or over http(s). opusfile depends on libopus and libogg. opusurl depends on opusfile and openssl. Binaries for macOS will be available through homebrew soon. Changes since the v0.8 release: - Fix an invalid free

I'm pleased to announce the release of opusfile 0.12 The opusfile library provides seeking, decode, and playback of Opus streams in the Ogg container (.opus files) including over http(s) on posix and windows systems. opusfile depends on libopus and libogg. The included opusurl library for http(s) access depends on opusfile and openssl. Changes since the v0.11 release: - Fix stack overflow

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm pleased to announce the availability of opusfile v0.4. The opusfile and opusurl libraries provide a high-level API for decoding and seeking within .opus files on disk or over http(s). * https://ftp.mozilla.org/pub/mozilla.org/opus/opusfile-0.4.tar.gz * https://ftp.mozilla.org/pub/mozilla.org/opus/opusfile-0.4.zip *

I don't know. Derf? -r -------- Original Message -------- Subject: Re: [opus] opusfile 0.4 release Date: Sat, 24 Aug 2013 14:20:35 -0700 From: alpha thinktink With my old streaming thread I am able to retrieve a unicode file from a web server by converting the resource name to UTF-8 MBCS then uri encoding it before sending it to the server with "GET /[resourcename]

Dear Opus community, I'm trying to build opusfile as a shared (.dll) library on Windows 10 using Visual Studio 2017. I know there are prebuilt libraries, but those are depending on a whole bunch of other libraries and x86 (32 bit) only. Whenever I try to build opusfile, it generates opusfile.dll, which is basically empty (no functions), which makes it unuseable. This is most likely because

Hello all! I've attached an updated patch for opusfile, based on formatting suggestions I got for the opus and libopusenc patches. Cheers! Drew On Thu, Mar 22, 2018 at 9:19 AM Drew Allen <bitllama at google.com> wrote: > Thanks! 2 down, 2 to go. :D :D :D > > On Wed, Mar 21, 2018 at 11:19 PM Jean-Marc Valin <jmvalin at jmvalin.ca> > wrote: > >> Thanks, the

Minor thing missed: Adding the files to the VS project file. (Sorry for the direct reply, Drew, Gmail's interface always trips me up on mailing lists.) On Fri, Jul 6, 2018 at 6:06 PM Joshua Bowman <silverbacknet at gmail.com> wrote: > Minor thing missed: Adding the files to the VS project file. > > (Sorry for the direct reply, Drew, Gmail's interface always trips me up

Hello all, Sorry for the delay (got really sick last week). Attached are updated patches for libopus, libopusenc, opusfile and opus-tools. Note that the patches for libopusenc, opusfile and opus-tools are dependent on the patch for libopus. Please let me know if you have any additional followup comments or questions. Cheers, Drew -------------- next part -------------- An HTML attachment was

Hi Jean-Marc, I've modified my patches for libopus and libopusenc based on your suggestions. Cheers, Drew On Mon, Mar 19, 2018 at 2:05 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi Drew, > > I think the libopusenc patch is better, but there's still a few issues > left: > 1) The static MAX_PACKET_BUFFER_SIZE value is still problematic because > if you

Drew Allen wrote: > Please feel free to ask any questions or give any feedback you might > have. :) A few comments from a quick glance through the opusfile patch: You unconditionally #include <opus_projection.h> in the public header, but you haven't updated the libopus version requirement in configure.ac. Ideally, of course, libopusfile would continue to work with older

Hi Mark, Drew, On 03/20/2018 02:40 AM, Mark Harris wrote: > + int _oge_use_projection(int channel_mapping); > > These functions are part of libopusenc, so I'd expect them to have an > ope prefix like the other functions in the libopusenc library. I'd like to avoid using the ope_ prefix for functions that's aren't in the public API. Right now there are other functions

Excellent, thanks Tim for writing back so quickly! Cheers, Drew On Tue, Mar 6, 2018 at 6:25 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Drew Allen wrote: > >> Please feel free to ask any questions or give any feedback you might >> have. :) >> > > A few comments from a quick glance through the opusfile patch: > > You unconditionally

On 03/20/2018 11:51 AM, Drew Allen wrote: > Just to confirm, I would use opeint_* for all the > OpusGenericEncoder-related functions? Correct. Or you can also use oge_ if you like. Just don't use something that starts with an underscore. > On Tue, Mar 20, 2018 at 8:38 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > Hi

Thanks, the libopus and the libopusenc patches are now merged. Cheers, Jean-Marc On 03/20/2018 12:36 PM, Drew Allen wrote: > Attached is an updated patch based on Jean-Marc and Mark's comments. :) > > Cheers, > Drew > > On Tue, Mar 20, 2018 at 9:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > On

Just a report about compiler warnings generated when building opusfile from current git. Regards. # x86-Linux builds / gcc48 and clang-3.3 (no warnings) # x86-Linux builds / gcc34 src/opusfile.c: In function `op_calc_bitrate': src/opusfile.c:1777: warning: integer constant is too large for "long" type src/opusfile.c: In function `op_open2': src/opusfile.c:1131: warning:

On Mon, Mar 19, 2018 at 11:52 AM Drew Allen <bitllama at google.com> wrote: > Hello all, > > Sorry for the delay (got really sick last week). > > Attached are updated patches for libopus, libopusenc, opusfile and > opus-tools. > > Note that the patches for libopusenc, opusfile and opus-tools are > dependent on the patch for libopus. > > Please let me know if

Apologies! That patch will not work correctly with Opus 1.2. Will send an updated patch shortly!! On Mon, Mar 26, 2018 at 11:56 AM Drew Allen <bitllama at google.com> wrote: > Hello all! > > I've attached an updated patch for opusfile, based on formatting > suggestions I got for the opus and libopusenc patches. > > Cheers! > Drew > > On Thu, Mar 22, 2018 at

Hi Drew, I think the libopusenc patch is better, but there's still a few issues left: 1) The static MAX_PACKET_BUFFER_SIZE value is still problematic because if you link libopusenc with a new version of libopus that supports higher order projection or just more projection channels for order 3, then you will overflow the buffer. I think what you'd want is a _ope_opus_header_get_size() call