[FFmpeg-user] FFmpeg accuracy issues.

[Michael Bradshaw]

On Thu, Aug 16, 2012 at 10:30 AM, Michael Bradshaw
<mbradshaw at sorensonmedia.com> wrote:
> I'll go ahead and open a trac ticket regarding the missing ~277
> samples. The increasing length though... I think that's just due to
> the inevitable delay accumulating, and I don't know if it can be
> reliably skipped (I'm not sure how LAME does it though, so maybe it
> can?).

Wow, I am just all sorts of wrong today. Looks like I was using an
older version of FFmpeg (thought it was git head, turns out it's a few
months old), and it indeed had a buggy mp3 decoder but it's been fixed
in current git head.

I've looked at it more: The lame technical faq explains: "LAME embeds
the amount of padding in the ancillary data of the first frame of the
MP3 file. (LAME INFO tag). The LAME decoder will use this information
to remove the leading padding of an MP3 file." It's really out of date
(12 years old), because it also says "Modifications to the decoder so
that it will also remove the trailing padding have not yet been made"
which, I've found, is wrong, because since then those modifications
have been made and it now skips this trailing padding.

FFmpeg parses this lame tag now and skips the leading padding, but it
does not skip the trailing padding (I don't know how it would...),
which is why using ffmpeg accumulates length and lame does not when
re-encoding the file.

That was fun :)

--Michael