similar to: Opus 1.3 release date?

Thanks for all the amazing work with ambisonics Drew et al. We're looking forward to the 1.3 final release and have already been successfully using the ambisonic work in production code. Varun -- Engineering Manager Facebook Audio ---------------------------------------------------------------------- Message: 1 Date: Sun, 3 Jun 2018 13:02:18 +0100 From: Peter Robinson

Hi, I just released Opus 1.3-beta. This is a beta release towards the upcoming Opus 1.3. Changes include: - The spec fixes in RFC 8251 are now enabled by default - Improvements to the VAD and speech/music classification using an RNN - Improvements to stereo speech coding at low bitrate - Added support for ambisonics projection using mapping 3 (disabled by default) - Fixes to the CELT PLC

Hi everyone, I'm happy to announce that Opus 1.3 was just released. This major release again brings quality improvements, new features, and bug fixes. You can read all the details in this release demo page: https://people.xiph.org/~jm/opus/opus-1.3/ Changes since 1.2.x include: - Improvements to the VAD and speech/music classification using an RNN - Support for ambisonics coding using

Hi, I just released Opus 1.3-rc. This is a release candidate for the upcoming Opus 1.3. Changes include: - Making it possible to use SILK down to bitrates around 5 kb/s - Using wideband encoding down to 9 kb/s - Improving security (including a new --enable-hardening option) - Minor quality improvement on tones - Improving Ambisonics support (still experimental) - Minor bug fixes It's likely

Aside from compilng with -Os, you'll have to look at the exact pieces you're using and remove the others. For example, if you're always encoding in SILK mode, then you can remove the CELT encoder (but not the decoder if you want to remain compliant). There's a lot of things you may not need, but it's highly application-specific, so there's no defines for each piece.

(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

I use the Opus multistream encoder for both mono and stereo encodings and after updating from 1.1.3 to 1.3 I noticed the size of the produced Opus files had doubled for 1-channel encodings whereas switching to the standand Opus encoder gave me roughly the same sizes as before. In these tests, I'm encoding an 8kHz mono stream containing only speech with the following options set: frame length

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg Maxwell tagged the v0.1.6 release of opus-tools earlier this week, and I've now posted source and binary packages. The binaries are built against the Opus 1.0.2 Jean-Marc announced last week, so these are a good way to pick up those changes. This release includes many build fixes, especially for Windows, as well as some minor correctness

Any luck reproducing the problem with opus_demo or opus-tools? Jean-Marc On 02/22/2018 10:14 PM, Stepan Salenikovich wrote: > > > On Thu, Feb 22, 2018 at 9:53 PM, Jean-Marc Valin <jmvalin at jmvalin.ca > <mailto:jmvalin at jmvalin.ca>> wrote: > > On 02/22/2018 09:34 PM, Stepan Salenikovich wrote: > > Its unexpected because the decoder continues to

Just to be clear, my goal here wasn't to make fun of anyone, but to drive the point that spectrograms should *never* be used to demonstrate quality. The only case where they can sometimes be useful is for diagnostic purposes. If you hear something and you're not sure what you're hearing exactly, then sometimes a spectrogram can help you figure out what it is. That's pretty much it.

Hi Robert, The file is not distributed in the official releases, but I can find it in the git repository. Cheers, Jean-Marc On 10/22/2018 03:53 AM, Robert Madinger wrote: > Hi Jean-Marc, > > thank you for that suggestion! > It seems that the file "fixed_c6x.h" is not part of the Opus sources, so the compiler cannot find it after enabling the TI_C6X_ASM config option.

On 10/28/2013 01:37 PM, Antonio Juan wrote: > The problem is that for using this package I need to use all the libs > like ogg, even Speex?, You do not need Speex. You do need libogg because .opus files *are* Ogg files. > no, and also where i can find an easy example > like opus_demo.c to create the .opus file There's an easy example called opusenc in the opus-tools package :-)

Thanks for your help, I will follow that, so in order to sum up I need: - libopus 1.0.3 compiled as static or shared library - libogg 1.3.1 compiled as static or shared library - opus-tools 0.1.7 and then follow the example in opus-tools opusenc.c to get things ready, because if I try to compile opus-tools, this ask for me for the speex library, and other things I think that that will we all.

The email might have been blocked due to the attachment size, here?s a link to it. https://www.dropbox.com/s/r9j7l3cbb02ob7i/opusDtx_noiseFix1_inOut.zip Pascal On 26/06/14 19:02, "Pascal Huart (phuart)" <phuart at cisco.com> wrote: >Hi Jean-Marc, >Thanks for the fix, the reconstructed signal is now much better. >Unfortunately there are still discontinuities which show

On 02/20/2018 06:48 PM, Rodriguez, Vince wrote: > I am trying to get the library to build without using the pseudostack > define, and use either VAR_ARRAYS or ALLOC, but it seems the global > stack is not defined. Not sure what you mean here. If your compiler supports C99 VLAs, then by all means just define VAR_ARRAYS and you're good to go. If not, the second best option is alloca(),

--- releases.sha2 | 1 + 1 file changed, 1 insertion(+) diff --git a/releases.sha2 b/releases.sha2 index dc0a6fce..334976b1 100644 --- a/releases.sha2 +++ b/releases.sha2 @@ -40,6 +40,7 @@ cfafd339ccd9c5ef8d6ab15d7e1a412c054bf4cb4ecbbbcc78c12ef2def70732 opus-1.2.1.tar 96fa28598e8ccd558b297277ad59a045c551ba0e06d65a9675938e084f837669 opus-1.3-rc.tar.gz

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,

FYI, the README file section on building for Windows says to see the README.md files in the cmake or meson subdirectories, but there are no README files in either of those subdirectories. -----Original Message----- From: opus <opus-bounces at xiph.org> On Behalf Of Jean-Marc Valin Sent: Monday, March 4, 2024 12:52 PM To: opus at xiph.org Subject: Re: [opus] Opus 1.5 is out -- now with ML