Opus issueshttps://gitlab.xiph.org/xiph/opus/-/issues2018-11-26T18:44:40Zhttps://gitlab.xiph.org/xiph/opus/-/issues/1978opus_decode fails on >20ms zero-length frame following hybrid frame2018-11-26T18:44:40ZMark Harrisopus_decode fails on >20ms zero-length frame following hybrid frameopus_decode fails with OPUS_BAD_ARG on a packet containing a 40ms or 60ms LP zero-length frame when it follows a hybrid or MDCT frame.
The attached ogg opus file contains ten 40ms packets. The duration of the expected output is 400ms -...opus_decode fails with OPUS_BAD_ARG on a packet containing a 40ms or 60ms LP zero-length frame when it follows a hybrid or MDCT frame.
The attached ogg opus file contains ten 40ms packets. The duration of the expected output is 400ms - 6.5ms pre-skip = 393.5ms. However, opus_decode and the opusdec tool fail after the first packet. The 1.0 reference implementation decodes it successfully.
The first packet contains two 20ms Hybrid SWB frames, and the others each contain one 40ms LP WB frame. The first 40ms LP WB frame has a length of 0, invoking PLC.Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1968URL incorrect in celt/entdec.c2018-11-26T18:44:40ZTony WilsonURL incorrect in celt/entdec.cThe MMW98 pdf is in .../ee398a/... The MMW98 pdf is in .../ee398a/... Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1962Quality is poorer when the FrameSize is 10 ms2018-11-26T18:44:40ZCedrick FonkwaQuality is poorer when the FrameSize is 10 msRunning PESQ score with OPUS codec show that the quality is not as good with 10ms packet size as with others (20, 40, 60).
Example:
Mean PESQ with 8 kHz - 10000 kbps - 10 ms : 3.19
Mean PESQ with 8 kHz - 10000 kbps - 20 ms : 3.75
Is...Running PESQ score with OPUS codec show that the quality is not as good with 10ms packet size as with others (20, 40, 60).
Example:
Mean PESQ with 8 kHz - 10000 kbps - 10 ms : 3.19
Mean PESQ with 8 kHz - 10000 kbps - 20 ms : 3.75
Is there any reason that could explain this ? Jean-Marc ValinJean-Marc Valinhttps://gitlab.xiph.org/xiph/opus/-/issues/1961libopus and libspeex can not be statically linked in same application2018-11-26T18:44:40ZGitlab Botlibopus and libspeex can not be statically linked in same applicationtrying to link libopus and libspeex in a static application on OS X (i.e. ffmpeg) fails due to duplicate symbols:
```
ld: duplicate symbol _pitch_xcorr in lib/libopus.a(pitch.o) and lib/libspeex.a(ltp.o)
```
to work around this, pitch_...trying to link libopus and libspeex in a static application on OS X (i.e. ffmpeg) fails due to duplicate symbols:
```
ld: duplicate symbol _pitch_xcorr in lib/libopus.a(pitch.o) and lib/libspeex.a(ltp.o)
```
to work around this, pitch_xcorr in opus could be renamed to opus_pitch_xcorrJean-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 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/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/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/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/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/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/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 Valin