Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_midi (foobar2000 v2.0) (Read 83753 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: foo_midi (foobar2000 v2.0)

Reply #250 –
Quote from: Brazil2 on
How are you installing foo_midi ? Because bassopus.dll is installed by default. Do you install the plugin from the preferences ?
Usually, I install foobar2000 and any plugin manually, keeping control of what is happening, except when needing to run the installer, like for a first install or a redo of required registry entries (associations, context-menu entries). However, I also have custom-built registry-key backups for these purposes.

Before manually installing a new plugin or a plugin update, I make a backup copy of foobar's user settings folder foobar2000-v2, so I can revert to a good state in case of an issue. And I keep bass.dll + bassmidi.dll for foo_midi up-to-date, too.

EDIT:
It's also strongly recommended to have at least backups of the user settings, stored in the foobar2000-v2 main folder and its subfolder configuration.

Re: foo_midi (foobar2000 v2.0)

Reply #251 –
Quote from: pqyt on
Except: it's an invalid MIDI file. It has only 1 track but the track has no End of Track marker hence the Insufficient Data error message.
I see. So I guess the old versions of foo_midi by Kode54 and XMP-MIDI have a more relaxed validity check. Thanks for checking. 🙂

Re: foo_midi (foobar2000 v2.0)

Reply #252 –
Quote from: deus-ex on
Quote from: pqyt on
Except: it's an invalid MIDI file. It has only 1 track but the track has no End of Track marker hence the Insufficient Data error message.
I see. So I guess the old versions of foo_midi by Kode54 and XMP-MIDI have a more relaxed validity check. Thanks for checking. 🙂
The library still supports malformed MIDI files but I enabled strict parsing because I wanted to detect bad files in my collection.

In the mean time I've added parser options to the library so I'll add a 'relaxed' parsing mode in the next version of foo_midi.

I knew where this sub-thread was going from the start ;-)

Re: foo_midi (foobar2000 v2.0)

Reply #253 –
Quote from: deus-ex on
Usually, I install foobar2000 and any plugin manually, keeping control of what is happening
Then I suggest you to backup your whole profile folder with versions of the plugins that still work, then install latest foo_midi plugin from the preferences and check if you still have the issue.  ;)

Re: foo_midi (foobar2000 v2.0)

Reply #254 –
Quote from: Brazil2 on
Then I suggest you to backup your whole profile folder with versions of the plugins that still work
I just explained in detail that this is exactly what I do when trying out a new/updated plugin.

Quote from: Brazil2 on
... then install latest foo_midi plugin from the preferences and check if you still have the issue.  ;)
And what difference would that make? An install routine extracting the plugin distribution content to my foobar2000 settings folder is no different than extracting to the same destination by hand.

Also, you probably missed this bit: https://hydrogenaud.io/index.php/topic,123301.msg1049298.html#msg1049298

Re: foo_midi (foobar2000 v2.0)

Reply #255 –
Quote from: deus-ex on
And what difference would that make? An install routine extracting the plugin distribution content to my foobar2000 settings folder is no different than extracting to the same destination by hand.
With computers don't believe in anything, just try things. ;)
That will only take you few minutes.

Re: foo_midi (foobar2000 v2.0)

Reply #256 –
Quote from: pqyt on
In the mean time I've added parser options to the library so I'll add a 'relaxed' parsing mode in the next version of foo_midi.
I didn't ask for this because I guessed you would have good reasons for making the parser more strict, and now you kindly confirm. I was about to take a search on the net for a non-malformed version of that MIDI file. Providing us with an option to control the parsing level is a great, welcomed solution.

Re: foo_midi (foobar2000 v2.0)

Reply #257 –
Quote from: Brazil2 on
That will only take you few minutes.
To satisfy your curiosity, and to honor your positive attitude (which is a good thing, keep that 🙂) I ran the plugin installer and made another test run. It took me about five tunes to have the same reported issue kicking in, e.g. the waveform isn't drawn for a tune.

As a reminder, like I stated earlier, something gets written to the wavecache.db for the tune(s) with the missing waveform representation, because the waveform never gets drawn until I request the waveform signature for that specific tune(s) to be removed from the wavecache.db, resulting in a reparse and finally proving waveform signatures.

Reverting to v2.12 and earlier, none of such issues for me. 🤔(hmm...)

Re: foo_midi (foobar2000 v2.0)

Reply #258 –
Quote from: pqyt on
v2.14.0.0, 2024-08-17

* New: Support for embedded artwork (IPIC) and encoding (IENC) chunks in RMI files.
Download from GitHub or the foobar2000 Components repository.
Automatic update from within foobar2000 does not work.
Bug:
As of this update, album shows up as <PRODUCT>.

