[FFmpeg-user] ffprobe audio duration mismatch

[Zak]

On 3/20/18 9:10 PM, Carl Eugen Hoyos wrote:
> 2018-03-21 1:56 GMT+01:00, Zak <ffmpeg-user-email at m.allo.ws>:
>
>> What you ideally want is a software library that can decode
>> the audio data itself and deduce the duration.
> What's wrong with FFmpeg?
>
> Please do not top-post here, Carl Eugen

Wait, what does "please do not top-post" mean in your opinion? My email 
didn't include a quote at all. This is a bottom-post so I don't think it 
is a top-post. Isn't not quoting at all orthogonal to either top-posting 
or bottom-posting?

I'm not trying to be difficult, I am honestly confused why two people 
have been reprimanded for a reason that I do not understand in this 
thread thus far. Obviously omitting the original message isn't bad, 
because you omitted most of the message I just posted, and I fully 
support that decision. You quoted the part that you replied to.

There is nothing wrong with FFmpeg, but at least for MP3 files, I do not 
know how to easily get it to report the actual number of frames or 
actual duration of the MP3 data stream with all the precision that is 
possible and without relying on the metadata that might be wrong. If I 
do "ffprobe song.mp3", it rounds the duration to 0.01 seconds, it rounds 
the bitrate to 1 kb/s, and it seems to be reporting some information 
from the LAME Info Tag, which could theoretically be wrong (but usually 
it is not, the LAME Info Tag has a CRC checksum and it is rarely touched 
by batch tag editors). For instance, the replaygain data definitely 
comes from the LAME Info Tag.

The original question seemed interested in very high precision. FFmpeg 
doesn't report this information with the most possible precision, and 
that's fine in most contexts, and FFmpeg also doesn't say exactly where 
the information came from, which is also fine. There are software 
libraries that do these things, if you really want them.

Zak