YM2612 samples not plaing and YM2413 not supported.

[system64MC]

Hi, I noticed 2 problems related to Game Music Emu.

The first one is samples not playing when playing some VGMs. I think supporting newer VGM features would solve the problem.
Another issue is YM2413 doesnt seem to be supported, despite being added in VGM 1.10, so some Master System VGMs will not play properly.
Here is a zip with 2 files that trigger the issue. The one named goddes2.vgm is for the YM2612 issue, the other named fantasyzone.vgm is for YM2413.
VGMs.zip

[Wohlstand]

Hello!
Right now VGM nodule supports only YM2612 and SN chips for a while. There are plans after 0.6.4 release to make an attempt to implement the rest of missing chips using the YMFM thing.

[system64MC]

Hello! Right now VGM nodule supports only YM2612 and SN chips for a while. There are plans after 0.6.4 release to make an attempt to implement the rest of missing chips using the YMFM thing.

That would be great! It has so many chips such as OPL3, OPM, OPNA and many more. So maybe libgme would be able to support them.

[vitamin-caig]

And what about ym2413 support in kss? kode54's version supports it, but it's way too outdated for now...

[Wohlstand]

Hello! @kode54's was mostly his personal experiment, and he don't suggest to use it as mainstream, and instead, I polish this mainstream version. For now, it's planned to take the chipset from the "YMFM" library to bring the support for the rest of VGM-supported chips, and this one should be included too.

[vitamin-caig]

Ok, I'll wait till implemented:)

Here the sample file which is played like a silence for now:(
MSX_Fan.zip

Additionally, some fixes for current upstream:

• fixed crashes in GYM playback
• slight optimization

I was going to make PRs to upstream after switching to it, but now have to postpone till FM chips support. So you can take it as is.

PS. I guess, you may get rid of VGM support and cleanup code - there's mainstream libvgm for that:)

[system64MC]

Ok, I'll wait till implemented:)

Here the sample file which is played like a silence for now:( MSX_Fan.zip

Additionally, some fixes for current upstream:

• fixed crashes in GYM playback
• slight optimization

I was going to make PRs to upstream after switching to it, but now have to postpone till FM chips support. So you can take it as is.

PS. I guess, you may get rid of VGM support and cleanup code - there's mainstream libvgm for that:)

Hi, isn't LibVGM licensed under GPL?

[vitamin-caig]

Hi, isn't LibVGM licensed under GPL?

To be honest, I don't known and don't care about that, just using it in opensource project:)

[Wohlstand]

To be honest, I don't known and don't care about that, just using it in opensource project:)

If you use that just for self, then okay. The sense is when you use that to embed into proprietary software used for business: GPL code is forbidden to be included into proprietary projects or with projects that has legally incompatible licenses. You can do that just with yourself, but publishing these projects will be illegal, especially at countries that has strict copyright laws. That means, copyright owner may complain a sue to you and require you to re-license your project into GPL too and open your source that was closed, or just get rid of everything. In Russia (and in China for example), people often spit on copyright and use GPL-licensed code in proprietary projects against common sense, but mostly that is sold to other business or used as part of network services. Software developed for international distribution is usually done with compilance to all licenses and laws.

If you develop some projects and you have license different than GPL, and if you don't want to apply GPL to your project, you should never include GPL (not LGPL) licensed dependencies, otherwise, they work like virus, and your project will be GPL.

[Wohlstand]

PS. I guess, you may get rid of VGM support and cleanup code - there's mainstream libvgm for that:)

Actually, I tried to use libVGM for some of my experiments, and its functionality is not enough for my needs, mainly the ability to dynamically control temp, etc. It was done, but unfortunately, it works wrong, I wanted to fix that, but I became busy on other things, and I forgot about that.

[vitamin-caig]

If you use that just for self, then okay

Yep, that's why I don't care. Your case may differ. So you may ask an author directly https://github.com/ValleyBell/libvgm

its functionality is not enough for my needs, mainly the ability to dynamically control temp, etc

For my case, full support of devices (and good design especially comparing to awful VGMPlay) was the main point - there were way too many complaints about vgm playback via gme.

[Wohlstand]

there were way too many complaints about vgm playback via gme

Just because historically nobody developed it well, and its support was so incomplete here. The libGME has major potential to support it better and wider, just need to take a time and effort. The same case with my libOPNMIDI: since my childhood I wanted to get a full-featured MIDI synthesizer with OPN2 chip after impressing from music in SEGA games and already having experience with OPL3 on my SB16 card. And, I just did libOPNMIDI by myself, after fiveteen years when I just got enough experience of programming.

