FFmpeg concat introduces gaps, even encoding to wav; does not occur with mpg123.

[Karen Róbertsdóttir]

mpg123 -w out_mpg123.wav 160k_75_80_15-8_v5_B/00015[5678]*

vs.

echo -n > list.txt; for i in 160k_75_80_15-8_v5_B/00015[5678]*.mp3; do echo "file '$i'" >> list.txt; done; ffmpeg -y -f concat -safe 0 -i list.txt -c copy out_ffmpeg.wav

See the attached waveform to see the gap, and the source files to recreate. My suspicion is that ffmpeg concat is not respecting the stated file length, and is instead just writing out whole blocks even if the block extends out beyond the end of the file.

[Karen Róbertsdóttir]

Waveform comparing the mpg123 (no added gap) .wav file with the ffmpeg (added gap) .wav file.

[Karen Róbertsdóttir]

First sound sample

[Karen Róbertsdóttir]

Second sound sample

[Karen Róbertsdóttir]

Third sound sample

[Karen Róbertsdóttir]

Fourth sound sample

[Michael Niedermayer]

the "blocking" field should not be filled with random text

[Karen Róbertsdóttir]

That's not "random text", that's describing the work that the bug blocks and whether or not there's a workaround that lets the project continue (TL/DR, there is, but it requires 3rd party software). And seriously, your important takeaway from the bug report was... what information was put in what fields in the submission form?

[Gyan]

The primary consumers of bug reports are FFmpeg developers. All these metadata fields are meant to be in relation to the FFmpeg project, not the bug reporter.