similar to: opus Digest, Vol 118, Issue 9

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

tracked down the spectogram atrefact source; it comes from the resampler. so it's not really a bug, just a nuisance. let's hope in the future Opus will be able to save bitrate on simple audio parts as all other lossy and lossless codecs do. i think opus decreasing bitrate only when it thinks that audio is too complex for human to hear difference. that's a bad attitude.

Hello. Me again. Have you tried to encode piano solo? Noticed high bitrate Opus gave? And there's also artefact at 15kHz which wasn't in the original audio. Visible with Spek program. Download FLAC and Opus both files, new link: http://www.filedropper.com/example_3 FLAC full: 1084 kbps; FLAC solo: 465 kbps. with --bitrate 160: Opus full: 158 kbps; Opus solo: 190 kbps. Included also Spek

Thanks for the reply. For my application I unfortunately need a better signal reconstruction. It's not necessarily a problem that the constant DC voltage is removed, but the audio signal will need to be more exact because it's also studied visually. To be more exact, I need to record and transmit audio data recorded from animals (mostly birds). Are there ways to achieve a more similar

On 3 February 2015 at 01:31, Phil Wang <Phil.Wang at arm.com> wrote: > Hi all, > > I have already added support for scaled forward non-power-of-2 floating-point FFT: > https://github.com/projectNe10/Ne10/commit/79c3d787302f8d74b9bcfe6545d487cdf1b101d9 > > Two flags are added to cfg structure: is_forward_scaled and is_backward_scaled. > By setting is_forward_scaled to

help compiling Opus! i'm stuck at opusfile. configure says i don't have openssl package installed but Debian 9.4 thinks i do. this Debian only have Opus 1.2-alpha2 package, so i need to compile Opus by myself. seems even Debian developers having trouble compiling latest versions of Opus, what chances do i have to succeed? -------------- next part -------------- An HTML attachment was

Hi all, I have already added support for scaled forward non-power-of-2 floating-point FFT: https://github.com/projectNe10/Ne10/commit/79c3d787302f8d74b9bcfe6545d487cdf1b101d9 Two flags are added to cfg structure: is_forward_scaled and is_backward_scaled. By setting is_forward_scaled to anything but zero, ne10_fft_c2c_1d_float32_neon will scale the output. So we can remove need for one buffer on

On Fri, Dec 19, 2014 at 9:03 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Daniel K wrote: >> true, then why stop at 120ms and not support longer packets? > > https://tools.ietf.org/html/rfc6716#section-3.2.5 > > "...the audio duration contained within a packet MUST NOT exceed 120 ms..." If you're wondering why the limit exists, there are a

Hi Timothy, Because I don't see any memory overflow, remains only any memory corruption and for sure it happens inside the library. Has anyone managed to run this library on embedded systems such as STM32, NXP IMXRT1060? By using opus_demo code (decoding part)? Pls advise, Kind Regards, Leonid Shigris RT Engineer Email: LeonidS at riscogroup.com -----Original Message----- From: opus

Many people have run opus on small embedded devices. It may be the case that your VLA support isn't providing enough stack. You may want to try using the pseudostack mode which will instead put that memory on the heap and give you better control over making sure you have enough available. On Tue, Jun 4, 2024 at 10:28?AM Leonid Shigris <LeonidS at riscogroup.com> wrote: > > Hi

Hello, I had talked earlier with 'Timothy B. Terriberry' <tterribe at xiph.org>, about adding support for AVX instructions in Opus, but since he appears to be busy I would like to resend this on the mailing list. I've created a pull request https://github.com/xiph/opus/pull/5 to add the testing infrastructure for the changes before adding the actual code. A draft for the rest

> I don't believe this is an actual error. If it's truly possible for > these areas to overlap (I don't think it is), then something much more > serious than using memmove instead of memcpy needs to be done about it. In the C# version of this code, these two copy regions are stored in separate arrays entirely. I agree that there should be no normal way to have the memcpy

It's not that hard to repackage it, is it? Here you go: www.icer.nl/misc_stuff/flac.xcodeproj .zip On 06-05-13 23:37, Marcus Johnson wrote: > Ralph, for Mac OS you should download either the Unarchiver which is > free, or Entrophy which is what I use, but it costs like $15 I > believe, both support decompressing .7z and Entrophy supports > compressing TO .7z > > > On

Yes, regarding the unsigned to signed conversion you are right, it is implementation defined. I just had an issue a couple of years ago with a compiler which incorrectly treated unsigned overflow as undefined rather than implementation defined? Regarding the 64 bit profiling: I looked at the disassembly (gcc ?c ?S ?O2 ../opus/silk/sum_sqr_shift.c ?I../opus/include ?I../opus/celt) of the 64 bit

Hi! AFAIK, there are different version of AVX; maybe clarify which versions you use, and how you detect the availability of the instructions needed. Also you could point out which CPUs are expected to be supported. Also consider that besides Intel there still exists AMD ;-) Regards, Ulrich >>> "Velea, Radu" <radu.velea at intel.com> schrieb am 20.01.2016 um 19:02 in

Thanks Timothy. Media Source Extensions were much easier and high-level than using WebAssembly with the Web Audio API. Unfortunately, MSE does not support MIME "audio/ogg" and I had to put my OpusFiles into a WebM container file. What could we do to get MSE support for Ogg Opus files? I created this issue if it helps: https://github.com/w3c/media-source/issues/245. Would be happy to

On 7 Nov 2017 13:36, Lucas Clemente Vella <lvella at gmail.com> wrote: 2017-11-07 11:10 GMT-02:00 encrupted anonymous <sergeinakamoto at gmail.com<mailto:sergeinakamoto at gmail.com>>: did another test of many. NeroAAC q=1 @400kbps and Vorbis q=10 @412kbps shared 2nd place. OPUS @330 kbps - 3rd place. LAME MP3 q=0 @320 kbps - 1st place. ---JPEG file attached--- Please disable

using iTunes i've noticed that AAC is very good at re-encoding own lossy sound. let's test Opus! neroaacenc.exe -q 0.75 -if 000.wav -of 001.m4a neroaacdec.exe -if 001.m4a -of aac001.wav wavdiff.exe 000.wav aac001.wav Comparing 000.wav - aac001.wav... Max diff: -17.3867dB RMS diff: -33.0851dB Mean diff: -32.4582dB opusenc.exe --bitrate 512 "000.wav" 001.opus opusdec.exe 001.opus

FYI, the Ogg Opus encapsulation is now RFC 7845: https://tools.ietf.org/html/rfc7845 -------- Forwarded Message -------- Subject: [codec] RFC 7845 on Ogg Encapsulation for the Opus Audio Codec Date: Fri, 29 Apr 2016 19:47:28 -0700 (PDT) From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org CC: drafts-update-ref at iana.org, codec at ietf.org, rfc-editor at

On 25 February 2015 at 19:54, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Viswanath Puttagunta wrote: >> >> Can we please have review on RFCv2? We have quite a few optimizations >> (Eg: ifft/mdct_backwards, fixed point fft/ifft mdct_forward/backward >> etc) that are in my pipeline that depend on this patch series being >> accepted. > > >