[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[fluid-dev] Inaccurate MIDI file timings when using fluidsynth command l

From: Curtis \"Fjord\" Hawthorne
Subject: [fluid-dev] Inaccurate MIDI file timings when using fluidsynth command line
Date: Sat, 18 Mar 2017 00:48:33 +0000

Hi fluidsynth devs,

I've noticed a problem when using the fluidsynth command line to render MIDI files. For some files, the time of note events seems to get less accurate the farther along in the file the event occurs.

To make the problem easy to diagnose, I took a midi file and added a note at the end that should occur at exactly 95 seconds. The file is available here: https://drive.google.com/file/d/0BwEv9tXUD_necUZDTmJMVE9KRzQ/view?usp=sharing

If I render the file with wildmidi, the final note is at 95 seconds as expected. I'm also able to render the file correctly by loading it into pretty_midi (https://github.com/craffel/pretty-midi) and having it render the file using the fluidsynth library.

However, if I use the fluidsynth command line, trying to replicate the settings that pretty_midi uses, the final note occurs about 230ms too late. Here's the command:

fluidsynth  -F test_fluidsynth_95s_note.wav -r 16000 -K 256 -L 1 -g .2 -v ~/pretty-midi/pretty_midi/TimGM6mb.sf2 test_with_95s_note.mid

I also tried rendering at 44.1khz, since that seems to be the sample rate the logging expects: https://sourceforge.net/p/fluidsynth/code-git/ci/master/tree/fluidsynth/src/synth/fluid_synth.c#l941

fluidsynth  -F test_fluidsynth_95s_note.wav -r 44100 -K 256 -L 1 -g .2 -v ~/m/pretty-midi/pretty_midi/TimGM6mb.sf2 test_with_95s_note.mid 

And here are the final lines of output:
fluidsynth: noteon      2       64      100     00523   95.163  0.741   0.000  0
fluidsynth: noteoff     2       64      0       00523   0.747   1

From that output, it looks like fluidsynth has misinterpreted the start time of the final note as 95.163 seconds, and if I open the resulting wav file in Audacity, the final note does come 163ms too late.

It's particularly odd that the magnitude of the timing error seems dependent on the output sample rate (163ms for 44.1khz, 230ms for 16khz).

Is this a known issue? Do you have any tips for a workaround?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]