Opus issueshttps://gitlab.xiph.org/xiph/opus/-/issues2020-08-08T17:36:52Zhttps://gitlab.xiph.org/xiph/opus/-/issues/2327CMake - Consistent warning levels between autotools and cmake2020-08-08T17:36:52ZMarcus AsteborgCMake - Consistent warning levels between autotools and cmakeIf things blow up on automake it should blow up on cmakeIf things blow up on automake it should blow up on cmakehttps://gitlab.xiph.org/xiph/opus/-/issues/2330Make decoder state completely relocatable by avoiding inline pointer to mode2020-08-06T12:42:35ZDan RavivMake decoder state completely relocatable by avoiding inline pointer to modeCurrently, Opus Decoder state can be freely moved in memory in the same process, but it can't e.g. be copied as bytes to be sent across the network and set as a state for another decoder. But it *almost* can! The only thing preventing th...Currently, Opus Decoder state can be freely moved in memory in the same process, but it can't e.g. be copied as bytes to be sent across the network and set as a state for another decoder. But it *almost* can! The only thing preventing this use case is the `mode` pointer at the start of `CELTDecoder`. A clean decoder state on one machine has identical bytes to those of a clean state on another machine with the same architecture, except for possibly the bytes of the `mode` pointer - even when the mode itself is the same.
I'm not sure how to fix this in a way compatible with any custom mode, but it would be nice to be able to do this for the default mode, at least.https://gitlab.xiph.org/xiph/opus/-/issues/2325float to short improvements2020-06-16T14:23:47ZMarcus Asteborgfloat to short improvements[22:58.40] <+jmspeex> xnorpx: About rounding, I actually think the right solution is to write functions that convert whole vectors at a time and then we can just use the normal run-time intrinsics method
[22:59.09] <+jmspeex> BTW, does S...[22:58.40] <+jmspeex> xnorpx: About rounding, I actually think the right solution is to write functions that convert whole vectors at a time and then we can just use the normal run-time intrinsics method
[22:59.09] <+jmspeex> BTW, does SSE2 even have a proper way to round without messing with rounding modeshttps://gitlab.xiph.org/xiph/opus/-/issues/2318Problem with `SATURATE` and `SROUND16 ` macros?2020-06-16T04:19:34ZVikram DattuProblem with `SATURATE` and `SROUND16 ` macros?Please have a look at below macros from celt/fixed_generic.h:
```c
#define SATURATE(x,a) (((x)>(a) ? (a) : (x)<-(a) ? -(a) : (x)))
#define SATURATE16(x) (EXTRACT16((x)>32767 ? 32767 : (x)<-32768 ? -32768 : (x)))
/** Shift by a and rou...Please have a look at below macros from celt/fixed_generic.h:
```c
#define SATURATE(x,a) (((x)>(a) ? (a) : (x)<-(a) ? -(a) : (x)))
#define SATURATE16(x) (EXTRACT16((x)>32767 ? 32767 : (x)<-32768 ? -32768 : (x)))
/** Shift by a and round-to-neareast 32-bit value. Result is a saturated 16-bit value */
#define SROUND16(x,a) EXTRACT16(SATURATE(PSHR32(x,a), 32767));
```
1.
As one can see clearly that macros `SATURATE` and `SATURATE16` are not similar when `SATURATE` is used for value 32767 or 32768.
Shouldn't the macro SATURATE be like:
`#define SATURATE(x,a) (((x)>(a) ? (a) : (x)<-(a + 1) ? -(a + 1) : (x)))`
or is it good as it is?
2.
The macro `SROUND16` uses `SATURATE` with value 32767.
Shouldn't it use SATURATE16 instead as it considers lower bound for 16 bits; -32768 as well?
Please note that this will in turn also enable some platform optimised instructions which saturate the value in certain bits.https://gitlab.xiph.org/xiph/opus/-/issues/2326undefined behavior in silk_NSQ_del_dec_neon2020-06-14T07:36:42ZRalph Gilesundefined behavior in silk_NSQ_del_dec_neonCompiling for aarch64 with gcc 9.3.0, I get an undefined behaviour warning:
```
silk/arm/NSQ_del_dec_neon_intr.c: In function ‘silk_NSQ_del_dec_neon’:
silk/arm/NSQ_del_dec_neon_intr.c:422:55: warning: iteration 80 invokes undefined behav...Compiling for aarch64 with gcc 9.3.0, I get an undefined behaviour warning:
```
silk/arm/NSQ_del_dec_neon_intr.c: In function ‘silk_NSQ_del_dec_neon’:
silk/arm/NSQ_del_dec_neon_intr.c:422:55: warning: iteration 80 invokes undefined behavior [-Waggressive-loop-optimizations]
422 | NSQ->sLPC_Q14[ i ] = psDelDec->sLPC_Q14[ i ][ Winner_ind ];
| ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
silk/arm/NSQ_del_dec_neon_intr.c:421:9: note: within this loop
421 | for( ; i < NSQ_LPC_BUF_LENGTH; i++ ) {
| ^~~
```https://gitlab.xiph.org/xiph/opus/-/issues/2320silk_LPC_inverse_pred_gain_neon methods reads memory outside of the intended ...2020-06-14T03:57:12ZRomansilk_LPC_inverse_pred_gain_neon methods reads memory outside of the intended bufferThe problem connected with attempt to read data outside of the intended buffer in method silk_LPC_inverse_pred_gain_neon.
Buffer of length MAX_LPC_ORDER (=16) is placed in silk_find_LPC_FIX stack:
```C
opus_int16 a_tmp_Q12[ MAX_LPC_OR...The problem connected with attempt to read data outside of the intended buffer in method silk_LPC_inverse_pred_gain_neon.
Buffer of length MAX_LPC_ORDER (=16) is placed in silk_find_LPC_FIX stack:
```C
opus_int16 a_tmp_Q12[ MAX_LPC_ORDER ];
```
Attempt to read the buffer outside boundaries in silk_LPC_inverse_pred_gain_neon
```C
t0_s16x8 = vld1q_s16( A_Q12 + 0 );
t1_s16x8 = vld1q_s16( A_Q12 + 8 );
t2_s16x8 = vld1q_s16( A_Q12 + 16 );
```
Backtrace of methods
silk_LPC_inverse_pred_gain_neon
silk_NLSF2A
silk_find_LPC_FIXhttps://gitlab.xiph.org/xiph/opus/-/issues/2321.exe opens CMD and closes it.2020-06-13T22:50:59ZJose.exe opens CMD and closes it.How can I even open the .exe when it closes right after?How can I even open the .exe when it closes right after?https://gitlab.xiph.org/xiph/opus/-/issues/2324SILK complexity levels 1 and 2 are inconsistent2020-06-01T19:22:07ZFrancis QuiersSILK complexity levels 1 and 2 are inconsistentIn `silk_setup_complexity()`, it seems that the parameters chosen for complexity levels 2 and 3 are mostly swapped (except `nStatesDelayedDecision`)In `silk_setup_complexity()`, it seems that the parameters chosen for complexity levels 2 and 3 are mostly swapped (except `nStatesDelayedDecision`)https://gitlab.xiph.org/xiph/opus/-/issues/2323Equivalent bitrate calculation is broken for <20ms frame sizes2020-05-26T04:56:56ZHector MartinEquivalent bitrate calculation is broken for <20ms frame sizesThis leads to negative bitrates at smaller frame sizes, which does bad things like making all bands available for intensity stereo coding.
So, for example, encoding with these parameters:
`opusenc --hard-cbr --bitrate 192 --framesize 2...This leads to negative bitrates at smaller frame sizes, which does bad things like making all bands available for intensity stereo coding.
So, for example, encoding with these parameters:
`opusenc --hard-cbr --bitrate 192 --framesize 2.5`
Yields output that, when mono downmixed, sounds completely terrible, which definitely shouldn't happen at those bitrates (phase inversion intensity stereo should not be used).
Fix: [0001-celt_encoder-fix-equivalent-bitrate-calculation-for-.patch](/uploads/0cc8ff9d0576f97bfad81e649c8e67ec/0001-celt_encoder-fix-equivalent-bitrate-calculation-for-.patch)https://gitlab.xiph.org/xiph/opus/-/issues/2322Autogen failed on Cygwin2020-05-25T17:30:32ZredmanmaleAutogen failed on Cygwin`./autogen.sh` failed on Cygwin when trying to build from cloned repo:
```bash
Updating build configuration files, please wait....
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
autoreconf-2.69: libtoo...`./autogen.sh` failed on Cygwin when trying to build from cloned repo:
```bash
Updating build configuration files, please wait....
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
autoreconf-2.69: libtoolize failed with exit status: 1
```
Maybe it's because `ltmain.sh` is a symlink.
Building from tarball (without autogen) works fine.
**Env**
windows 10 x64
autoreconf 2.69
libtoolize 2.4.6
opus 1.3.1https://gitlab.xiph.org/xiph/opus/-/issues/2315Minor Issue on libopus 1.3-rc default framesize adjustment2020-04-22T04:19:26ZHeman BusschotsMinor Issue on libopus 1.3-rc default framesize adjustmentHi,
I couldn't post on the IRC for some reason, that's why I want to post it here.
On the libopus 1.3-rc (release candidate), I found it best to change the Framesize setting to 40.
In my case I could increase bitrate from 48kbps to 51kbp...Hi,
I couldn't post on the IRC for some reason, that's why I want to post it here.
On the libopus 1.3-rc (release candidate), I found it best to change the Framesize setting to 40.
In my case I could increase bitrate from 48kbps to 51kbps, where artifacts are hardly heard, while keeping the same file size.
These 3 extra bits, may seem little, but they're the difference between noticeable artifacts at 48kbps (in the stereo spectrum) to nearly fully transparent at 51kbps; all the while keeping the same file size.
Audio quality overall improved slightly thanks to this setting.
Setting it larger or smaller, did not increase quality or decrease filesize.
With that I just want to say that in my opinion, the newer release candidate, runs better with Framesize 40.
It would be nice to further be able to finetune this (between the ranges of 20-60) to see where the exact best setting is located.
The best framesize setting, could be 30, or it could be 45, without the ability to tune it any other than 20, 40, or 60, I wouldn't know...
Not sure if Opus can support such a feature?
Just like CPU complexity is by default set to 10, I think framesize should be set to 40 by default, on the RC candidate (1.3).
Aside from allowing a 6% higher bitrate, while keeping the same file size, it also allows for going much lower in bitrate before capping off the high frequencies.
For instance, For stereo music, I can go as low as 24kbps at almost 48kHz (I think it's capped to 32, but it's mostly inaudible); and for mono I can go as low as 12kbps, before the high frequencies are cut.
Using Framebuffer 20 or 60, has higher tresholds.https://gitlab.xiph.org/xiph/opus/-/issues/1997Opus trunk/1.1 fails to build - 'export' is a GNU make-ism2020-04-22T04:16:23ZBrad SmithOpus trunk/1.1 fails to build - 'export' is a GNU make-ismOpus trunk/1.1 has had someregressions over 1.0.x and fails to build..
checking for C99 variable-size arrays... yes
checking for cos in -lm... (cached) yes
/home/ports/pobj/opus-1.1/opus-1.1/configure[12816]:
${inline_optimization:0:3}...Opus trunk/1.1 has had someregressions over 1.0.x and fails to build..
checking for C99 variable-size arrays... yes
checking for cos in -lm... (cached) yes
/home/ports/pobj/opus-1.1/opus-1.1/configure[12816]:
${inline_optimization:0:3}": bad substitution
AM_CONDITIONAL([OPUS_ARM_INLINE_ASM],
[test x"${inline_optimization:0:3}" = x"ARM"])
AM_CONDITIONAL([OPUS_ARM_EXTERNAL_ASM],
[test x"${asm_optimization:0:3}" = x"ARM"])
*** Parse error in /home/ports/pobj/opus-1.1/build-amd64: Need an
operator in 'yes' (Makefile:2756)
# Provide the full test output for failed tests when using the parallel
# test suite (which is enabled by default with automake 1.13+).
export VERBOSE = yes
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1937opusenc : problem sample causes clipping2019-09-13T15:02:02ZJulian Hughesopusenc : problem sample causes clippingEncoding this 10 second pcm wav sample with opusenc 0.1.6 causes obvious clipping (repeated clicks in right channel) from about 7 seconds.
I tried default:
opusenc sample.wav sample.opus
That produced a file opusinfo shows as:
Average ...Encoding this 10 second pcm wav sample with opusenc 0.1.6 causes obvious clipping (repeated clicks in right channel) from about 7 seconds.
I tried default:
opusenc sample.wav sample.opus
That produced a file opusinfo shows as:
Average bitrate: 124.4 kb/s, w/o overhead: 123.3 kb/s
then I tried:
opusenc --bitrate 160 sample.wav sample_160.opus
That produced a file opusinfo shows as:
Average bitrate: 198 kb/s, w/o overhead: 196.8 kb/s
The 160 target file also clips.
Then I tried:
opusenc --bitrate 192 sample.wav sample_192.opus
That produced a file opusinfo shows as:
Average bitrate: 229.2 kb/s, w/o overhead: 227.7 kb/s
That plays without clipping. This is quite similar to Ogg Vorbis which on the same sample clips at -q 6 but is OK at -q 7. The sample is pcm from my retail CD and hasn't been touched by a lossy encoder. I've compressed it to flac for attachment.
Here are examples of what I did so you can see the version I'm using:
$ opusenc sample.wav sample.opus
Skipping chunk of type "LIST", length 26
Encoding using libopus 1.1-alpha (audio)
-----------------------------------------------------
Input: 44.1kHz 2 channels
Output: 2 channels (2 coupled)
20ms packets, 96kbit/sec VBR
Preskip: 356
Encoding complete
-----------------------------------------------------
Encoded: 10.02 seconds
Runtime: 1 seconds
(10.02x realtime)
Wrote: 155636 bytes, 501 packets, 13 pages
Bitrate: 123.112kbit/s (without overhead)
Rate range: 92.8kbit/s to 193.6kbit/s
(232 to 484 bytes per packet)
Overhead: 0.924% (container+metadata)
$ opusinfo sample.opus
Processing file "sample.opus"...
New logical stream (#1, serial: 1ce42e69): type opus
Encoded with libopus 1.1-alpha
User comments section follows...
ENCODER=opusenc from opus-tools 0.1.6
Opus stream 1:
Pre-skip: 356
Playback gain: 0 dB
Channels: 2
Original sample rate: 44100Hz
Packet duration: 20.0ms (max), 20.0ms (avg), 20.0ms (min)
Page duration: 1000.0ms (max), 910.9ms (avg), 20.0ms (min)
Total data length: 155636 bytes (overhead: 0.924%)
Playback length: 0m:10.007s
Average bitrate: 124.4 kb/s, w/o overhead: 123.3 kb/s
Logical stream 1 ended
This is on i386 Debian Wheezy/Testing on AMD Athlon64 CPU. I built opus-tools from the tarball supplied at http://www.opus-codec.org/downloads.
I also built ffmpeg and opus from current git (yesterday) and get identical results when using ffmpeg -c:a libopus.
I tried playback/decoding with and without software sample rate conversion and ruled out any possibility of sample rate conversion artefacts. I got the same clipping whether running opusdec alone or doing 'opusdec sample.opus --force-wav - |mplayer -'Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1894exp_analysis doesn't work in fixed-point2018-11-26T18:44:40ZJean-Marc Valinexp_analysis doesn't work in fixed-pointThe exp_analysis branch added some float operations that need to be converted to fixed-point or #ifdef'ed out.The exp_analysis branch added some float operations that need to be converted to fixed-point or #ifdef'ed out.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1918OggIndex needs opus support2018-11-26T18:44:40ZGitlab BotOggIndex needs opus supportRight now one can not use Ogg with Theora and Opus with an index.
As a first step OggIndex needs support for Opus.
http://git.xiph.org/?p=OggIndex.git;a=tree
Right now one can not use Ogg with Theora and Opus with an index.
As a first step OggIndex needs support for Opus.
http://git.xiph.org/?p=OggIndex.git;a=tree
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1926Enhanced spatialization can lead to high-frequency swishiness after mixing do...2018-11-26T18:44:40ZkarlnordstromEnhanced spatialization can lead to high-frequency swishiness after mixing down to monoEnhanced spatialization during encoding can result in high-frequency swishiness after mixdown to mono. The problem becomes evident when the following conditions are true:
1. The encoder captures far-field (across-the room) audio in ster...Enhanced spatialization during encoding can result in high-frequency swishiness after mixdown to mono. The problem becomes evident when the following conditions are true:
1. The encoder captures far-field (across-the room) audio in stereo, and
2. the decoder side mixes the audio down to mono.
This can occur when the receiving side has a mono speaker. This is likely to occur in multi-chat with a mix of devices doing hands-free communication.
Reproducing the problem:
1. Capture far-field (across the room) speech with stereo mics.
2. Encode and decode with Opus.
3. Mix down to mono.
4. Listen.
Expected result:
Mono audio without audio artifacts.
Observed result:
High frequency "swishiness" due to high-frequency phase issues.
One (sub-optimal) solution is to just use the right or left channel for the mono signal instead of mixing the audio down to mono. However, this means that the mono signal will lose key information from the other channel.
The following patch eliminates the above-mentioned artifacts by not doing additional spatialization:
```
$ git diff
diff --git a/celt/bands.c b/celt/bands.c
index 62f0ee7..f493a81 100644
--- a/celt/bands.c
+++ b/celt/bands.c
@@ -794,7 +794,7 @@ static void compute_theta(struct band_ctx *ctx, struct split_ctx *sctx,
} else if (stereo) {
if (encode)
{
- inv = itheta > 8192;
+ inv = 0; // Don't reverse phase. leads to high-freq "swishiness" on mixdown to mono.
if (inv)
{
int j;
```
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1949genversion.bat doesn't work if path contains a space2018-11-26T18:44:40ZDietrich Eppgenversion.bat doesn't work if path contains a spaceOn Windows, the `genversion.bat` script doesn't seem to work if the path contains a space, e.g., `C:\Users\John Doe\...`. It works fine if I move the project to a path containing no spaces. Maybe the script could start with `cd` and th...On Windows, the `genversion.bat` script doesn't seem to work if the path contains a space, e.g., `C:\Users\John Doe\...`. It works fine if I move the project to a path containing no spaces. Maybe the script could start with `cd` and then work with relative paths?Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1952opus 1.0.2 not working fine in windows (xp/7)2018-11-26T18:44:40Zsasugumaropus 1.0.2 not working fine in windows (xp/7)i unzipped the opus 1.0.2 and build in windows xp. i tried to decode "testvector01.bit" which i hav downloaded from www.opus_codec.org.
with command arguments "-d 48000 2 testvector01.bit testvector01.pcm".
"testvector01.pcm" not matc...i unzipped the opus 1.0.2 and build in windows xp. i tried to decode "testvector01.bit" which i hav downloaded from www.opus_codec.org.
with command arguments "-d 48000 2 testvector01.bit testvector01.pcm".
"testvector01.pcm" not matching with "testvector01.dec" ref testvector.
but it is matching if it decoded in linux ubuntu. it is working fine with same arguments.
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1954celt_decode_lost() - very poor precision/wrong result in application of frac_...2018-11-26T18:44:40ZJ.Dodscelt_decode_lost() - very poor precision/wrong result in application of frac_div32( arg1, arg2 )
## Looking in celt_decode_lost() under the comment:
```
/* Check if the waveform is decaying (and if so how fast)
We do this to avoid adding energy when concealing in a segment
with decaying energy */
decay = celt_sqrt(...
## Looking in celt_decode_lost() under the comment:
```
/* Check if the waveform is decaying (and if so how fast)
We do this to avoid adding energy when concealing in a segment
with decaying energy */
decay = celt_sqrt( frac_div32(SHR32(E1,1),E2) );
```
We see that if E1=1 then the 1-bit right shift of E1 makes E1=0. Therefore ANY E1, E2 combinations like 1/2, 1/3, ... 1/n will evaluate to zero.
Similarly, for small values of E1 the precision of the result is needlessly poor (see table below).
Suggested fix: If the intent of shifting was done to bound the output of frac_div32 to (0.5,0] then an alternate solution which avoids the E1=1 pitfall (and poor precision on small values of E1) is to shift the _result_ of frac_div32(), instead.
```
decay = celt_sqrt( frac_div32(E1,E2)>>1 );
```
Here is a small table of test values to illustrate:
decay = celt_sqrt ( frac_div32(SHR32(E1,1),E2) );
====================================================
7FEB = celt_sqrt( 3FF36D10 = frac_div32(1303/1303)) <-- so-so
687C = celt_sqrt( 2AAAAAA0 = frac_div32( 11/ 15)) <-- not great
5A86 = celt_sqrt( 1FFFFFF0 = frac_div32( 3/ 4)) <-- very bad
0000 = celt_sqrt( 00000000 = frac_div32( 1/ 1)) <-- wrong
With suggested code fix:
decay = celt_sqrt( frac_div32(E1,E2)>>1 );
====================================================
7FF6 = celt_sqrt( 3FFFFFF8 = frac_div32(1303/1303))
6D97 = celt_sqrt( 2EEEEEE8 = frac_div32( 11/ 15))
6ED5 = celt_sqrt( 2FFFFFF8 = frac_div32( 3/ 4))
7FF6 = celt_sqrt( 3FFFFFF8 = frac_div32( 1/ 1))
Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1955what is the encoding parameters usef for opus testvectorx.bit2018-11-26T18:44:40Zsasugumarwhat is the encoding parameters usef for opus testvectorx.bithi! thanks for last reply. i am getting hard to find, what is the encoding parameters that is used for coding in the Bitconformance testvectorx.bit. pls send or ref some link regarding this.
i found decoding parameters
-d 48000 2 testv...hi! thanks for last reply. i am getting hard to find, what is the encoding parameters that is used for coding in the Bitconformance testvectorx.bit. pls send or ref some link regarding this.
i found decoding parameters
-d 48000 2 testvectorx.bit testx.out
any help greatly appreciated.
Jean-Marc ValinJean-Marc Valin