libgme/game-music-emu

libgme change altered VLC playback behavior to restart repeatedly instead of looping infinitely

Opened this issue · 6 comments

Digging through my email for libgme-related mail, I saw that the VLC devs reached out to point me to a bug on their bug tracker.

VLC includes support for libgme. It seems in earlier versions it would loop forever on SPC files. With VLC 3.0.18 and later, it no longer does so, instead completing playback and then starting over from the beginning (or switching to the next track if a playlist is in use).

I vaguely remember there were changes a few years ago that may have affected the behavior of libgme for SPC tracks that can otherwise loop forever. If this is the case then what the VLC devs would need is a description of how to achieve infinite playback on their end with current libgme, or a reversion on our end.

I can probably figure that out (I added 'play forever' to the sample player because I like the feature) but I don't want the only mention to be in my email and I can't comment on the VLC bug until my account is created over there, so noting it here.

Ah, yes, that's my ticket :)

OK @jbkempf, so I think the issue is related to fadeout support. libgme can (and will) play a file forever as long as it doesn't result in a sustained period of silence (and even this can be allowed).

Aside from silence detection, the other way for a track to end is to reach a configurable fadeout timer. See gme_set_fade decl. With a valid fadeout time set, libgme will fadeout playback and then gme_track_ended will return true for that track.

Normally fadeout is set to begin at a very large value. While VLC seems to call into libgme to determine how long a track is (which for these files is usually just a decision by whoever dumped the SPC since the song could play forever), it doesn't seem to set a desired playback length.

However back in 2019 I had added a way in commit 3f1e9bd for libgme to automatically read track length metadata for a track and use it as the fadeout time, gme_set_autoload_playback_limit. The SPC emulator will respect this flag and set a fadeout timer if this behavior is not disabled (and this behavior is the default).

To restore the old behavior it should be enough to call gme_set_autoload_playback_limit with autoloading set to false on the Music_Emu object returned by gme_new_emu.

However this will also mean other SPC music will not ever skip to the next track unless silence is detected or the user manually advances to the next track. I can see both sides of that dilemma (which is why it was made an option) but it may be too fine a detail to add a U/I for it. Perhaps it would be appropriate to autoload track length if playing within a playlist containing multiple tracks but not otherwise?

I'll see if I can build VLC again locally to test this out myself tomorrow.

I'll see if I can build VLC again locally to test this out myself tomorrow.

Something like that:
https://code.videolan.org/videolan/vlc/-/merge_requests/4512 ?

That should work, yes. And making resetting it after each track instead of when the emulator is created ensures any change to the config option is applied each time a new track starts playback.

@jbkempf ok I've tested it here. It's close, but the call to disable autoloading of track limits needs to come right after gme_new_emu, and before gme_start_track.

With that change made, VLC will play the track forever if you tell it to in my local testing.

@jbkempf ok I've tested it here. It's close, but the call to disable autoloading of track limits needs to come right after gme_new_emu, and before gme_start_track.

Done and updated the MR :)