strawberry
strawberry copied to clipboard
strawberrymusicplayer
split second of OGG Vorbis File gets skipped nearing the end due to buffer
- [x] I have checked the FAQ for answers.
- [x] I have checked the Changelog that the issue is not already fixed.
- [x] I believe this issue is a bug, and not a general technical issue, question or feature requests that can be discussed on the forum.
Describe the bug When the last few seconds play of a song I converted into OGG Vorbis using VLC and song transitions are disabled or not triggered, it will skip a beat/split second or two. This does not happen within VLC or mpv.
to be even more specific, here in bullet list form:
- song plays last 4-5 seconds
- song was converted into OGG Vorbis using VLC (128kb/s, 48 kHz, 2 Channels)
- song transitions within Strawberry Music Player are not triggered
- song will at exactly 4 seconds before end skip a beat or a split second
- the buffer time/duration selected in the backend is the exact amount of time before the song ends where it will skip a beat or two. as the default is 4000ms aka. 4s, this is when the issue will always occur (in my case). (see further below for workarounds)
To Reproduce
- grab any audio file which plays sound until the very end (minimum: 3 seconds before the end)
- open vlc and convert the file.
- File > Convert/Save
- Add Files to the selection (Drag n Drop or manually)
- Click "Convert/Save"
- Select the Audio Profile "Aduio - Vorbis (OGG)" or create your own.
- Make sure the following settings:
- Ogg/Ogm
- No Video
- Audio: Vorbis, 128kB/s, 2 Channels, 48000 Hz, No Filters
- No Subtitles
- Save the profile
- select an output file
- convert
- grap the converted file and put it into strawberry music player
- make sure song transitions are disabled (NOT set to 0ms) in the Settings > Backend
- enjoy the music
- get absolutely triggered when at exactly 4 seconds before the end it decides to just skip a beat for some reason NOTE: This issue occurs for most files on my end, however some are not affected for some reason. just use a different one if this issue didn't happen the first time. I can also provide a file myself if you still have trouble.
Workarounds set "Minimum Value" (or whatever it is in english) to 0. 0.01 already makes the issue occur. "Maximum Value" doesn't change anything. OR set buffer duration to 100ms to fix, as 1 or 0ms absolutely do not help at all, try for yourselves. depending on the length of the buffer duration it also changes when song transitions are triggered. this will post-pone the lag enough for nobody to notice, however it also post-pones the music transition.
Expected behavior the audio plays without skipping parts of it AT ALL
Screenshots: no.
System Information:
- Operating system: Windows 10 64x
- Strawberry Version: 1.0.20
Additional context Backend Engine is GStreamer. I wanted to use VLC to see if it fixes the issue but I'm too dumb to figure it out how to get it working in Windows without compiling it myself.
This is the most oddly specific issue I've ever encountered with any software.
I can't reproduce this with ogg vorbis files, but I didn't test with any encoded with VLC at the same bitrate, do you know if it's specific to that?
I can't reproduce this with ogg vorbis files, but I didn't test with any encoded with VLC at the same bitrate, do you know if it's specific to that?
nope I haven't, I'll try it now, gimme a second
I can't reproduce this with ogg vorbis files, but I didn't test with any encoded with VLC at the same bitrate, do you know if it's specific to that?
@jonaski So after rewriting this answer 3 times because I always figured out something new, here's what I found.
- This issue is (to my surprise) very consistent
- shuffle makes the issue occur randomly :D (before I though it was always random)
- I tried using a different Sample Rate and different Bitrate, but nothing changed.
About the files I experimented with...
- All my OGGs are "broken".
- All my MP3s are not "broken".
- PS: the source file I converted it from (an opus file) is broken as well.
- PPS: converting the OGG to MP3 and then back to OGG does not fix it
- PPPS: the not broken MP3s are converted from the broken opus file
What causes the problem & how to actually trigger it
I think the problem is still the buffer, or whatever pre-loads the next song, because If the next song to play is an OGG File, it causes this issue to occur.
Here's an example: You have 3 songs in a playlist. The first is your typical not-broken MP3 file, the second one as well, the third is our broken OGG. Playing the first song no problems happen, when you play the second one however it occurs. It will not happen with the OGG, as after that the playlist ends (or if you repeat it, it goes to our not broken MP3). If you now have "repeat playlist" enabled and the only song in your playlist is that troublesome OGG, it repeats to itself, making this issue occur every single time. If your entire playlist is now filled with such files, it will always happen.
Other less relevant info
If you change the order while playing a song, you need to "re-load" (double click) the song when its position changes, else it won't update to it's current broken-ness.
As I had repeat and shuffle on the entire time I though the issue occured randomly, and after restarting the app everything was different again... due to shuffle mode. I'm sorry for wasting both our time due to this oversight on my end.
Considering all of this we might just give up (as you're the only maintainer and probably have other things to worry about) and set the puffer's minimum value to 0 as it fixes it permanently, until you change it to anything other than 0.
A RECORDING according to the example I've given
I hope you can hear it... YouTube Link, at 0:13 and 0:38 the issue occurs If the example was too quiet, I can redo it with a phonk song, my entire playlist just consists of them.
Are you using the MSVC or MinGW version? What output is set in the backend settings? Auto, DirectSound or WASAPI? Are any of the audio normalization, fading or bs2b features enabled?
Are you using the MSVC or MinGW version? What output is set in the backend settings? Auto, DirectSound or WASAPI? Are any of the audio normalization, fading or bs2b features enabled?
MinGW, I'll try MSVC now. Auto, but happens on all three, even after restarting the app. Default output device. Normilazition and Fading are disabled, bs2b wasn't. Disabling bs2b didn't do anything. Enabling fading fixes the issue, but none of the others (Note: a fade must be triggered. If fading is when manual, but you don't manually trigger it, the issue will happen).
tried MSVC, same issue, same setup.
...tho my manual primary color "orange" in the fusion style is actually used across the entire app and not only for a few things... but that's a different problem that might be unfixable as it might be a problem with MinGW itself...
Can you try one of the installers listed on https://github.com/strawberrymusicplayer/strawberry/actions/runs/6880692159 under artifacts and see if it resolves it.
@jonaski used msvc x64, issue still occurs. I'll try x86 next, then the MinGW variants
Ok, no need to try all of them, it should have worked with the msvc x64 one.
Can you try the latest from https://builds.strawberrymusicplayer.org/windows/ and check if the issue is fixed.
@jonaski Problem does not occur anymore on that build, no work-around needed. I guess we can close this now