similar to: Multithreaded encoding?

I'm not aware of any other attempts, and there have never been official plans. It's difficult to partition input for opus at anything other than the track level, because of the way the decoder derives its adaptive state from recently-seen audio. I guess cutting together streams with at least an 80ms overlap wouldn't glitch too much? You could probably do something to try different

>>> Ralph Giles <giles at thaumas.net> schrieb am 30.03.2020 um 23:17 in Nachricht <11930_1585603054_5E8261ED_11930_50_1_c110a52d-de95-3bbb-35b2-eca12c79f143 at thaum s.net>: > I'm not aware of any other attempts, and there have never been official > plans. It's difficult to partition input for opus at anything other than > the track level, because of the way

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

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

2017-06-16 10:28 GMT-05:00 Jesus Cea <jcea at jcea.es>: > On 16/06/17 13:18, Marvin Scholz wrote: >> The source client is supposed to encode the metadata into the stream, >> not use any endpoint whatsoever to send them, for Ogg and >> other supported formats. There is nothing confusing about this. The >> reason this is different for MP3 and AAC is, that it is

Hi, We just released Opus 1.1.4, which fixes a single bug. A specially-crafted Opus packet could cause an integer wrap-around in the SILK LSF stabilization code. This would cause an out-of-bounds read 256 bytes before a constant table. In most circumstances, the consequences are harmless and the result is simply noise in the audio. This was reported as CVE-2017-0381 [1]. Contrary to that report,

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

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 those interested in testing it, there's an experimental patch to make opus-tools use libopusenc for the encoder:

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

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

Until today I could do this to backup my primary IMAP4 server: """ doveadm backup ssh csi doveadm dsync-server """ It doesn't work anymore after upgrading to Dovecot 2.2.18: """ jcea at ubuntu:~$ doveadm backup ssh csi doveadm dsync-server Enter passphrase for key '/home/jcea/.ssh/id_rsa': dsync-remote(root): Error: Mailbox INBOX: Failed

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 Sat, 2015-10-24 at 22:16 -0700, Thomas Daede wrote: > Everything above 96kbps on that table is speculative, as the highest > multi-participant listening testing done was at 96kbps. Here's the > results from that test, if you're curious: > > http://listening-test.coresv.net/results.htm > > As you can see, at that rate Opus ranged from slightly perceptible to >

I am using mdbox for dovecot storage. I wonder if I could skip "dovecot.index.cache" files and, in general, "*.cache" files when doing mail backup. Those files are big and change frequently. What I feel from reading documentation [1][2] is that they could be dropped in the backups, to be recreated on the fly if needed. But I would like expert confirmation. [1]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rsync 3.0.9 here. I am using a rsync script like: """ rsync -z --numeric-ids -a -H --inplace --delete --delete-excluded - --stats --progress -v --itemize-changes SOURCE DESTINATION """ I detected the following issue when RSYNCing a bunch of Mercurial repositories. It is very dangerous, because it will corrupt files.

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would like to know the blocksize of a particular file. I know the blocksize for a particular file is decided at creation time, in fuction of the write size done and the recordsize property of the dataset. How can I access that information?. Some zdb magic?. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea at

On 30/3/20 23:17, Ralph Giles wrote: > I'm not aware of any other attempts, and there have never been official > plans. It's difficult to partition input for opus at anything other than > the track level, because of the way the decoder derives its adaptive > state from recently-seen audio. I guess cutting together streams with at > least an 80ms overlap wouldn't glitch

On 16 Jun 2017, at 5:41, Rick Keniuk wrote: > Is this the HTTP call for injecting the “song” metadata? > This is a capture (using RawCap in conjunction with Wireshark) of my > AAC+ stream metadata input to IceCast that works fine. > > GET > /admin/metadata?mode=updinfo&mount=%2FFVHradio_AAC&song=Fox%20Valley%20Hit%20radio%20-%20Hits%20from%20the%20Valley > HTTP/1.0

On 24/8/20 7:12, Fabien KOCIK wrote: > First, extract user list using doveadm users '*'. > Then process this list to fit your needs (seven parts for a week and a > part processed by week day for example). > Finally, use -u option of doveadm purge into a loop. This is a good idea for installations with tons of users. Good point. I would be personally interested in incremental