xiph / opus Goto Github PK

Minor nit of the README. It says:

There is also collection of standard test vectors which are not
included in this package for size reasons but can be obtained from:
https://opus-codec.org/testvectors/opus_testvectors.tar.gz

To run compare the code to these test vectors:

    % curl -O https://opus-codec.org/testvectors/opus_testvectors.tar.gz
    % tar -zxf opus_testvectors.tar.gz
    % ./tests/run_vectors.sh ./ opus_testvectors 48000

but curl -O only gives us an HTML file that tells us that the file has moved permanently to https://opus-codec.org/static/testvectors/opus_testvectors.tar.gz , and tar fails to decompress this.

To fix this, either the URL should be updated, or curl -LO should be suggested which follows redirects.

root@dou-pc:~/opus# make
./celt/arm/arm2gnu.pl < celt/arm/armopts.s > celt/arm/armopts-gnu.S
./celt/arm/arm2gnu.pl < celt/arm/celt_pitch_xcorr_arm.s > celt/arm/celt_pitch_xcorr_arm-gnu.S
make all-recursive
make[1]: Entering directory /root/opus' make[2]: Entering directory /root/opus'
CC celt/bands.lo
CC celt/celt.lo
CC celt/celt_encoder.lo
CC celt/celt_decoder.lo
CC celt/cwrs.lo
CC celt/entcode.lo
CC celt/entdec.lo
CC celt/entenc.lo
CC celt/kiss_fft.lo
/tmp/ccOBaCHb.s: Assembler messages:
/tmp/ccOBaCHb.s:281: Error: first destination register must be even -- ldrd r5,r6,[lr,fp]' /tmp/ccOBaCHb.s:292: Error: first destination register must be even -- ldrd r5,r6,[r9,fp]'
make[2]: *** [celt/kiss_fft.lo] Error 1
make[2]: Leaving directory /root/opus' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory /root/opus'
make: *** [all] Error 2

Autotools is pretty severely out-dated, and especially a pain to use on Windows. Some modern alternatives are CMake and Meson. CMake is probably the most popular C/C++ build system today, but it is quite insane (e.g. it is 'stringly typed' and even lists are just semi-colon delimited strings).

Meson is very new, but aims to be a much saner version of CMake. It is gaining popularity and I have implemented a rough version of a meson-based build system for Opus here.

It doesn't do everything your current one does, because honestly whenever I come near a configure.ac I get angry that anyone could allow such a monstrosity to exist, so I haven't worked out what all the options in the Opus build system are meant to do. But if someone were to explain it they could easily be added.

What do you think?

There are a few files that are applications, and I would recommend moving them to a separate folder, outside of the library folder:
src/opus_compare.c
src/repacketizer_demo.c

It will be more clean if library and demo apps are in separate folders.

If DTX is enabled, the Opus codec goes into DTX after 10 frames of inactivity, and then stays in DTX for 20 frames before coding the noise and sending a new frame.

In Silk only mode, DTX is entered after 9 frames of inactivity, and DTX is maintained for 21 frames before coding a new frame.

The behaviour of DTX should not differ depending on modes, and the latter behaviour does not match the macros in define.h:

/* DTX settings */
#define NB_SPEECH_FRAMES_BEFORE_DTX             10      /* eq 200 ms */
#define MAX_CONSECUTIVE_DTX                     20      /* eq 400 ms */

https://wiki.xiph.org/Opus_Recommended_Settings#Framesize_Tweaking

Increasing the frame duration also slightly improves coding efficiency, but the gain becomes small for frame sizes above 20 ms.

From this I understand that I get better quality from greater frame sizes than 20 ms, but only by a little.

https://wiki.xiph.org/OpusFAQ#What_frame_size_should_I_use.3F

For file encoding, using a frame size larger than 20 ms will usually result in worse quality for the same bitrate because it constrains the encoder in the decisions it can make.

And this says, that I will get worse quality.
So which one is the true?

I'm using on average 96kbps, stereo.

I recommend:

1. updating the documentation website.
2. adding comments about this in the "opus.h" header file, near the "opus_encode" function

