[FFmpeg-user] ffprobe audio duration mismatch
ffmpeg-user-email at m.allo.ws
Wed Mar 21 04:05:11 EET 2018
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
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.
More information about the ffmpeg-user