Skip to main content


Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: OpusEnc is bugged? (Read 2621 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

OpusEnc is bugged?

I've run these two commands for a 16 bit, stereo, 44.1 kHz flac file:
Code: [Select]
opusenc --bitrate 200 source.flac opus.opus
ffmpeg -i source.flac -c:a libopus -b:a 200k opus.ogg

They must produce exactly the same or very similar output, right? Not at all.

opus.ogg - 33,868,022 bytes
opus.opus - 33,904,598 bytes

Never mind a tiny difference in the file sizes. Check the resulting spectrograms.

Can anyone tell what's going on? Why is opusenc so bad? I'm using libopus-1.3.1 and ffmpeg-5.1.2 built with exact same opus library.

I can share the FLAC file with you privately. It's copyrighted.

Re: OpusEnc is bugged?

Reply #1
One of them was decoded with repalygain/opusgain applied, and they have different volume?

Re: OpusEnc is bugged?

Reply #3
Probably opusenc calculates opusgain value during encoding (and writes it to the output file) while ffmpeg doesn't do it.

Then spek uses libopus to decode these files, and libopus reads and applies this gain. And as I said earlier, different volume -> different spectrograms.

Re: OpusEnc is bugged?

Reply #4
Why is opusenc so bad?

Using spectrograms to show that two encodes are different is fine, but right here you cross the TOS 8 line. Opusenc isn't a picture encoder. If it "looks" worse to you, it's your fault for looking and is entirely irrelevant, because you can't judge opusenc's quality as an audio encoder by looking at the spectrogram.

That being said, the spectrogram seems to indicate just a difference in overall volume.

Re: OpusEnc is bugged?

Reply #5
It's a problem I've encountered often in the past, today it seems to me that everyone follows the EBU R128. In any case, TOS 8 cannot be of any help to someone who does not hear a difference of 5 dB nor when one uses the spectrogram because the hearing has already noticed large differences.

Rather, we need to learn to respect the opinion of those who notice the differences and to know how to hold back from defining the ideas of raising criticism as shit. Before TOS 8 there should be the rules of civilization and the awareness that one's hearing, like that of others, is anything but linear or stable over time. Man is not a comparator, he undergoes too many external influences that too many ignore.

What operating system do you use? For example Gstreamer had this problem, but it's fixed.

The software does not improve thanks to the push of those who have found peace of mind, it is thanks to those who show its limits that progress begins, even if they use the spectrogram to highlight differences that they cannot describe in their own words. In my opinion it’s better than nothing, it's called the experimental scientific method and we have to thank Galileo Galilei for having left it to us.

The terms of service are the choices of those who manage the forum, time will prove right to those who do not believe that they can remain unchanged forever and that day you will hear from those who wanted them that only stupid people never change their minds. Until then I will be the stupid one along with those who believe other tools can be tolerated.

We could try to reproduce ReplayGain conditions on public domain files, for now it's the only way to avoid the spectrogram.

Re: OpusEnc is bugged?

Reply #6
Probably opusenc calculates opusgain value during encoding (and writes it to the output file) while ffmpeg doesn't do it.
If the flac has REPLAYGAIN_ALBUM_GAIN tag then this is used as opusgain (with some modifications), see flac.c:135.

Re: OpusEnc is bugged?

Reply #7
Yes, opusenc uses the replaingain value from a flac file to encode, thus spectrograms are different.

Sorry for the noise, case solved.