Because without stumbling upon this problem I've always assumed that the best quality is achieved with highest frame size (60ms), but now it seems that 20ms gives better quality?
Perhaps you can make some constant in the header file:
#define OPUS_FRAME_SIZE_BEST_QUALITY 20
I'm asking for a define, in case in a future release of the library would offer some improvements, and for example 60ms would become the better solution than 20ms, in which you would just change
#define OPUS_FRAME_SIZE_BEST_QUALITY 60
and I could use the define in my own codes without worrying which one is the best.

src/opus_demo.c:870:40: runtime error: division by zero
#0 0x42a550 in main /home/user/code/opus/src/opus_demo.c:870:40
#1 0x7fd061d3782f in __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
#2 0x402de8 in _start (/home/user/code/opus/opus_demo+0x402de8)

On Ubuntu 16.04 with fresh clone, I see this error and not being a C developer I don't know how to address it.

opus$ ./autogen.sh
Updating build configuration files, please wait....
configure.ac:38: warning: macro 'AM_PROG_LIBTOOL' not found in library
configure.ac:38: error: possibly undefined macro: AM_PROG_LIBTOOL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1

I'm a passionate music listener, and a game developer, so I deal with a lot of music and sound files.
99.9% of the content that I encountered in my life is in 44.1 kHz sampling rate, but Opus does not support that. I'm really concerned about the resampling.

From the documentation https://wiki.xiph.org/OpusFAQ#But_won.27t_the_resampler_hurt_the_quality.3F_Isn.27t_it_better_to_use_44.1_kHz_directly.3F

The Opus encoder is heavily tuned for 48 kHz now and using it at 44.1 kHz will cause it to make sub-optimal decisions.

Isn't the better solution, is to add a special mode for the 44.1, and tune that mode the same way as 48 is tuned?
Because right now when trying to use Opus with 44.1, we have resampling + lossy compression on top of that. So 2 lossy operations.
If you would provide a tuned version of the encoder for 44.1 mode, then we would have only one lossy operation, which is the encoding, without having to do resampling. I think that would be the best solution.

I strongly believe that if you would add native support for 44.1 sampling rate, then Opus would become much more popular. Because, like I said at the start, at least in my experience, 44.1 is the 99.9% of the audio content flying on the internet, and because of the resampling needed, Opus doesn't seem like a perfect solution, for which I'm still sticking with Vorbis.

Hi Opus team,
Recently i want to porting opus in to Android. But there is not any document, resource out there to do so.
Could you please provide a sample Android application which use opus and provide a guide to build opus for Android ?

This causes incompatible-pointer compilation warnings with neon intrinsics on 64-bit systems.

So...

Opus doesn't seem to like a lot of electronic music... on this sample in particular it's having issues...

Here's the lossless

https://drive.google.com/file/d/1ERvzuTO86OcSTBcI7uOLlrY5dGaTE8Px/view?usp=sharing