According to the spec, IPRD is the album chunk and it shows up as <PRODUCT> even though it's the album.
WAV files with the IPRD chunk are correctly read as album in foobar, but not RMIDI files.

Also creation date is shown in <CREATION_DATE> instead of the "Date" field. Why?

Other than that, great work!

PS: foo_midi uses fluidsynth, right? Fluidsynth has a DLS support. So maybe you can add support for DLS rmidis?
The spec does describe their behavior too:
https://github.com/spessasus/sf2-rmidi-specification#handling-differences
It should be easy, only check for `dls ` instead of `sfbk` and assume bank offset of 0 and it (hopefully) should work.

Currently, the only player I know that reads DLS RMIDIs is Winamp (and only after adding a specific configuration), which is a pain to get working in wine, unlike foobar, so I'll appreciate adding it!

I've attached a DLS RMI file for testing. I hope this helps!

Re: foo_midi (foobar2000 v2.0)

Reply #259 –
Quote from: spessasus on
Bug:
As of this update, album shows up as <PRODUCT>.

According to the spec, IPRD is the album chunk and it shows up as <PRODUCT> even though it's the album.
WAV files with the IPRD chunk are correctly read as album in foobar, but not RMIDI files.

Also creation date is shown in <CREATION_DATE> instead of the "Date" field. Why?
I'm afraid your spec is wrong.

There is an IALB chunk for the album title. IPRD is for the product that created the file: see https://exiftool.org/TagNames/RIFF.html#Info and https://www.mediamonkey.com/sw/webhelp/frame/index.html?abouttrackproperties.htm

foo_midi followed the latter standard from before I took custody. The same goes for the ICRD chunk.

Bonus: Here's the spec from which RIFF was derived: https://www.martinreddy.net/gfx/2d/IFF.txt

That's what I love about standards... there are so many of them  ::)

Edit: there is BTW already an official spec: https://www.loc.gov/preservation/digital/formats/fdd/fdd000120.shtml It would make sense your spec aligns with that reference.

Re: foo_midi (foobar2000 v2.0)

Reply #261 –
Quote from: spessasus on
PS: foo_midi uses fluidsynth, right? Fluidsynth has a DLS support. So maybe you can add support for DLS rmidis?
The spec does describe their behavior too:
https://github.com/spessasus/sf2-rmidi-specification#handling-differences
It should be easy, only check for `dls ` instead of `sfbk` and assume bank offset of 0 and it (hopefully) should work.

Currently, the only player I know that reads DLS RMIDIs is Winamp (and only after adding a specific configuration), which is a pain to get working in wine, unlike foobar, so I'll appreciate adding it!

I've attached a DLS RMI file for testing. I hope this helps!
I got it working with FluidSynth AND fixed a very old bug in the MIDI parsing code with Pitch Bend control change messages: it's been a good night ;-)

Re: foo_midi (foobar2000 v2.0)

Reply #262 –
Quote from: pqyt on
Quote from: spessasus on
Bug:
As of this update, album shows up as <PRODUCT>.

According to the spec, IPRD is the album chunk and it shows up as <PRODUCT> even though it's the album.
WAV files with the IPRD chunk are correctly read as album in foobar, but not RMIDI files.

Also creation date is shown in <CREATION_DATE> instead of the "Date" field. Why?
I'm afraid your spec is wrong.

There is an IALB chunk for the album title. IPRD is for the product that created the file: see https://exiftool.org/TagNames/RIFF.html#Info and https://www.mediamonkey.com/sw/webhelp/frame/index.html?abouttrackproperties.htm

foo_midi followed the latter standard from before I took custody. The same goes for the ICRD chunk.

Bonus: Here's the spec from which RIFF was derived: https://www.martinreddy.net/gfx/2d/IFF.txt

That's what I love about standards... there are so many of them  ::)

Edit: there is BTW already an official spec: https://www.loc.gov/preservation/digital/formats/fdd/fdd000120.shtml It would make sense your spec aligns with that reference.
Hi,
Exiftool Link doesn't mention IALB (or at least I couldn't find it)
The second link you've provided (mediamonkey) also states that IPRD is correct. So why not both then? If foobar sees IALB, uses that. If it sees IPRD but not IALB, use that instead. I've based my assumptions on the fact that windows itself (in the properties) and KDE (also in properties) and Winamp recognize IPRD as album.
But if you don't want to change it, that's fine.

Another thing is that this new spec aims to be a new format rather than the DLS RMIDI format as it allows more metadata (like DBNK and IPIC) than the original format could while being backwards compatible with it.

Re: foo_midi (foobar2000 v2.0)

