similar to: Opus 1.2-alpha

Xiph.Org is pleased to announce that we've released Opus 1.2. The 1.2 release includes: . Speech quality improvements especially in the 12-20 kbit/s range . Improved VBR encoding for hybrid mode . More aggressive use of wider speech bandwidth, including fullband speech starting at 14 kbit/s . Music quality improvements in the 32-48 kb/s range . Generic and SSE CELT optimizations .

Hi everyone, Just to let you know that Opus 1.2 is finally here. This major release brings many quality improvements, new features, and bug fixes. You can read all the details (and hear audio samples) in this release demo page page: https://people.xiph.org/~jm/opus/opus-1.2/ Changes since 1.1.x include: - Speech quality improvements especially in the 12-20 kbit/s range - Improved VBR encoding

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi to everybody. First of all I hope this is the right place to discuss such an (nitpicky) issue. I've just been testing the current Opus release and for mere curiosity compared its performance to WMAPro with CD quality music at low bitrates (48 kbit/s). While Opus generally does a very good job, I found one particular example (a high pitched

Hi Felicia, A few comments: > - /* CELT can only support up to 20 ms */ > subframe_size = st->Fs/50; > - nb_subframes = frame_size > st->Fs/25 ? 3 : 2; > + nb_subframes = frame_size/subframe_size; This will use six 20ms frames to make a 120ms packet, even for SILK-only mode where frames can be up to 60ms. For SILK, two 60ms frames would be a more

Attached is the amended second patch. It now extends the multistream API as well to 80/100/120 ms and incorporates changes based on Mark's comments. Thanks, Felicia On Mon, Jun 13, 2016 at 4:21 PM Felicia Lim <flim at google.com> wrote: > Hi Mark, Jean-Marc, > > Thanks for your comments. > > On Sun, Jun 12, 2016 at 6:34 AM Mark Harris <mark.hsj at gmail.com>

Hello all, This is slightly off-topic, but should be of interest to some people on this list. I just released version 0.3.2 of the CELT ultra low-delay audio codec (http://www.celt-codec.org/). CELT is designed to encode high quality speech and music with less than 10 ms delay and at rates starting from around 32 kbit/s. This version is "special" in that it is the basis for some

Hi, I wondered if are there any further thoughts on these patches? Thanks, Felicia On Thu, Jun 2, 2016 at 2:13 PM Felicia Lim <flim at google.com> wrote: > OK, I've amended the second patch and also added 80 and 100 ms. > > Thanks, > Felicia > > > On Thu, Jun 2, 2016 at 7:20 AM Jean-Marc Valin <jmvalin at jmvalin.ca> wrote: > >> On 06/01/2016 02:06

Thank you Mark. I agree and have now updated the pull request with a new commit, addressing your comments. Please take a look. /Gustaf On Fri, 5 Apr 2019 at 11:41, Mark Harris <mark.hsj at gmail.com> wrote: > On 2019-04-01 3:37, Gustaf Ullberg wrote: > > Hi everyone, > > > > Some time ago, I sent a pull request > > <https://github.com/xiph/opus/pull/107>

Thanks Jean-Marc, I was able to get both encode and decode working the CC3220 device! But for bi-directional communication, I need decode and encode to occur in less time than the frame size I’m sending (20 ms). Currently decode takes 16~22 ms and encode is ~13 ms. What is the best way to try to reduce this time? Also, unsure why encode is taking less time than decode... I've also

Hi Ulrich, thanks for the suggestion. My concern is that one of the valid inputs is "2.5", which would require conversion to an int, e.g. x10, but doing something like this would start to affect the code readability. On Mon, Jun 27, 2016 at 3:02 PM Ulrich Windl < Ulrich.Windl at rz.uni-regensburg.de> wrote: > Hi! > > A note on style: Looking at this chunk of the patch

Hello everyone, I have been having trouble utilizing the PLC function (I think). In older versions (0.7.1) a pointer to NULL did the trick, but with code from the tip of the GIT repository, this method causes the codec to crash on the C55x fixed point platform. I have not determined where the crash occurs. I have also attempted to pass in an array of zero's and this creates an echoey, reverby

Hi All, Since I continue to base my work on top of Jonathan's patch, and my previous Ne10 fft/ifft/mdct_forward/backward patches, I thought it would be better to just post all new patches as a patch series. Please let me know if anyone disagrees with this approach. You can see wip branch of all latest patches at https://git.linaro.org/people/viswanath.puttagunta/opus.git Branch:

Using -i should prevent failing if the files don't exist. --- appveyor.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/appveyor.yml b/appveyor.yml index c85b0b1..ad9c6c0 100644 --- a/appveyor.yml +++ b/appveyor.yml @@ -17,7 +17,7 @@ build: verbosity: minimal after_build: -- cmd: 7z a opus.zip win32\VS2015\%PLATFORM%\%CONFIGURATION%\opus.lib include\*.h +- cmd: 7z

Hi Timothy, As I mentioned earlier [1], I now fixed compile issues with fixed point and resubmitting the patch. I also have new patch that does intrinsics optimizations for celt_pitch_xcorr targetting aarch64. You can find my latest work-in-progress branch at [2] For reference, you can use the Ne10 pre-built libraries at [3] Note that I am working with Phil at ARM to get my patch at [4]

?? hi ?Jean-Marc, ? thanks for your answer. But still I am struggling to find a reasonable upper limit for the RAM sizes. ? You say we need 4.5/9.0 kB for enc/dec per channel. But are those sizes really independent of any settings, like frame_size, bitrate, complexity, etc. ? ? at least in our configuration I find these requirements:? ?- native stack: < 2.1kB (enc or dec) measured by RealView

Hi everyone, I've made several posts recently about CELT being "replaced" by the Opus codec ( http://opus-codec.org/ ) and I thought it was time to give an update on what's going on. As many of you know, I've been involved at the IETF on this new Opus codec, which essentially merge (a modified version of) Skype's SILK codec with CELT. This is more than just two codecs

? There seems to be a memory violation when calling celt_mode_create(48000, 240). ? The function compute_pulse_cache() calls celt_alloc (the second one, bits=celt_alloc()) in order to allocate 343 byte, but it is using about 872 bytes at that location, which will be deleted by the following allocations. ? In this case the following encoder call crashes at first run. ? Sorry, my time is very

Changes from RFC PATCH v1: - passing arch parameter explicitly - reduced stack usage by ~3.5K by using scaled NE10 fft version - moved all optimization array functions to arm_celt_map.c - Other cleanups pointed out by Timothy Phil, As you mentioned earlier, could you please address all compile and linker errors/warnings coming out of Ne10 library? You can find my working Ne10 repo at [1] You

Changes from RFC PATCH v3 - Just rebased on tip - For all else, please see notes from RFC PATCH v3 at http://lists.xiph.org/pipermail/opus/2015-March/002902.html - latest wip opus tree/branch https://git.linaro.org/people/viswanath.puttagunta/Ne10.git branch: rfcv4_final_fft_ne10 Viswanath Puttagunta (1): armv7(float): Optimize encode usecase using NE10 library Makefile.am