Closed canchanchara closed 2 years ago
Hm. Just to make sure I didn't just break this. Could you please check if the previous release produces the same problem?
If yes, does it only apply to all files or just this one?
The old release has the same problem. I know this problem at the moment only at this file.
In that case it might again be an issue with the original filter, which I cannot do much about. I know it has its quirks and should be improved (unfortunately it has not been maintained much recently).
I will check it out tomorrow!
Thank you. I do batch processing. So if you can fix it, it would be perfect. If you can not fix this problem, it would be great if the programm can send an error. This would help for batch processing, to identify a problem.
Something is wrong with the entire conversion. Look at the original:
vs the output:
Essentially, the original you had was mixed very loud to begin with. The resulting file is missing a large chunk of the audio contents.
I think you should file a bug report on https://trac.ffmpeg.org/ for this particular sample.
Unforatunately, there is not much I can do about it!
Is it possible to "validate" the output mp3? Sth. like: if ( x% of the output mp3 is quiet) -> throw an error
This would be possible with the silencedetect filter of ffmpeg and parsing the output in the shell, but really, it's obviously just a bug that needs to be fixed. I don't see that it's worth implementing such a check in this tool.
If you are looking for a script that implements "how many percent of a clip are silent?", and you have something started already, superuser.com may be a good resource for help.
This is more input mp3 problem, somehow there is very huge amplitude spike 84.9dBFS right at start of audio. Can be inspected with astats or ebur128 filter. loudnorm gets somehow entirely confused about this and thus dynamics processing/scanning is giving wrong results to compensate for such huge spike. Can be fixed by using some kind of limiter just as first step in processing chain.
@richardpl Thanks for your input! Is this just this MP3 or have you seen it with others?
I seen it first time with this mp3, but can be reproduced with any file that can store >+/-1.0 values in samples. Just need high enough single sample spike.
I guess I will close this as a one-off bug then, nothing that can be done from ffmpeg-normalize.
:warning: Please read this carefully and edit the example responses! If you do not fill out this information, your bug report may be closed without comment.
Checklist (please tick all boxes)
ffmpeg-normalize
(runpip3 install --upgrade ffmpeg-normalize
)ffmpeg
or a recent build from Git masterExpected behavior I'm normalizing a mp3 with -t -14 and -lrt 11.
Actual behavior The converted mp3 is quiet.
File to reproduce: https://return0.de/interview.mp3
Command The exact command you were trying to run:
Any output you get when running the command with the
--debug
flag:Environment (please complete the following information):
python3 --version
orpython --version
): 3.10.6ffmpeg -version
): N-108116-g50a4dff69f-20220913