Reply #263 –
Quote from: spessasus on
Quote from: pqyt on
Quote from: spessasus on
Bug:
As of this update, album shows up as <PRODUCT>.

According to the spec, IPRD is the album chunk and it shows up as <PRODUCT> even though it's the album.
WAV files with the IPRD chunk are correctly read as album in foobar, but not RMIDI files.

Also creation date is shown in <CREATION_DATE> instead of the "Date" field. Why?
I'm afraid your spec is wrong.

There is an IALB chunk for the album title. IPRD is for the product that created the file: see https://exiftool.org/TagNames/RIFF.html#Info and https://www.mediamonkey.com/sw/webhelp/frame/index.html?abouttrackproperties.htm

foo_midi followed the latter standard from before I took custody. The same goes for the ICRD chunk.

Bonus: Here's the spec from which RIFF was derived: https://www.martinreddy.net/gfx/2d/IFF.txt

That's what I love about standards... there are so many of them  ::)

Edit: there is BTW already an official spec: https://www.loc.gov/preservation/digital/formats/fdd/fdd000120.shtml It would make sense your spec aligns with that reference.
But if you don't want to change it, that's fine.
It's not a matter of 'wanting'.

1) there's prior art. I don't know where Kode54 found the information to map the chunks to tags or if he was making it up as he was writing the code.
2) The purpose of a chunk should be clear from it's identifier. IPRD meaning 'Album Title' is not as clear as IALB. ICRD for the creation date leaves room for when you want to introduce a composition date or arrangement date later f.e.

Re: foo_midi (foobar2000 v2.0)

Reply #264 –
Quote from: pqyt on
Quote from: spessasus on
PS: foo_midi uses fluidsynth, right? Fluidsynth has a DLS support. So maybe you can add support for DLS rmidis?
The spec does describe their behavior too:
https://github.com/spessasus/sf2-rmidi-specification#handling-differences
It should be easy, only check for `dls ` instead of `sfbk` and assume bank offset of 0 and it (hopefully) should work.

Currently, the only player I know that reads DLS RMIDIs is Winamp (and only after adding a specific configuration), which is a pain to get working in wine, unlike foobar, so I'll appreciate adding it!

I've attached a DLS RMI file for testing. I hope this helps!
I got it working with FluidSynth AND fixed a very old bug in the MIDI parsing code with Pitch Bend control change messages: it's been a good night ;-)

