owntone/owntone-server

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.