[FFmpeg-devel] [PATCH 0/5] Fix mp3 gapless support (second try)
nfxjfg at googlemail.com
Wed Apr 15 13:16:45 CEST 2015
On Wed, 15 Apr 2015 12:42:04 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:
> On Wed, Apr 15, 2015 at 11:08:02AM +0200, wm4 wrote:
> > On Tue, 14 Apr 2015 22:44:22 +0200
> > Michael Niedermayer <michaelni at gmx.at> wrote:
> > > On Tue, Apr 14, 2015 at 09:24:32PM +0200, wm4 wrote:
> > > > Seeking was slightly broken. The 4th patch seems to fix this (everything
> > > > else is noise).
> > > >
> > >
> > > > Note that ffmpeg can't correctly implement mp3 gapless audio if seeking
> > > > is used. The xing toc is not precise enough. The only way to fix it is
> > > > to do a full scan on the mp3 to index each frame (which in turn is not
> > > > possible with the public API, because byte seeking is not supported and
> > > > the parser would interfere anyway). But in this case, it even broke when
> > > > seeking to the beginning. I'm still not sure if this patch is correct.
> > >
> > > do you have a file/sample/testcase for patch 4 ?
> > https://0x0.st/AG.mp3
> > I'm assuming mpg123 is getting it right. One test case is seeking to
> > the start of the file. (Seeking to anywhere else likely won't work,
> > because libavformat tries to use the imperfect xing toc, instead of
> > scanning the frames.)
> how can this be tested ?
> ./ffmpeg -ss 0 -i AG.mp3 -flags +bitexact new.wav
> ./ffmpeg-ref -ss 0 -i AG.mp3 -flags +bitexact old.wav
> 52298dcb38185e665b1b6d184884dd3e new.wav
> 52298dcb38185e665b1b6d184884dd3e old.wav
> ./ffmpeg -ss 5 -i AG.mp3 -flags +bitexact new.wav
> ./ffmpeg-ref -ss 5 -i AG.mp3 -flags +bitexact old.wav
> b4b8f2a83924b48f3d25baa6b9b4f4a8 new.wav
> b4b8f2a83924b48f3d25baa6b9b4f4a8 old.wav
The result is the same because in both cases the CBR seeking path is
used, which didn't change. You need to apply patch 5/5. I don't have a
good "real" VBR sample at hand for testing, unfortunately.
With all patches applied, the output with "-ss 0" should be the same as
without. (Make sure that ffmpeg.c doesn't drop or add audio samples due
to the seek, because it could cause subtitle depending how seeking
works - for one, skip_samples causes the decoder to change the audio
timestamps for whatever reason, so the output doesn't actually start at
As a "reliable" reference for testing I would use mpg123. But it
doesn't have a bitexact mode (and even if it did, it'd probably not
match ffmpeg's), so testing isn't that easy.
(Also I'm not sure myself if I made some mistake, so it'd be nice if
you could confirm this.)
More information about the ffmpeg-devel