Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duration seems to be reported too long #502

Open
bpeperkamp opened this issue Jan 20, 2025 · 2 comments
Open

Duration seems to be reported too long #502

bpeperkamp opened this issue Jan 20, 2025 · 2 comments
Labels
bug Something isn't working

Comments

@bpeperkamp
Copy link

Reproducer

Thanks for creating Lofty!

I do have a question though. It seems that the duration from properties is off, or i am doing something wrong. It happens with all file types. An example (also happens with other formats):

let mut file_content = File::open(entry.path())?;
let wav_file = WavFile::read_from(&mut file_content, ParseOptions::new())?;
println!("WAV: {}", wav_file.properties().duration().as_secs());

In all found files the duration is reported longer than it actually is. An example file will report 208 secs (3:48 mins). While sox/vlc/ffmpeg will report it as: 3:28 mins. The amount of samples is 9211020 and the sample rate is 44100 Hz.

9211020/44100 = 208.866666667 (which explains the duration)

Am i missing something here?

Summary

The file duration seems to report higher values

Expected behavior

It should report the duration correctly

Assets

No response

@bpeperkamp bpeperkamp added the bug Something isn't working label Jan 20, 2025
@bpeperkamp
Copy link
Author

I'll try to figure it out, will make a pull request/comment if i do :)

@Serial-ATA
Copy link
Owner

Am i missing something here?

Nope! Lofty tries not to read too much into the actual audio data, only what's absolutely needed (which can sometimes be wrong). Some difference from FFmpeg is acceptable, for example see the AAC properties test:

duration: Duration::from_millis(1474), /* TODO: This is ~100ms greater than FFmpeg's report, can we do better? */
overall_bitrate: 117, // 9 less than FFmpeg reports
audio_bitrate: 117, // 9 less than FFmpeg reports

But a 20sec difference is pretty bad.

Feel free to email a file to serial AT [domain on my profile], I can look into it when I have time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants