similar to: libopusenc 0.1.1 released

Hi Drew, On 11/13/2017 03:34 PM, Drew Allen wrote: > Does your encoder support ch253/254? Not at this point. Only families 0 and 1 are supported. I think adding family 2 shouldn't be relatively straightforward, but adding family 3 would require some thought. Cheers, Jean-Marc > Cheers, > Drew > On Mon, Nov 13, 2017 at 12:33 PM Jean-Marc Valin <jmvalin at jmvalin.ca >

Hi Jean-Marc (and everyone else who replied), > Considering you're switching to Ogg, I think you should give libopusenc> a try. It does a really good job at getting rid of *all* discontinuities> -- to the point where you can chop a song into files less than one> millisecond each and it still sounds good. It's also pretty simple to> use. You just feed it audio and tell it

Hi Jean-Marc, thank you for looking into this. I'm using the current release version of libopus (1.2.1) and version 0.1.10 of opus-tools, both built from source. Libopusenc is the current git master. Indeed I cannot hear any glitches in continuous.opus, continuous.wav, and chained.wav. chained.opus decodes just fine with opusdec as well, but doesn't play properly in any standard audio

Hey Jean-Marc, Does your encoder support ch253/254? Cheers, Drew On Mon, Nov 13, 2017 at 12:33 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Hi, > > Just to let everyone know that I released libopusenc version 0.1.1. It > does not change the API/ABI compared to 0.1, but fixes a few bad bugs. > You can get it from https://www.opus-codec.org/downloads/ > > For

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

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

Just to confirm, I would use opeint_* for all the OpusGenericEncoder-related functions? On Tue, Mar 20, 2018 at 8:38 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > 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

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, Some comments on the libopusenc patch: + 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. + if (_oge_use_projection(h->channel_mapping)) + { + len=27+(h->channels*(h->nb_streams+h->nb_coupled)*2); + } + else + { +

1，you say “libopusenc depends only on libopus.”but 2，so，i add speexdsp source code ， but 3，so，i 。。。 but now，what can i do。i use libopus 1.2 and 1.2beta and 1.1.3 test -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20171101/40680ea1/attachment-0001.html> -------------- next part -------------- A

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

Opus 1.1.2. As experienced in previous release: """ ./test-driver: line 107: 25185 Illegal instruction "$@" > $log_file 2>&1 FAIL: celt/tests/test_unit_mathops """ -- Jes?s Cea Avi?n _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea

On 16/06/17 18:47, Marvin Scholz wrote: > This concatenation are valid streams, it's called chaining, afaik. So > players not supporting them are broken and the authors should be > notified about it, I think. And my question is... Is THAT the way an OPUS source communicates new metadata to the icecast server?. That is the question I would like to know :-). -- Jesús Cea Avión

I am interested in being able to encode a single Opus stream using several CPU cores. I get a raw audio input and "opusenc" can transcode it at 1200% speed (Raspberry PI 3B+). It saturates a single CPU core, but the other three are idle. Is out there any project to add multithreading options to "opusenc", or something in that line? Looking around, I have found this:

Hello Jean-Marc et all, I've attached an updated patch which I feel addresses all 3 cases. PTAL, Thanks! Cheers, Drew On Wed, Mar 7, 2018 at 8:39 PM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > Make sure the modified libraries work in all of these three cases: > 1) libopus 1.2.1 > 2) libopus master (or 1.3-beta) with --enable-ambisonics > 3) libopus master (or

Doing a "doveadm purge" today I got this: """ doveadm(jcea): Error: Corrupted dbox file /home/jcea/.thunderbird/dovecot/storage/m.686 (around offset=1385772): purging found mismatched offsets (1385742 vs 1380664, 185/275) doveadm(jcea): Warning: fscking index file /home/jcea/.thunderbird/dovecot/storage/dovecot.map.index doveadm(jcea): Warning: mdbox

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 zpool and zfs report different free space because zfs takes into account an internal reservation of 32MB or 1/64 of the capacity of the pool, what is bigger. So in a 2TB Harddisk, the reservation would be 32 gigabytes. Seems a bit excessive to me... - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at jcea.es -

Most documents around there talk abour "dsync", but the modern way is "doveadm backup". This command is not documented in the wiki and there are a few details missing, like how to use it thru SSH. I am currently doing some tests about how to backup my mdbox. I can do tests in local using: $ doveadm backup -u jcea -m proveedores/dovecot mdbox:/tmp/aa/ This will

I am using Dovecot 2.3.4. I could upgrade if necessary. I see this capabilities after login in: """ a OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN

On 16/06/17 21:18, Marvin Scholz wrote: > Exactly Ok, GREAT: Thanks. I have another question: Could a MP3 source send metadata updates using ICY metadata (like clients receive new metadata, but in reverse order) or MUST I update via the HTTP interface?. -- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea at jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/