Opened 14 months ago
Last modified 14 months ago
#11524 new defect
g726(le) produces clicks in encoded audio
| Reported by: | Lastique | Owned by: | |
|---|---|---|---|
| Priority: | normal | Component: | avcodec |
| Version: | 7.1 | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Reproduced by developer: | no | |
| Analyzed by developer: | no |
Description
Summary of the bug:
The G726 and G726LE codecs sometimes produce audible clicks in encoded audio. I have observed this when the encoder is configured to 16, 24 or 48 kbit/s bitrate, but the clicks appear at different places and it is possible that all bit rates are affected.
How to reproduce:
% ffmpeg -i input.wav -acodec g726 -b:a 16000 g726-16-output.wav % ffmpeg -i input.wav -acodec g726 -b:a 24000 g726-24-output.wav
I have attached the problematic input.wav, where there are no audible clicks across the entire clip. I have also attached g726-16-output.wav, produced with the above command line, where you can hear an audible click on the 11th second of the clip. I have also attached g726-24-output.wav, where the click can be heard on the 2nd second of the clip. Note that both times the same input file was used.
Attachments (4)
Change History (14)
by , 14 months ago
comment:1 by , 14 months ago
I analyzed samples in Audacity, and it looks like an int16 overflow happens somewhere, which turns some lowest value samples (i.e. close to -32768) into the highest ones (i.e. close to 32767), which sounds like a click.
comment:2 by , 14 months ago
Can you attach a g726 wav file that has no artefacts? Using master code maybe from
https://www.freecalypso.org/hg/gsm-codec-lib/rev/0ee1a66c1846?revcount=14
comment:3 by , 14 months ago
I've attached a G726 32 kbit/s encoded clip that has no artefacts in it. The file was produced with this command line:
$ ffmpeg -i input.wav -acodec g726 -b:a 32000 g726-32-output.wav
comment:4 by , 14 months ago
Obviously it needs to be some g726-24-output.wav file that has no artefacts encoded without ffmpeg...
comment:5 by , 14 months ago
I don't know any other G726 encoder software. In the project you linked, I do not see one either, at least not from the cursory look (it looks like a collection of GSM codecs that reference G726 spec but not an implementation of G726 itself). If I missed it, please let me know how to encode G726 audio with it.
comment:6 by , 14 months ago
There is probably no bug in our encoder, only in decoder, duplicate #5482
That is why it would be nice to verify where the bug is.
I will check with sox whether is the bug.
comment:7 by , 14 months ago
Found an imlementation for G722. Will compare it to ffmpeg:
used in a binary here https://github.com/shanepowell/G722Converter/blob/master/G722Converter/G722Converter.csproj
comment:8 by , 14 months ago
Okay, about G.722. (64000 bitrate.) There is a bug in our encoder. If you want correct file you have to manually convert to 16000 Hz beforehand or it will just produce file where audio is speed up or slowed down. So instead of ffmpeg -i input.wav FileName.g722
you have to use ffmpeg -i input.wav -filter:a aresample=resampler=soxr:precision=33:osf=s16:osr=16k FileNamecorrect.g722
Obvious from the almost x2 size difference. Also G722Converter.exe is decoding g722 as 8000 Hz which is wrong, LMAO. So useless, our ffmpeg decoder on the other hand is not removing a gap in the start of the g722 file and our ffmpeg encoder appears to insert too big of a gap at the start... LOL. So ideally you would encode using G722Converter.exe, but decode using ffmpeg. Also when I use G722Converter.exe with bitrate at 48000 or 56000 it produces incorrect file that ffmpeg fails to decode and G722Converter.exe decodes only a second of.
Found here https://www.reddit.com/r/ffmpeg/comments/11q53cb/how_to_convert_audio_from_wav_to_g722/
comment:9 by , 14 months ago
I'm not sure why you're testing G.722. From what I can see, this is an entirely different codec than G.726.
comment:10 by , 14 months ago
I'm not sure why you're testing G.722
Because there are no artefacts in it. And yet it is not sample accurate, which would complicate debugging... Because it does not allow direct comparison.
"After painstakingly comparing the C implementation of G.726 in the ITU-T G.191
STL against the language of G.726 spec itself and convincing myself that they
really do match"
https://www.freecalypso.org/hg/gsm-codec-lib/rev/0ee1a66c1846?revcount=14



Input audio clip