midis with silence after the calculated total time

[kotc]

example file, total time calculated 2:18 and notes finish playing here, yet loop still goes up to around ~4.50 when it ends by itself: http://sourceforge.net/projects/oscp/files/tmp/oscptmp-mozart_-_the_marriage_of_figaro_-_no_20.mid/download

it's not the only file from my collection behaving this way, and files from the same folder (source) can have or have not this bug. i'm checking for WildMidi_GetOutput() to return <0 to detect end of song

[sezero]

On 2/23/15, kotc notifications@github.com wrote:

example file, total time calculated 2:18 and notes finish playing here, yet look still goes up to around ~4.50 when it ends by itself: http://sourceforge.net/projects/oscp/files/tmp/oscptmp-mozart_-_the_marriage_of_figaro_-_no_20.mid/download

This is an interesting one. wildmidi-0.3.8 reports 2.18s for it whereas wildmidi-0.4.0 (master branch) reports 4.48, and timidity (or libtimidity) reports 4.46s, but the song is no more than 2.18s..

[psi29a]

What does fluidsynth say?

[psi29a]

Fluidsynth says:

(venv)bcurtis@Wintermute:~/workspace/terrain$ time fluidsynth -a alsa -m alsa_seq -l -i /usr/share/sounds/sf2/FluidR3_GM.sf2  ~/Downloads/oscptmp-mozart_-_the_marriage_of_figaro_-_no_20.mid 
FluidSynth version 1.1.6
Copyright (C) 2000-2012 Peter Hanappe and others.
Distributed under the LGPL license.
SoundFont(R) is a registered trademark of E-mu Systems, Inc.
fluidsynth: warning: Failed to pin the sample data to RAM; swapping is possible.
fluidsynth: warning: Failed to set thread to high priority
fluidsynth: warning: Failed to set thread to high priority
real    4m48.911s
user    0m26.118s
sys 0m16.526s

[psi29a]

Fluidsynth and WildMIDI (0.4) win.

[sezero]

On 2/23/15, Bret Curtis notifications@github.com wrote:

Fluidsynth and WildMIDI (0.4) win.

so does [lib]timidity in that regard... weird one.

[kotc]

well, i would say that playing 2 minutes of silence isn't exactly a win

[psi29a]

@kotc you're right, it isn't. However the MIDI file is crap.

In 0.4 there will be options to trim silence (before and after), so this might help. Otherwise, we (and timidity and fluidsynth) are doing exactly what the MIDI file is telling us to do.

[kotc]

but i stumble quite often on this particular issue, might be some standard incosistency from the past? trimming silence at the beginning is trivial, the one at the end isn't so, especially when i only call function to generate samples and not scanning tracks by myself, so please add it to lib too as an option

[psi29a]

It trimming before and after is already ready to use in 0.4 branch. I suggest you try it out and let us know. :)

[kotc]

will do, but i'm turned away from current branch because of issue that notes get cut off too fast

[chrisisonwildcode]

Letting you guys know I am still here. My internet (adsl) is down at the moment due to recent weather and line/exchange upgrades. It should be back up by 3rd March according to telco. When it comes back up I'll be publishing the midi type 2 fix in all its glory. Currently using mobile broadband which I need for my studies while ADSL is down.

Thought I dealt with the notes cutting off too soon issue a while ago ...

Also please remember to check latest master before filing bugs. As said by others the "silence at beginning/end" issue has been investigated and there is an option to deal with that within master.

Sent from my iPhone

On 24 Feb 2015, at 5:58 pm, Bret Curtis notifications@github.com wrote:

It trimming before and after is already ready to use in 0.4 branch. I suggest you try it out and let us know. :)

— Reply to this email directly or view it on GitHub.

[kotc]

cool, compiling it now (haven't tried it before because there was no announce about it

[chrisisonwildcode]

Just remember master is still in development, not a release yet, while I iron out bugs and szero swears at my spacing and formatting :)

Sent from my iPhone

On 24 Feb 2015, at 7:31 pm, kotc notifications@github.com wrote:

cool, compiling it now (haven't tried it before because there was no announce about it

— Reply to this email directly or view it on GitHub.

[kotc]

as for spacing and formatting there are tools that do it automatically ;) btw. can you add 'WANT DYNAMIC' option in cmakelists.txt? right now i'm only using static lib and have to hack the file every time i do git pull

[psi29a]

Fork wildmidi, commit, send a pull request... be a contributor! :)

[kotc]

never learned cmake, right now im using all times favourite method of just commenting dynamic parts out ;)

[kotc]

ok, i must say it works (notes aren't cut too fast, end of song doesn't cut sound in the middle and trimming works as expected too). so you can close this issue with a comment 'fixed in currrent git, and probably #116 but i haven't tested it thorougly yet

[sezero]

On 2/24/15, kotc notifications@github.com wrote:

ok, i must say it works (notes aren't cut too fast, end of song doesn't cut sound in the middle [....]

Because 0.4 (master) deliberately adds about 2s of silence at the end... sigh...

[chrisisonwildcode]

Um, I replaced the adding of a fixed amount of silence with a dynamic amount of silence. It was similar to what someone else had done except improved to take into account the stage of release the samples are in.

The only deliberate silence added should be just enough to let sounds release smoothly without cutting them off at the end. This is calculated using envelope release information of samples that would still be in release by the end of the song, and how much time the sample needs to complete their release.

I will double check that I didn't add more than what's needed.

Sent from my iPhone

On 24 Feb 2015, at 8:45 pm, sezero notifications@github.com wrote:

Because 0.4 (master) deliberately adds about 2s of silence at the end... sigh... — Reply to this email directly or view it on GitHub.

[kotc]

why not just check for a chunk of zero bytes when generating sound after setting 'no more notes' flag ?

[chrisisonwildcode]

Because we initially need to know how long to play for (allowing for final decay) so we can tell the players how many samples to expect for timing purposes.

Sent from my iPhone

On 25 Feb 2015, at 6:01 am, kotc notifications@github.com wrote:

why not just checking for chunk of zero bytes when generating sound after setting 'no more notes' flag ?

— Reply to this email directly or view it on GitHub.