[vitamin-caig]

And, I just did libOPNMIDI by myself, after fiveteen years when I just got enough experience of programming.

I have to take a look:) I tried to support MIDI playback via mt32emu library about 10 years ago, the main problem was rendering performance on typical android devices.

[Wohlstand]

I have to take a look:) I tried to support MIDI playback via mt32emu library about 10 years ago, the main problem was rendering performance on typical android devices.

I actually have the OPNMIDI-Player-Java crap that works on over-10-years-ago Android devices and plays with a proper performance and have agood quality of sound. You can try it yourself. I support Android 4.1+ on it. It's not a super-convenient player, just as a demo, but works as a simple player that loops a single file and allows to toggle setup on the fly.

[Wohlstand]

Anyway, I guess, I probably already suggested to implement MIDI with libADLMIDI and libOPNMIDI at zxtune at some moment, but nothing happen after that 🤔

[vitamin-caig]

implement MIDI with libADLMIDI and libOPNMIDI at zxtune

That's my job, I guess 🤣

[Wohlstand]

That's my job, I guess 🤣

Then, I will give some tips related to performance at these libraries (Anyway, that should be posted at your repo's issues rathar than here, but as a note to be copied in the future. Also, I lost my Bitbucket account, and glad I quickly resqued everything mine from it to my private self-hosted gitea and GitHub):

• These libraries do support multiple different chip emulators with an ability to switch between them on the fly (the most accurate are Nuked emulators, but they were worst for mobile devices as they consume too much. Nuked OPL3 at least works on weak phone, but battery gets eaten quick. Nuked OPN2 just don't work on phone, it requires even more resources to work. The best chip emulator for phones at libADLMIDI is DosBox, the fastest one, and has average accuracy, somewhere it's inaccurate, but works well. At libOPNMIDI besties are MAME YM2612 and YMFM YM2612 - golden middle, the fastes is GEMS, but has worst accuracy, it works glitchy at SSG-EG parts). Can be an option for users.
• It's an option to select number of chips to increase/decrease polihpony. Should be an option for users. Default for libADLMIDI can work just 2, or better 4. With DosBox on phones, 4 should be fine. The pronlem when selected embedded bank uses Rhythm-mode feature of OPL2/OPL3 chip.
• For libADLMIDI, the ability to select one of embedded banks should be (the libALDMIDI by its API returns the list of available banks).
• For libOPNMIDI, are no embedded banks, but you can supply a pile of bank files (the xg.wopn is default) and allow choice between them, but mainly use xg.wopn as default one, and allow user to select any bank from the file system. The libADLMIDI also supports custom banks in WOPL format. These banks can be created/edited via my OPL3-Bank-Editor and OPN2-Bank-Editor.
• For both libADLMIDI and libOPNMIDI:
  • The "automatical arpeggio" option suggested to be disabled by default, and be an option for users.
  • The "Volumes model" option should be available for users to switch
  • The "Channels allocation mode" should be available for users to switch
  • "Enable panned stereo" flag is also an option that allows to escape the left-center-right stereo limitation of chips, and use full-panning stereo (using a hack in chip emulators made by me and my friend @jpcima who gone two years ago into nowhere...)
• Also, supported file formats:
  • libADLMIDI supports MID, RMI, XMI (also supported multi-track files!), MUS (Id's format), IMF (also Id's used in Wolfenstein and other games), CMF, also EA's MUS format too but it's not so widely used.
  • libOPNMIDI supports MID, RMI, XMI (multi-track files supported too), and MUS, but no IMF and CMF.

[vitamin-caig]

Let's go to vitamin-caig/zxtune#2183 :)

[freq-mod]

libADLMIDI is good, libOPNMIDI still has some features left to implement to be honest - PCM, PSG for example. Or at least ability to use Fluidsynth/TiMIDIty for PCM voices, but that's the player issue.

Nuked OPN2 just don't work on phone, it requires even more resources to work.

it works on fairly recent (last few years) phones, it's not YM2608-LLE 😛 personally I wouldn't go below YMFM, all others are absurdly inaccurate

[Wohlstand]

it works on fairly recent (last few years) phones

Even it works, it consumes too much of battery's energy. Imagine you run a stress test on all your CPU cores, and you'll eat phone's battery in the quickest way.