I'm encoding 32-bit floating point Wave (.wav) files to Opus using the command line encoder, opusenc 1.4.
None of the Wave files have clipping (= contain audio samples outside the -1.0 .. +1.0 range), yet:
if I open the
.opusfile produced by the command line encoder in Audacity, there are a handful instances of individual audio samples going under -1.0 or over +1.0.If I instead decode the
.opusfile via opusdec 1.4 or read it vialibopusfilein C++, there is no clipping present in the audio data.
I've compared my code to Audacity's (https://github.com/audacity/audacity/blob/5b9d78bc9ecda8dcb84669541c268cce90b06848/modules/mod-opus/ImportOpus.cpp#L193), both use ::op_read_float().
What is Audacity doing differently? How can the .opus file, opened via drag and drop onto the Audacity window, contain a handful of clipping samples, yet, opusdec and my own code can't replicate the same clipping samples?
I discovered that if I use my system-provided
libopus/libopusfile, the clipping issues do occur even outside Audacity.So there appears to be a small difference in decoding between the official
opusdecexecutable, my debug build oflibopus/libopusfileand the riced build of said libraries on my system (compilation flags include-march=native -Ofast -pipe -fomit-frame-pointer -g0 -fgraphite-identity -fno-common -flto=13 -fmerge-all-constants -falign-functions=32 -fno-stack-protector -floop-strip-mine -floop-block -ftree-vectorize -floop-interchange -floop-nest-optimize -floop-parallelize-all -fstack-check=no -fno-stack-check -fno-stack-clash-protection).The following C++ snippet, when linked with my system's
libopus, does reproduce the clipping I see in Audacity: