Closed naglis closed 3 months ago
Thanks for the super detailed report!
Your fix works nicely. While testing this, I found out that files without VBR headers have durations that are slightly off as well. I'll look into that tomorrow and get this fixed in 0.20.1.
Reproducer
To reproduce, I am using a file filled with 10 minutes (600s) silence generated by
ffmpeg
using this command (the file is also attached):ffprobe
on the generated file says the duration is600.137143
seconds:However, running lofty's
tag_reader
example from dde24d5b6d5b040abcd8a7be30e6aa580bda4e00 prints:which is off by 3 seconds.
After digging in the code I believe it is because here we lose the fractional part from
frame_time
, since it is computed separately as an integer before multiplying by the number of frames.If I change the
length
computation to multiply by the number of frames before dividing by sample rate:I get the correct duration:
Summary
First of all, I'd like to thank you for this library. I really appreciate all the work that you put into it.
I am using it in context of audiobooks where single-file audiobooks can be quite long, and have noticed that the duration of MP3 files returned by lofty was incorrect (when comparing to the duration returned by other tools, like ffmpeg). This led to some weird results when the audiobook playback position was seemingly greater than the length of the audiobook and where a chapter was supposed to start after the audiobook had already ended. FWIW, from my limited testing with MP4/FLAC/OPUS/OGG, all those file formats returned the correct duration.
E.g. for an MP3 file of 14.5 hours, the duration returned by lofty would be ~4 minutes shorter.
Expected behavior
The duration of MP3 files of known duration returned by lofty should be correct and match the duration returned by other libraries/tools.
Assets
silence.zip