Last 4 seconds of track skipped when using ffmpeg filter loudnorm
boblund opened this issue · 5 comments
Owntone: 28.9, output to ALSA HIFIBerry DAC+ Pro.
Platform: Raspberry Pi 3b+, Bookworm lite
Playback with ffmpeg loudnorm filter enabled decode_audio_filters = { 'loudnorm=I=-16:TP=-1.5:LRA=11' }
skips the last 4 seconds of tracks. This has been observed with .m4a (aac and alac codecs) and mp3 files.
The following messages were seen in owntone.log
when the last 4 seconds are skipped:
[2024-07-23 13:39:52] [ WARN] ffmpeg: Could not update timestamps for discarded samples.
[2024-07-23 13:39:52] [ WARN] xcode: Could not read frame: End of file
[2024-07-23 13:39:52] [ WARN] ffmpeg: stream 0, timescale not set
To determine if this was an issue with ffmpeg, I applied ffmpeg loudnorm to an m4a (alac) file, i.e.
ffmpeg -i file.m4a file.flac
ffmpeg -i file.flac -af loudnorm=I=-16:TP=-1.5:LRA=11 file-loudnorm.flac
ffmpeg -i file.m4a -i file.flac -map_metadata 0 -map 1 -acodec alac file-loudnorm.m4a
Audacity showed the increased loudness in file-loudnorm.m4a
compared to file.m4a
.
Without the loudnorm filter file-loudnorm.m4a
was louder than file.m4a
and the last 4 seconds were not
skipped. Enabling the owntone loudnorm filter and playing the same file resulted in skipping the last 4 seconds.
I think I found the issue here and also a fix. It's in the master branch now. If you are able to test and verify from there it would be great.
Here's a deb for RPi Bookworm with the fix. You don't need to remove anything, just install with dpkg -i
. It will be replaced automatically by apt once I make a new release to the RPi repo.
looks like it's for pi4? Isn't the pi3b+ amhf?
Yes you are right, I didn't notice you would need armhf. Let me see if I can produce a deb for that.
Once I install it will I get some sort of notification when it's replaced with your new release?
Yes and no, apt upgrade
will tell you there is a newer version and install it if you accept (like any other package update)
I built and installed master (28.9.131) on a rpi3b+ and tested it with m4a (alac, aac) and mp3 files. They all played to the end so indeed the problem looks fixed. Thanks.