Hi again,
I wanted to let you know that I've discovered that AWEBLOWN is an External RMIDI file (you can read about it in the spec).
This means that it expects a full GM bank loaded as 0 and it uses this + its own DLS presets.
Also it expects bank offset of 1 for some reason (and all other RMIDIS in the archive do as well, so I've updated the spec to say that it should assume bank offset of 1 too.)
Since Foo_midi comes with a gm bank by default, can it use it in fluidsynth and stack another one on top of it?

I've converted blown to the new SF2 RMIDI format with DBNK 1 and sure enough, it sounds much better with a full GM bank in spessa. Play it there and hear how cool it sounds with all the new instruments!

Re: foo_midi (foobar2000 v2.0)

Reply #265 –
Quote from: spessasus on
Quote from: pqyt on
Quote from: spessasus on
PS: foo_midi uses fluidsynth, right? Fluidsynth has a DLS support. So maybe you can add support for DLS rmidis?
The spec does describe their behavior too:
https://github.com/spessasus/sf2-rmidi-specification#handling-differences
It should be easy, only check for `dls ` instead of `sfbk` and assume bank offset of 0 and it (hopefully) should work.

Currently, the only player I know that reads DLS RMIDIs is Winamp (and only after adding a specific configuration), which is a pain to get working in wine, unlike foobar, so I'll appreciate adding it!

I've attached a DLS RMI file for testing. I hope this helps!
I got it working with FluidSynth AND fixed a very old bug in the MIDI parsing code with Pitch Bend control change messages: it's been a good night ;-)

Hi again,
I wanted to let you know that I've discovered that AWEBLOWN is an External RMIDI file (you can read about it in the spec).
This means that it expects a full GM bank loaded as 0 and it uses this + its own DLS presets.
Also it expects bank offset of 1 for some reason (and all other RMIDIS in the archive do as well, so I've updated the spec to say that it should assume bank offset of 1 too.)
Since Foo_midi comes with a gm bank by default, can it use it in fluidsynth and stack another one on top of it?

I've converted blown to the new SF2 RMIDI format with DBNK 1 and sure enough, it sounds much better with a full GM bank in spessa. Play it there and hear how cool it sounds with all the new instruments!
There's an custom .sflist file format that appears to support SoundFont layering but I haven't look at it or needed to change anything to it yet.

Re: foo_midi (foobar2000 v2.0)

Reply #266 –
Hi again,
I've wanted to suggest another feature: Multi-port MIDI files. This allows us to use more than 16 channels.
I know that BASSMIDI supports these, but fluidsynth doesn't (see https://github.com/FluidSynth/fluidsynth/issues/1361).

I've attached an RMIDI with a cover of Africa by Toto, which uses 64 channels total.

Play if through SpessaSynth or Falcosoft MidiPlayer6 to hear how it's supposed to sound like. For example note the snare drum and glockenspiel.

I wrote my own findings about this feature when I implemented it: https://github.com/spessasus/SpessaSynth/wiki/About-Multi-Port

I hope this helps implementing these in foo_midi!

Re: foo_midi (foobar2000 v2.0)

Reply #267 –
Quote from: spessasus on
Hi again,
I've wanted to suggest another feature: Multi-port MIDI files. This allows us to use more than 16 channels.
I know that BASSMIDI supports these, but fluidsynth doesn't (see https://github.com/FluidSynth/fluidsynth/issues/1361).

I've attached an RMIDI with a cover of Africa by Toto, which uses 64 channels total.

Play if through SpessaSynth or Falcosoft MidiPlayer6 to hear how it's supposed to sound like. For example note the snare drum and glockenspiel.

I wrote my own findings about this feature when I implemented it: https://github.com/spessasus/SpessaSynth/wiki/About-Multi-Port

I hope this helps implementing these in foo_midi!
You sure keep me busy... ;-) All the port support is already in there so it's probably a bug.

Re: foo_midi (foobar2000 v2.0)

Reply #268 –
Hi again,
I think I've found a bug with RMIDI Implementation:
I've attached an RMI file without the DBNK chunk, so the offset is 1 (self-contained)
But the strings are missing in foobar, while they work fine in both spessa and FSMP6.

Re: foo_midi (foobar2000 v2.0)

Reply #269 –
Quote from: spessasus on
Hi again,
I think I've found a bug with RMIDI Implementation:
I've attached an RMI file without the DBNK chunk, so the offset is 1 (self-contained)
But the strings are missing in foobar, while they work fine in both spessa and FSMP6.
Offset support is only implemented for FluidSynth/DLS sound fonts. I'm still working on it for BASSMIDI and SF2 sound fonts.

Re: foo_midi (foobar2000 v2.0)

Reply #270 –
Hi pqyt,
I've managed to implement the DLS support and in turn, DLS RMIDI support into spessa (it internally converts it into SF2).
Here's the implementation:
https://github.com/spessasus/SpessaSynth/tree/master/src/spessasynth_lib/soundfont/dls
It allows to produce files like the one I attached (converted from the infamous gm.dls).
It may be helpful to you with converting DLS to SF2 as BASS doesn't support it yet.
Cheers!

Re: foo_midi (foobar2000 v2.0)

Reply #271 –
@spessasus
Which SoundFont is your online player using ?

Re: foo_midi (foobar2000 v2.0)

Reply #272 –
Oh nice, I have been looking for proper DLS specs everywhere for my own personal things.  Nice to see a 16bit sample MSGS too.

Re: foo_midi (foobar2000 v2.0)

Reply #273 –
The current version seems to be ignoring libADLMIDI and libOPNMIDI if a soundfont path is set - regardless of what player I choose the console reports the following:

Code: [Select]
Opening track for playback: "D:\Synth\rips\1991 - Jimmy White's Whirlwind Snooker\01 - Snooker.mid"
foo_midi failed to initialize FluidSynth: Invalid FluidSynth directory: The system cannot find the path specified (0x00000003)
foo_midi uses SoundFont "D:\soundfonts\HiDef.sf2" with bank offset 0.

clearing the soundfont path allows libADLMIDI and libOPNMIDI to operate as normal, it's only when a soundfont path is set that they're getting overridden.
 

Re: foo_midi (foobar2000 v2.0)

Reply #274 –
Quote from: raekuul on
The current version seems to be ignoring libADLMIDI and libOPNMIDI if a soundfont path is set - regardless of what player I choose the console reports the following:

Code: [Select]
Opening track for playback: "D:\Synth\rips\1991 - Jimmy White's Whirlwind Snooker\01 - Snooker.mid"
foo_midi failed to initialize FluidSynth: Invalid FluidSynth directory: The system cannot find the path specified (0x00000003)
foo_midi uses SoundFont "D:\soundfonts\HiDef.sf2" with bank offset 0.

clearing the soundfont path allows libADLMIDI and libOPNMIDI to operate as normal, it's only when a soundfont path is set that they're getting overridden.
Thx. for reporting. The player override logic has been updated to support layered soundfonts but it looks like it's a bit too assertive.