[FFmpeg-user] FFmpeg accuracy issues.

[Michael Bradshaw]

On Thu, Aug 16, 2012 at 9:27 AM, Michael Bradshaw
<mbradshaw at sorensonmedia.com> wrote:
> On Thu, Aug 16, 2012 at 8:42 AM, Roger Pack <rogerdpack2 at gmail.com> wrote:
>>> Actually, wait a bit on that. MP3s suffer from added encoder/decoder
>>> delays. LAME FAQ talks about it here:
>>> http://lame.sourceforge.net/tech-FAQ.txt
>>>
>>> So re-encoding an MP3 just keeps accumulating delays, so it's slowly
>>> getting longer. But three seconds (the first transcode) is a very
>>> large jump... the other ones are more consistent with LAME's delays.
>>
>> Oops the 3 seconds one was a typo :)
>>
>> Ok with .wav it seems to keep consistent timings.
>>
>> However, using lame "straight" (lame.exe) results in the following timings:
>>
>> lame1:  00:00:53.28
>> lame2:  00:00:53.28
>> lame3:  00:00:53.28
>>
>> (and the files stay the same size, so maybe lame has fixed their
>> problem since then?)
>
> No, it's still an issue in LAME.
>
>> This is using the same version of lame that ffmpeg is compiled with.
>> Any feedback?
>
> LAME is kinda special. I just did some tests (and I plan on contacting
> the LAME list about this), but here's what I've found: LAME adds the
> delay, just like all MP3 encoders do. BUT, it also has the special
> ability to skip this delay when it reads an MP3 file (or at least it
> skips the delay it added; dunno if it works with MP3s encoded with
> another encoder). So if you do lame in.wav out.mp3 and open it with
> Audacity or something, you'll see the delay at the start (there's also
> about ~277 samples missing at the end... I'm trying to get feedback on
> this from the LAME devs). However, if you then do lame --decode
> out.mp3 out.wav and open out.wav in Audacity, the added delay to the
> beginning is gone and the missing ~277 samples are back at the end
> again.
>
> So it looks like LAME is the only tool that properly reads LAME
> output. I suspect that if you select the libmp3lame codec for the
> decoder (and don't use FFmpeg's MP3 decoder) it'll go away.

Lies. Sorry, I was wrong :)

I think FFmpeg's MP3 decoder is to blame for the missing ~277 samples.
I've just checked things, and FFmpeg's decoder is missing the last
little bit of the audio. However, when I used libmad or MainConcept's
decoders, they decoded the full song.

Also, there's no libmp3lame decoder :)

But I still stick with what I said about LAME auto-skipping the delay
when it decodes an MP3.

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

--Michael