[FFmpeg-devel] [PATCH 0/5] Fix mp3 gapless support (second try)

[wm4]

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
timestamp 0.)

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.)