Especially near the beginning and middle... near the end the music changes and I don't think it's as audible (but then again, I didn't test the end of the sample much... as I was hearing a lot of artifacting in the beginning and middle)

At 48kbps it has pretty much the same artifacting but MUCH more audible... it's mainly in the 0-1khz range... same with 320kbps

This is the sample encoded with Opus at 48kbps

https://drive.google.com/file/d/1DQrGaXP82Wx1H20nlPKtGY7Fts91i6nh/view?usp=sharing

It's whirling/thumping sounds that I'm hearing... mostly artifacts in the 0-1khz range... at 48kbps it's understandable... but at 320.... not so much

Oh, and here's the ABX test of 320kbps Opus versus lossless

https://i.imgur.com/FIsTWC4.png

It seems to be issues with mostly electronic music... at least, I think...

I used 1.2.1 Opus and VBR

As a comparison to AAC at 48kbps... you can tell it is a lot better because it doesn't have those whirling effects... or at least, drastically reduced

https://drive.google.com/file/d/1R36tsP0NrSxFvekfyeWXSzFMTK_YzkbV/view?usp=sharing

Now, AAC did use about 7% more bitrate overall... but even then... it's a LOT better

For my use cases, I would always prefer setting a specific quality over setting a target bitrate.
The needed average bitrate for the same audible quality can change drastically with a different source.
It would also make encoding simpler because you can leave your personal settings regardless of factors like the number of channels.
I would be really happy to see this feature one day.

I happened to come across this bug with spearmint, available at spearmint.pw. The description of this bug is, when you go to compile opus, the compiler gives out 4 warnings. Here's an excerpt of the warning as it happens:

CC code/opus-1.1/silk/NLSF2A.c
code/opus-1.1/silk/NLSF2A.c: In function ‘silk_NLSF2A’:
code/opus-1.1/silk/NLSF2A.c:121:17: warning: array subscript is above array bounds [-Warray-bounds]
Ptmp = P[ k+1 ] + P[ k ];
^
code/opus-1.1/silk/NLSF2A.c:122:17: warning: array subscript is above array bounds [-Warray-bounds]
Qtmp = Q[ k+1 ] - Q[ k ];
^
code/opus-1.1/silk/NLSF2A.c:121:17: warning: array subscript is above array bounds [-Warray-bounds]
Ptmp = P[ k+1 ] + P[ k ];
^
code/opus-1.1/silk/NLSF2A.c:122:17: warning: array subscript is above array bounds [-Warray-bounds]
Qtmp = Q[ k+1 ] - Q[ k ];
^

This also happens when compiling any project which uses opus, meaning it's probably also a bug with opus.

Hi ，
When I use opus in WICED-Studio-6.0.0.43(http://www.cypress.com/products/wiced-software), it will report compile errors like undefined reference to __aeabi_i2f' , undefined reference to __aeabi_fdiv' and so on . Do you have any suggestions ? thanks very much.

original: https://people.xiph.org/~tdaede/Xte.flac
64kbps: https://people.xiph.org/~tdaede/Xt_.opus
192kbps: https://people.xiph.org/~tdaede/Xt2.opus

I am personally unable to ABX this.

Hello and congrat for that wonderful project.

I have done a translation of the C header into pascal:

https://github.com/fredvs/uos/blob/master/src/uos_opusfile.pas

op_open_file() is working like charm with op_read().

But with op_open_memory() I have problem: op_read() gives always 0 as result.

Why ?

Thanks.

Fre;D

Using op_open_file()

HandleOP := op_open_memory(BufferURL[0],PipeBufferSize, Err);

op_test_open(StreamIn[x].Data.HandleOP);

I can retrieve the tags infos, all seems ok.

But for reading, using this gives 0 outframes:

outframes :=
op_read_float(Data.HandleOP, at Buffer[0], Wantframesm, nil);

Minor nit.

See this place in mathops.h and the cE definition above. We define cE but undef cD.

Is there a way to figure out all the configurable switches/flags/parameters while compiling the codec?

I ask this because NE10 does not find a mention on the website or the README, but seems to be a useful flag while compiling for mobile platforms that support NEON.

In case there is an automated way of figuring out these switches/flags/parameters, please help me point to it (something like a "opus --help" or "man opus").

When compiling Opus using the included VS2015 projects, the opus_strerror and opus_get_version_string functions are not exported into the resulting DLL.

This is caused because those functions are implemented in the CELT VS project, which, unlike the Opus project, does not define the DLL_EXPORT preprocessor symbol (as implemented in 6e96173).

Changing the CELT project properties to also define DLL_EXPORT causes the functions to be exported as expected.

(EDIT: As pointed out below, this is only a problem with 1.1.3 and has been fixed on master.)

In calls with DTX enabled there is sometimes an issue with periodic "noise bursts" during the DTX period. The issue appears when the background noise is slighty unstationary. In my experience the problem is common and can be triggered by noise from ventilation etc.

To illustrate the problem I have encoded a 10 seconds long file containing speech and slowly increasing noise.

I encoded the file with opus_demo from master as of May 8th 2018 (commit 1b58446). I used DTX and the highest complexity mode.

./opus_demo voip 48000 1 32000 -complexity 10 -dtx original.raw encoded.raw
libopus 1.3-beta-33-g1b584467
Encoding 48000 Hz input at 32.000 kb/s in auto bandwidth with 960-sample frames.
average bitrate:              15.400 kb/s
maximum bitrate:              64.400 kb/s
active bitrate:               25.930 kb/s
bitrate standard deviation:   17.448 kb/s

The issue can easily be seen in the following spectrograms. The first spectrogram shows the original file with the encoded file below.

The reason for these clicks is a mismatch between two voice activity detectors: the Opus VAD and the Silk VAD.
The Opus VAD decides when to go into DTX. During DTX a packet is transmitted every 420 ms containing an update of the background noise. If the VAD in the Silk layer of the codec considers the signal to be active (type TYPE_UNVOICED or TYPE_VOICED instead of TYPE_NO_VOICE_ACTIVITY) the decoder will conceal the DTX region by using packet loss concealment (PLC) instead of pure comfort noise (CNG). This will case a noise burst every time a packet is decoded.

I have created two competing pull requests: #84 and #87 . The two PRs solve the issue slightly differently.

PR #84 avoids DTX when the Opus and Silk VADs do not agree.

Pros of #84:
Behaves similarly to lower complexity modes (where only the Silk VAD is used).

Cons of #84:
Results in higher bit-rates (in this example DTX is alomost not used at all).

Encoding with opus_demo from pull request 84:

./opus_demo_pr84 voip 48000 1 32000 -complexity 10 -dtx original.raw encoded_pr84.raw
libopus 1.3-beta-34-g2e635837
Encoding 48000 Hz input at 32.000 kb/s in auto bandwidth with 960-sample frames.
average bitrate:              31.296 kb/s
maximum bitrate:              64.400 kb/s
active bitrate:               33.355 kb/s
bitrate standard deviation:    6.355 kb/s

Spectrogram showing the file encoded with PR84

PR #87 passes the result of the Opus VAD to Silk. If the Opus VAD says no activity the maximum value of the Silk VAD is clamped to just below the activity threshold. The Silk encoder then produces a frame with type TYPE_NO_VOICE_ACTIVITY.

Pros of #87:
Does not alter the decision of when to enter DTX (same bit-rate as master)

Cons of #87:
Slightly more code than #84.

Encoding with opus_demo from pull request 87:

./opus_demo_pr87 voip 48000 1 32000 -complexity 10 -dtx original.raw encoded_pr87.raw
libopus 1.3-beta-34-gdbc27362
Encoding 48000 Hz input at 32.000 kb/s in auto bandwidth with 960-sample frames.
average bitrate:              15.386 kb/s
maximum bitrate:              64.400 kb/s
active bitrate:               25.941 kb/s
bitrate standard deviation:   17.431 kb/s

Spectrogram showing the file encoded with PR87

I made all audio files available here (raw and wav formats):
https://drive.google.com/drive/folders/1wY-_yz5I44QTccmV0lFohTWHVIGH2Vqx

Conclusion:
Both pull requests solves the issue, but the DTX behavior of #87 is more similar to the current DTX behavior. I suggest that #87 is merged to master and #84 is withdrawn.

The clang static analyzer detects memory leaks due to early returns in opus_compare.c and opus_demo.c.

More info in this bug and patch from the WebKit project:
https://bugs.webkit.org/show_bug.cgi?id=186009
https://trac.webkit.org/changeset/232236

I am layman user of the codec. I chanced upon the NE10 switch while trawling the source code to find ways through which I could help improve the audio output performance of ExoPlayer since I was getting audible glitches. This was quite some time back. Meanwhile, it seems that the good folks at Google have added some NEON related things to opus (pardonne moi for my complete ignorance).

I have no idea whether NE10 has any utility any more, and whether removing it would have any impact. Furthermore, is there a need/mechanism to activate the NEON related things added to the codec or are they automatically activated?

Apologies for the dumb queries.

@mjbshaw @jmvalin

Hi all,

I used Freac converter which convert a mp3 track to opus then from the opus back to mp3. However, the lengths of the original and converted is now different. Could you give explanation?

Kind regards

Will

I'm trying to use the opus codec with ogg encapsulation in an iOS app. I came so far that I have data encoded into opus but I'm stuck at packaging it with Ogg.

Hi. I am on a sse-only machine. I noticed that in test_unit_rotation.c and test_unit_mathops.c some files that could use celt_inner_prod_sse by macro expansion of celt_inner_prod like pitch.c and vq.c are included before pitch_sse.c resulting in errors.

I only changed the order of the includes and it compiles fine. I'm not sure but also could be needed the inclusion of vq.c after pitch.c.

Maybe unrelated, but i don't know much about c/c++ but i like to learn and i wonder why the compiler could mark a macro function as an implicit declaration of that function. ¿do you know?. It happened to me on pitch_sse.h:115.

I think it's not needed but i will atach a build log and a little patch.

Thanks.

I could be wrong, but in the encoder-specific-ctls I see OPUS_GET_LAST_PACKET_DURATION documented with reference to the number of packets decoded instead of encoded:

_Gets the duration (in samples) of the last packet successfully _decoded* or concealed*

afaik the encoder isn't aware of a decoder so this seems like a typo to me.

I tried compiling this but I got an error at the first place:

$./autogen.sh
Updating build configuration files, please wait....
aclocal: error: aclocal: file 'm4/lt~obsolete.m4' does not exist
autoreconf: aclocal failed with exit status: 1

It complains that there is no m4/lt~obsolete.m4. Does anyone have an idea?

I'm trying to experiment with extremely low bitrates and would like to set my frame size to 1000 ms or higher, even if that sounds crazy to you.

Compiling opus for the armv7 architecture for Android outputs

[armeabi-v7a] Compile arm    : opus <= opus_multistream.c
In file included from ./libopus/celt/kiss_fft.h:100:0,
                 from ./libopus/celt/mdct.h:46,
                 from ./libopus/celt/modes.h:36,
                 from ./libopus/src/opus_decoder.c:44:
./libopus/celt/arm/fft_arm.h:37:20: fatal error: config.h: No such file or directory
 #include "config.h"
                    ^
compilation terminated.

There is no config.h in the opus sources, except one in the win32 directory which is not applicable for the current build. The offending line is this

#include "config.h"

(https://github.com/xiph/opus/blob/master/celt/arm/fft_arm.h#L36-L37)

Both fft_arm.h and mdct_arm.h have the same config block, and subsequently the same error.

Should we be checking HAVE_CONFIG_H before including the config.h, similar to the check in other files?

I'm using recent clone of git repository (HEAD of master branch at commit 99aaff5), and I'm noticing some spurious behavior with versions and tags. When I go through typical autoconf procedure (ie, running ./autogen.sh to create configure), I note that configure.ac calls the update_version script. Looking at that script, I see the following lines:

# We run `git status` before describe here to ensure that we don't get a false
# -dirty from files that have been touched but are not actually altered in the
# working dir.
GIT_VERSION=$(cd "$SRCDIR" && git status > /dev/null 2>&1 \
                           && git describe --tags --match 'v*' --dirty 2> /dev/null)
GIT_VERSION=${GIT_VERSION#v}

On my system (Debian Jessie [amd64], with git version 2.1.4), the output of this git call is:

v1.1.1-rc-91-g99aaff59

But that seems a bit ridiculous, as the output of git tag | tail -1 is:

v1.1.2

I suspect there's some issue with the tagging of v1.1.2, also recognizable in that the v1.1.2 tag does NOT show up if I execute git log --decorate=full, but does show up if I execute git log --decorate=full --tags. The v1.1.1-rc tag shows up in both cases. I've read about some weird corner cases with tagging on StackOverflow, maybe this is related.

Regardless, it results in the wrong version information being embedded in the autoconf configured output, which I don't think is a good thing.

I actually discovered this while hunting for another, related bug in versioning, but I'll report that separately.

src/opus_demo.c:875:49: runtime error: division by zero
#0 0x42a451 in main /home/user/code/opus/src/opus_demo.c:875:49
#1 0x7ffbb460d82f in __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
#2 0x402de8 in _start (/home/user/code/opus/opus_demo+0x402de8)

I'm using Manjaro Linux (Arch Linux). After following all the steps the compilation completes successfully but on checking in Terminal opus reports previous version (1.2.1) which is present in repository.

The update_version script is inexplicably missing from the downloadable tarball (or zip-file) of the last released version (v1.1.2), even when it is present in the repository --- I'm confused / surprised that this is happening, but find it easily reproducible. Per my other recent issue report (#12), I'm running Debian Jessie (amd64) with git version 2.1.4. I download the gzip'd tarball from GitHub as follows:

wget https://github.com/xiph/opus/archive/v1.1.2.tar.gz
tar xzvf v1.1.2.tar.gz

I clone the repo at the same tag as follows:

git clone http://github.com/xiph/opus.git
git checkout tags/v1.1.2

I then compare the list of files between the two (via successive find -type f | sort -k9), and find that v1.1.2 from the tarball is missing update_version (as well as the .git directory, which is obviously to be expected), even though it is present in v1.1.2 tag via git-clone... Weird (at least to me). Please see the output from diff FileList.FromTarBall FileList.FromGitClone:

120a121,144
> ./.gitattributes
> ./.git/config
> ./.git/description
> ./.git/HEAD
> ./.git/hooks/applypatch-msg.sample
> ./.git/hooks/commit-msg.sample
> ./.git/hooks/post-update.sample
> ./.git/hooks/pre-applypatch.sample
> ./.git/hooks/pre-commit.sample
> ./.git/hooks/prepare-commit-msg.sample
> ./.git/hooks/pre-push.sample
> ./.git/hooks/pre-rebase.sample
> ./.git/hooks/update.sample
> ./.gitignore
> ./.git/index
> ./.git/info/exclude
> ./.git/logs/HEAD
> ./.git/logs/refs/heads/master
> ./.git/logs/refs/remotes/origin/HEAD
> ./.git/objects/pack/pack-80603375c3f957ac617456b999e2240d6ff6d204.idx
> ./.git/objects/pack/pack-80603375c3f957ac617456b999e2240d6ff6d204.pack
> ./.git/packed-refs
> ./.git/refs/heads/master
> ./.git/refs/remotes/origin/HEAD
344a369
> ./update_version

I'm sure you can imagine that there are all kinds of follow-on effects of this missing update_version script. The configure.ac script ends up selecting unknown for the version information, which then gets embedded in the pkg-config files, and (at least via my method of configuring opus-tools via PKG_CONFIG_PATH environmental variables), causing the opus-tools configure script to fail (as libopus no longer passes the version check, even though it definitely is the most recent version).

Thoughts on how to correct this, please? I'd presume it's either an issue with the v1.1.2 tag (perhaps related to issue #12 I just submitted), or maybe there's some script that makes the tarballs that is not properly including this update_version file (though I grep'd throughout the source-tree and couldn't find anything obvious).

Thanks for all your help, as well as a great bunch of libraries (in opus/ogg)!

Hello,

It would be extremely helpful if the project could be built via CMake. As it is the project can be built under Cygwin or MSYS2, but these environments are not always available. The VS2015 project is thoughtful but MSVC produced libraries sometimes do not work with other compilers (mainly MinGW[-w64]).

I understand this may be some work.

Cheers,
R0b0t1

I noticed that when building the 64 bit versions that casts from int32 to 64 bit generates a warning.

Same is true for 32 bit builds saying cast from int64 to int warning. Might need to review the code or suppress the warnings (they can be annoying.)

Trying to compile on Mac after updating to latest version I get this error:

silk/x86/x86_silk_map.c:63:3: Excess elements in array initializer

opus_int (*const SILK_VAD_GETSA_Q8_IMPL[ OPUS_ARCHMASK + 1 ] )(
    silk_encoder_state *psEncC,
    const opus_int16   pIn[]
) = {
  silk_VAD_GetSA_Q8_c,                  /* non-sse */
  silk_VAD_GetSA_Q8_c,
  silk_VAD_GetSA_Q8_c,
  MAY_HAVE_SSE4_1( silk_VAD_GetSA_Q8 ), /* sse4.1 */
  MAY_HAVE_SSE4_1( silk_VAD_GetSA_Q8 )  /* avx */
};

Because OPUS_ARCHMASK appears to be 0.
I took a look at cpu_support.h and indeed it's possible it's set to 0.

So it looks like your initializer list is unsafe, because it ignores checks for OPUS_ARCHMASK

Minor nit.

In the documentation of the ec_dec_uint function, there is a note that the param "must be at least one, and no more than 2**32-1", so >= 1. In the implementation of the function we have the following:

opus_uint32 ec_dec_uint(ec_dec *_this,opus_uint32 _ft){
  /* [...] */
  /*In order to optimize EC_ILOG(), it is undefined for the value 0.*/
  celt_assert(_ft>1);

... so requiring >1 for the param.

Regarding that post here:

https://www.reddit.com/r/audiophile/comments/40g900/flac_vs_lossy_compression_opusaacmp3_etc/

Is said that Opus 512 takes more underlying song elements away as compared to lower bitrates.

This link leads here - where a comparison was done about the elements which Opus and other audio codecs remove (Listen to the 256 and 512 Opus samples)

https://soundcloud.com/kingo64-1/sets/lossy-audio-compression-comparisons

So, is it normal that 512 strips away more minor parts than 256?

https://stackoverflow.com/questions/47555361/are-there-tools-to-repair-opus-file-stream

Summary: there seem to be no [official and supported] way to repair otherwise salvageable opus streams. opusdec seems to be rather anal about the proper format and will not let it repaired. There should be either a switch to allow lax parsing in opusdec or a separate tool which is able to actually pick all the frames from a possibly semi-broken bitmess. Real-life users would really appreciate that.

(Sidenote: xiph webpage and xiph wiki isn't quite consistent where we're suposed to report bugs. I've been sent to trac, or here, or to the mailing list.)

opus-1.2.1

# rpm -qa | grep gcc
libgcc-4.8.5-11.el7.centos.aarch64
gcc-c++-4.8.5-11.el7.centos.aarch64
gcc-gfortran-4.8.5-11.el7.centos.aarch64
gcc-4.8.5-11.el7.centos.aarch64

libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I./include -I./celt -I./silk -I./silk/float -I./silk/fixed -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -fvisibility=hidden -W -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes -c silk/CNG.c  -fPIC -DPIC -o silk/.libs/CNG.o
In file included from celt/arm/celt_neon_intr.c:37:0:
celt/arm/celt_neon_intr.c: In function 'xcorr_kernel_neon_float':
celt/arm/celt_neon_intr.c:137:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
       SUMM = vmlaq_lane_f32(SUMM, YY[0], vget_low_f32(XX[0]), 0);
              ^
celt/arm/celt_neon_intr.c:139:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
       SUMM = vmlaq_lane_f32(SUMM, YEXT[0], vget_low_f32(XX[0]), 1);
              ^
celt/arm/celt_neon_intr.c:141:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
       SUMM = vmlaq_lane_f32(SUMM, YEXT[1], vget_high_f32(XX[0]), 0);
              ^
celt/arm/celt_neon_intr.c:143:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
       SUMM = vmlaq_lane_f32(SUMM, YEXT[2], vget_high_f32(XX[0]), 1);
              ^
celt/arm/celt_neon_intr.c:145:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
       SUMM = vmlaq_lane_f32(SUMM, YY[1], vget_low_f32(XX[1]), 0);
              ^
celt/arm/celt_neon_intr.c:147:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
       SUMM = vmlaq_lane_f32(SUMM, YEXT[0], vget_low_f32(XX[1]), 1);
              ^
celt/arm/celt_neon_intr.c:149:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
       SUMM = vmlaq_lane_f32(SUMM, YEXT[1], vget_high_f32(XX[1]), 0);
              ^
celt/arm/celt_neon_intr.c:151:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
       SUMM = vmlaq_lane_f32(SUMM, YEXT[2], vget_high_f32(XX[1]), 1);
              ^
celt/arm/celt_neon_intr.c:170:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
       SUMM = vmlaq_lane_f32(SUMM, YY[0], vget_low_f32(XX[0]), 0);
              ^
celt/arm/celt_neon_intr.c:172:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
       SUMM = vmlaq_lane_f32(SUMM, YEXT[0], vget_low_f32(XX[0]), 1);
              ^
celt/arm/celt_neon_intr.c:174:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
       SUMM = vmlaq_lane_f32(SUMM, YEXT[1], vget_high_f32(XX[0]), 0);
              ^
celt/arm/celt_neon_intr.c:176:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
       SUMM = vmlaq_lane_f32(SUMM, YEXT[2], vget_high_f32(XX[0]), 1);
              ^
celt/arm/celt_neon_intr.c:184:14: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
       SUMM = vmlaq_lane_f32(SUMM, YY[0], XX_2, 0);
              ^
celt/arm/celt_neon_intr.c:189:11: error: incompatible types when initializing type 'float32x4_t' using type 'float32x2_t'
    SUMM = vmlaq_lane_f32(SUMM, YY[0], XX_2, 0);

It seems like that there is no defination of float32x4_t in the current gcc.

Hello.

I battle with op_callback_open() to use it with Pascal to access url-steaming.

OK, I can use it, assigning a named pipe as "source" and a pre-filled buffer as "initial data".

The callback-set used is op_callbacks:

op_test_callbacks(InPipe, op_callbacks, BufferURL[0], PipeBufferSize, err);

But using in a loop op_read_float, it read to the end of song only if "initial data" was filled completely.
Huh.., this is not streaming, it is downloading then playing...

Is it possible to use a PipeBufferSize < than the whole song (like for web-radio) ?

Thanks.

PS: Of course c code is welcome.

Fre;D

hello, boys. We have decide to use opus in our product. but the size of lib complied to more than 200KB is also too larger to use. is that any options to cut off the size? we only need speech , music is not necessary, can these part be cut?

NDK compile,opusfile 0.9 opus 1.2.1. android 7.1.1 test.
My own music is converted to opus, always play after 1 second stop.(use opusenc)
use offical website sample But everything is OK!
https://people.xiph.org/~giles/2012/opus/ehren-paper_lights-96.opus

I debug found op_pcm_total func in opusfile.c always return 47880 / 48000 = 0.98sec
Who can tell me if this is a bug?

I've tried various parameters for opusenc and various music. So it shouldn't be a format problem.
By the way, everything is ok at windows

Is there a pre analysed R-value for OPUS codec in Full band 48kHZ? I'm trying to calculate MOS and R-factor but I can't seem to get it. There is one calculation shown for G711

hi,

i always see a

Inline Assembly Optimizations: . No inline ASM for your platform, please send patches

am i doing something wrong, is there something missing in my building environment?

i'm compiling using msys2, no errors, but no optimization.
at the end it also tells me again:

you appear to be compiling without optimization, if so opus will be very slow

Hi,

I discovered Opus has a PLC mechanism and wanted to use it.

I tried opus_demo in version 1.2.1 and it doesn't really seem to work.

Here is what I do: opus_demo audio 48000 2 70600 -loss 1 input.wav out.wav
Using "voip" instead of "audio" doesn't help.
In any case, I can clearly hear the missing audio (and see silence using audacity).

I tried to debug the demo application and I can clearly see it is passing a NULL pointer but a size > 0 (around opus_demo.c:778), which is what you need to do, according to the documentation.
And that afterwards some processing is taking place which seems related to PLC (e.g. in celt_decode_lost) but I'm not sure what it is actually doing.

Does someone know more about how PLC is working in Opus?
I spend some time looking around but couldn't find useful resources about this.
I suspect it might work or not depending on the audio input, how repetitive it is etc. but would be curious to know the limitations it might have.

In advance, thanks a lot!

Arnaud

In the file silk/MacroCount.h line 694, shouldn't the return type of the silk_LIMIT_32 function be "opus_int32" instead of "opus_int"? All parameters and the variable used to compute the return value are declared as "opus_int32". Moreover, in the case of other functions from the same file, there is a consistency between these types and the return type of the corresponding functions. I detected this automatically using a CodeSonar plugin.

The static function celt_fir5 is used only once, at line 214 inside the pitch_downsample function. There are some minor issues that could warrant a cleanup:

• mem is sort of superflous. It is created on the stack of pitch_downsample and initialized with 0, and passed to celt_fir5 but there only the 0 values are read from mem, and while there is writing to mem afterwards, pitch_downsample never reads that. One could just simply initialize mem0-mem4 with 0 and drop the mem variable entirely, no?
• There is this weird aliasing happening between the x and y pointers; why not just simply have one pointer?

I might be missing something and this is all done to nudge the compiler to vectorize which it otherwise wouldn't do, but IMO if that's the case then it would be nice to have a comment in the code.

I am getting errors in windows build "expression must have a constant value" on ALLOC macro. How to fix that?

I am building Opus 1.2.1