Open JsBergbau opened 9 months ago
Can you add a wav or flac of the first ~10 seconds of a file that clearly shows the problem? That would be a lot simpler than trying to source the originals via iffy sites.
Ok I under fair use policies to debug this, I provide here the wave of the Audio Book "Martin Wehrle - Wenn jeder dich mag, nimmt keiner dich ernst." Please download and write when you have received your sample, then I'll delete here.
I am providing the first 15 seconds of file 080 - Kapitel 80
. This file also has problems with default framesize of 20. Why 15 seconds? Because it takes about 12 seconds until opus has reached its full quality.
Interessting when using bitrate 31 the problem doesn't occur.
it sounds much more brilliant than using 32. With --bitrate 33
it has the same problem as with 32.
Problems are with bitrates of 32, 33, 34, 35, 36 (tested bitrates 16, 31, 37, 38, 39, 40)
080 - Kapitel 80 15s.zip PW: xSObaJfGJmCtHn1
Any progress so far in background?
Any update on this?
Even with --bitrate 31
I encountered the problem at the beginning of the file. At least it is less severe, but still clearly audible.
Can anybody raise the priority of this issue? I consider this as a severe bug.
I use opus a lot for audiobooks storing at 32 kbit/s. At the beginning I used
opusenc --bitrate 32 --framesize 60
to save a few bits extra. Then I've read here https://wiki.xiph.org/Opus_Recommended_Settings#Framesize_Tweaking that using a framesize of 60 has slightly lower quality. With framesize 60 I've encountered the problem quite often. Using default framesize of 32 the problem occured now with 2 files. So it looks like it is some kind of probablity that the problem occurs whereas the probablity rises significant with--framesize 60
When the problem occurs the first few seconds of the audio book file are very damp. Then with 2 to 4 seconds, you can here how the frequency range goes up and the audio sounds brilliant again. Somtimes it also takes only 1 to 2 seconds where you can here the frequencies going continiously up. Very seldom there is also a hard switch where within less then one seconds the full freuquency range is suddenly back (e.g. in
101 - Kapitel 101
). Sometime the audio is clear within the first five seconds of the file, mostly it takes about to second 15 of the file until it is fully brilliant again.Example with Elena Krieger - Die Milchlüge. Die Milch macht's leider doch nicht - 013.mp3 According to audacity frequency is capped to about 7 kHz
A few seconds later, when problem is gone, it looks like this
I've reproduced the problem with the same file with
So the problem seems to be deeply in the library of opusenc. When using either --speech or --music in addition problem doesn't occur. Input is mp3 which is decoded via
lame --decode
. Using ffmpeg for decode ofElena Krieger - Die Milchlüge. Die Milch macht's leider doch nicht - 013.mp3
and then encoded with opus lead to the same problem.Very extreme is the audio book Martin Wehrle - Wenn jeder dich mag, nimmt keiner dich ernst with
opusenc --birate 32 --framesize 60
the problem occurs in almost every fileHere a list of files where it occurs
So in totalit occurs in 88 of 141 files, which is about 2/3.
Using
opusenc --birate 32
it occurs only with 053 - Kapitel 53 080 - Kapitel 80 100 - Kapitel 100 134 - Kapitel 134 (only first second)If it is helpful I can to the same analysis with the audio book of
Elena Krieger - Die Milchlüge
You can get the audio book on variaous sources like myg*lly.com or h*rbch.us
In the attachement you find the SHA256Sums of the files I've tested with. The list above was made with Files of
SHA256SumsMartinFullyTested.txt
With
SHA256SumsMartin2Only4FilesWithDefaultFramesizeTested.txt
I've only tested with opusenc --bitrate 32 the "Kapitel" 53,80,100 and 134 files. Despite a differenct file checksum the same damp audio quality occured.If I can further assist you, just write. SHA256SumsMartinFullyTested.txt SHA256SumsMartin2Only4FilesWithDefaultFramesizeTested.txt