fluidsynth command fills up file system when playing blinding_lights.mid

[bclark288]

FluidSynth version

Execute fluidsynth --version and provide the output.
FluidSynth runtime version 2.3.2
Copyright (C) 2000-2023 Peter Hanappe and others.
Distributed under the LGPL license.
SoundFont(R) is a registered trademark of Creative Technology Ltd.

FluidSynth executable version 2.3.2
Sample type=double

Describe the bug

Provide a clear and concise description of the current situation, e.g. how the bug manifests.
When I run the command
/opt/homebrew/bin/fluidsynth -F ./blinding_lights.wav -T wav /usr/local/share/sft/FluidR3_GM_GS.sf2 ~/Downloads/blinding_lights.mid
the command writes data to the file blinding_lights.wav until the file system fills up.

Expected behavior

Provide a clear and concise description of what you expected to happen.
the command should only write 35 seconds of a wav file.

Steps to reproduce

Please explain the steps required to duplicate the issue, esp. if you are able to provide a sample application. E.g. how to start fluidsynth, what shell commands to enter, what midi events to send, etc.
Run the specified command with the attached (zipped) midi file.

Additional context

If you are able to illustrate the bug with an example, please provide simple
source code below or as attached file. List any other information that is relevant to your issue, e.g. stack traces, related issues, build logs, suggestions on how to fix, links to related discussions at fluid-dev, etc.

insert code snippets, soundfonts or anything relevant here, or attach it as extra file(s) if it's too much

blinding_lights.mid.zip

[derselbst]

the command should only write 35 seconds of a wav file.

Well, it's not that simple.

Fluidsynth's MIDI player will stop once all End-of-MIDI-track (EOT) events have been processed. The provided MIDI file specifies the EOT event of the first MIDI Track with a delta-time of 134,050,688 ticks - this is what the byte sequence 0xBF 0xF5 0xE7 0x00 in the file at offset 0xED says.

Therefore, rendering should terminate gracefully after about 26,6 hours provided my calculations are correct. Unfortunately, this doesn't happen. Instead, I can observe player->cur_ticks to go up to somewhere 121,873,438 ticks and then drops back to zero again, leading to the endless rendering that you are complaining about.

I'll see what can be done to yield the 26 hours behavior requested by your MIDI file.

In any case: Your MIDI file is broken. Admittedly, it's pretty hard to spot that as none of the MIDI editors I've checked seem to honor the EOT event.

[derselbst]

Ok, it's quite simple: fluid_synth_get_ticks() is the timing source for the player. Once it went up to 2^32 it'll overflow and therefore the player->cur_tick starts from zero again. I'll try to detect this in the player and stop rendering immediately with an error message.

[bclark288]

Hi Tom, Thanks for the prompt reply and the explanation. I think we can probably develop a workaround to prevent fluidsynth from trying to play the entire 26.6 hours as indicated by the delta time of 134,050,688 ticks. What's interesting to me is that when I play the file in Garage Band or Ableton, they stop playing after 35 seconds (which would be the ideal behavior). I also noticed what appeared to be several non-standard meta events in the file. Do you know what kind of application might have produced the file in the first place? Is it possible that the meta events are clues as to what the application might be? Best, Beach Clark

…

On Fri, Apr 14, 2023 at 2:06 PM Tom M. ***@***.***> wrote: Ok, it's quite simple: fluid_synth_get_ticks() is the timing source for the player. Once it went up to 2^32 it'll overflow and therefore the player->cur_tick starts from zero again. I'll try to detect this in the player and stop rendering immediately with an error message. — Reply to this email directly, view it on GitHub <#1233 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2KJIZ4CRGSZBFG7DUHOFDXBGG2TANCNFSM6AAAAAAW45TD5A> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[derselbst]

Those meta events seem to be standard copyright, marker and lyrics events. Unfortunately, there seems to be no hint which application has created this file.

[bclark288]

Hi Tom,
I noticed that the track that contained the delta time of 134,050,688 ticks has nothing but meta messages and therefore nothing that fluidsynth would need to render. Do you think it's possible to check for that condition (i.e. nothing to render on a track?) when rendering?

[derselbst]

The MIDI player does not ignore those events. On the contrary, it passes all meta events to a potentially user-provided callback function, allowing users to display lyrics or otherwise process these. It could be that more events (even audible ones) are to follow after such a long wait time, we cannot just cut it off, sry.

I've opened a PR that makes the player terminate when the internal ticks overflow, see above.

I'd advise you to fix the MIDI by editing the file. Either in a HEX editor or by importing the MIDI in some MIDI app and exporting it again.