Bug#797965: bs1770gain somehow "destroys" gapless playback on (at least) lame encoded MP3s
Control: -1 reopen
Hey Andreas.
I'm afraid I have to reopen this.
Today I made a fresh set of extensive checks for gapless playback in
mpv (from Debian sid with the ffmpeg from sid) and also upstream git
master HEAD ffmpeg alone.
The details results can be found here:
https://trac.ffmpeg.org/ticket/7828#comment:2
https://github.com/mpv-player/mpv/issues/2284#issuecomment-479667296
Long story short:
In mpv MP3/Opus play gapless quite fine.
In ffmpeg, it works at least with the version from git (but not with
the one in Debian); reasons seems to be an issue in the ffmpeg(1)
program itself which was recently fixed... while mpv used the libs
already correctly.
>From that I'd have expected that bs1770gain also works now and files
that have been processed by it still play back gaplessly, however it
does not.
1) First pair of test files
>From the test-files from the two bug reports above I used:
02.split-track01.mp3
02.split-track02.mp3
and
03.split-track01.opus
03.split-track02.opus
each of them in a directory, which I then processed (each dir) with:
bs1770gain dir -t -o outdir
Playing these with:
mpv 02.split-track01.mp3 02.split-track02.mp3
respectively
mpv 03.split-track01.opus 03.split-track02.opus
works without any gap/distortion.
Fine so far, but now...
2) Second pair of test files
I do have another pair of sample file from an audio CD.
Encoded them exactly as described in the ffmpeg/mpv tickets with lame
respectively opusenc.
Processed them as above with bs1770gain (the Debian version from sid,
with the ffmpeg version from sid).
With the (bs1770gain processed) MP3 files, there is a
distortion/corruption at the the intersection, which I can clearly
hear.
However... the (bs1770gain processed) Opus files are fine!!! (wtf?)
It can also be seen in the waveform (see attached images):
For that I decoded the files with lame --decode respectively opusdec
(not with ffmpeg this time), joined each pair together with sox and
displayed them in sonic-visualizer with:
top:
the sox concatenation of the original two WAV sample files
middle:
the joined WAVs decoded from the MP3 respectively Opus
bottom:
just the WAV of first track from MP3 respectively Opus, serving just as
reference as to where the intersection is
Any idea why the MP3 is still mangled up? It apparently seems to depend
on the input file... so maybe it's just luck, that the Opus worked
here.
Thanks,
Chris.
btw: As for the sample files, I wouldn't want to upload them publicly
since these are from some copyrighted Audio CD,... but I can make them
privately available to some developers if this is desired.
Reply to: