similar to: Opus 1.1 released

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, We just released Opus 1.1-beta and Monty wrote a nice demo showing off all the new features, including many improvements over the alpha release: http://people.xiph.org/~xiphmont/demo/opus/demo3.shtml As usual, the code can be downloaded from: http://opus-codec.org/downloads/ In addition to 1.1-beta, we also released 1.0.3, which includes a

Can somebody tell me where I can find the differences between OPUS 1.0 and OPUS 1.1? ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please

Hello. Attached are some patches that some Debian users of vorbis-tools have sent to our BTS over the years (numbers refer to Debian bugs). It'd be nice to see them integrated. They apply cleanly to SVN as of today. The largefile_support one is a bit bigger than just the configure.ac since the submitter adviced that config.h got included in all C source files before the standard includes,

Hello. Attached are some patches that some Debian users of vorbis-tools have sent to our BTS over the years (numbers refer to Debian bugs). It'd be nice to see them integrated. They apply cleanly to SVN as of today. The largefile_support one is a bit bigger than just the configure.ac since the submitter adviced that config.h got included in all C source files before the standard includes,

Hi, Thank you for your response. I pulled yesterday to commit da97db1ca1f92592af3534c9a2596da0e9a009ca, added a bunch of more defines to my compile options, and assembled & linked in armopts.s,celt_pitch_xcorr_arm.s. Performance jumped up from about 4.8 Mb/s to 5.3 Mb/s on the same device, so it is improvement. Not sure what other tweaks there would be to try, but if it could match the

Hi everyone, We finally made it! Opus is now standardized by the IETF as RFC 6716 (http://tools.ietf.org/html/rfc6716). See the announcements at: https://hacks.mozilla.org/2012/09/its-opus-it-rocks-and-now-its-an-audio-codec-standard/ http://www.xiph.org/press/2012/rfc-6716/ Feel free to spread those around :-) We're also releasing both 1.0.0 (same code as the RFC) and 1.0.1, which is a

Hi everyone, We finally made it! Opus is now standardized by the IETF as RFC 6716 (http://tools.ietf.org/html/rfc6716). See the announcements at: https://hacks.mozilla.org/2012/09/its-opus-it-rocks-and-now-its-an-audio-codec-standard/ http://www.xiph.org/press/2012/rfc-6716/ Feel free to spread those around :-) We're also releasing both 1.0.0 (same code as the RFC) and 1.0.1, which is a

(Please wrap your lines.) On Oct 26 01:38:34, Ulrich.Windl at rz.uni-regensburg.de wrote: > Playing with Opus 1.3 I converted a tone sweep with a sample rate of 96kHz (just for fun). Before I had converted that from WAV to FLAC, and to Vorbis without problems. Can you please post the original wav? I am not sure what Audacity means by a logarithmisch sweep. Is that a fixed number of Hertz per

Hi everyone, I have lately been evaluating the performance of various audio decoders, particularly for ARM devices (Cortex A8 / A9). The context is audio playback in a game engine, and thus decoding performance is of particular interest. Looking at Opus versus Vorbis on a Cortex A9 smartphone, the numbers look approximately like this: Vorbis (tremolo decoder) 9.3 Mb PCM/s Opus (libopus 1.1)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We just discovered some issues with the ARMv5E and Neon optimizations and have released 1.1-rc2 to address those. Other platforms are unaffected. Jean-Marc On 11/26/2013 02:06 AM, Jean-Marc Valin wrote: > We just released Opus 1.1-rc, which should be the last step before > the final 1.1 release. Compared to 1.1-beta, this new release >

Why does opus scale down frequency from 22k to 20k ? 64kbps<https://lh5.googleusercontent.com/-DGsEd1ijTBs/UDE3OFVrE5I/AAAAAAAADBo/bFcWQ6I4-Zk/s588/opus_64_test.png> 128kbps<https://lh3.googleusercontent.com/-3Wfvq6OPGRw/UDE3OClxEdI/AAAAAAAADBk/vsBJ9Gcd_pU/s589/opus_test.png>

Just to make sure, what's the goal here? Is the goal 1) to have a fast Opus implementation or are you 2) looking for an interesting FPGA implementation project? If 1), then an FPGA is most likely not necessary since Opus is not computationally expensive. If 2), then it depends on the desired size of the project and the desired quality. The simplest encoder possible is indeed simpler than the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We just released Opus 1.1-rc, which should be the last step before the final 1.1 release. Compared to 1.1-beta, this new release further improves surround encoding quality. It also includes better tuning of surround and stereo for lower bitrates. The complexity has been reduced on all CPUs, but especially ARM, which now has Neon assembly for the

On Fri, Nov 16, 2018 at 7:40 PM ongaku zettai <sergeinakamoto at gmail.com> wrote: > Hello. > i have over 30GB of Opus music and noticed that > solo instrumentals and solo vocals uses more bitrate > than full-mixes. > Here's example where Opus 1.3 used 190 kbps for > piano solo and 159 kbps for full-mix. > (--bitrate 160 --music) > Download example piano solo

Hi, Opus team I'm Huang Hao and trouble you again. When I used the OpusRepacketizer as Jean-Marc mentioned, I got a result (maybe problem I'm not sure) that perplexes me, please give me some comments. The result be described as below: First(all init which are needed I have done), I used opus_encode() to get the encoded data successfully. The encoder control parameters are set: VBR=0,

Hi, I have found differences in quality between opus_demo and opusenc/opusdec. I used for both applications the same raw pcm file,16 bit,48khz,litle endian. i use libopus 1.1-beta and opus-tools-0.1.7. The command for opus_demo is: opus_demo audio 48000 1 64000 -cvbr -framesize 10 in.pcm out.pcm For opusenc/dec: opusenc --raw --raw-chan 1 bitrate 64 -cvbr --framesize 10 in.pcm in.opus

I know the focus for Opus is low delay, but I've been watching its development with interest because of the potential for audiobook/podcast use, where latency is practically irrelevant. I hear the upcoming USAC codec will give good results for this niche (though listening test results don't seem to be available to the public yet), but I also hear it'll be extremely patent

>>> Jan Stary <hans at stare.cz> schrieb am 05.11.2018 um 11:05 in Nachricht <20181105100534.GB44329 at www.stare.cz>: > (Are we off‑list now by intention?) No, just fooled by the list defaults (some need just reply, others need reply to all) > >> Did you also try to listen at the beginning, shortly before the real tone > appears in the audible spectrum?

Hi I am Rupesh from India. I have a huge directory of size 93.5 gb with 8500 mp3 files and 2000 sub directories. All these mp3s are speeches recorded by someone at 64 kbps. I want to compress these files recursively to opus using lame or another tool with 16 kbps bit rate and 11050 sample rate. I have compressed the above huge directory with above options using ffmpeg and the resulted

Hi! Playing with Opus 1.3 I converted a tone sweep with a sample rate of 96kHz (just for fun). Before I had converted that from WAV to FLAC, and to Vorbis without problems. With Opus I noticed that the file size for 48kHz and 48 kbps compared to 96kHz Vorbis at 31kbps is about double the size and it sounds even worse (than Vorbis) (there is a lot of noise in the lower frequencies when a low