Problems with modules playback.

[system64MC]

Hi. I encountered some problems with tracker modules playback.

The first one is lowpass filter sounding different if the sample rate is under 50kHz or above 50kHz. You can try playing the goddess.mptm through OpenMPT and SDL-Mixer-X. Try with 44100Hz to notice the problem. Note that if I comment "include(music_xmp)" in the CMakeLists.txt, that fixes the issue. So this is likely a problem with libxmp.

The second one is the playback speed. With the magica.mptm module, it goes faster than expected at some point (you also can compare with OpenMPT)

The third problem is the OPL3 not working. You can try with the th06_04.mptm module.

Possible solution : Maybe using libOpenMpt for module playback would solve the problem? Or letting the user choosing between libopenmpt, libxmp or libmodplug?

Here are the test files : Archive.zip

[Wohlstand]

include(music_xmp)

You should don't do this as you can just disable the libXMP using CMake's arguments -DUSE_XMP=OFF. Currently there are two libraries supported - libModPlug and libXMP. The libXMP is more prefereable because it has better support of various formats and is actually maintained thing while libModPlug is not maintained for a while, just by me and other folks to maintain build compatibility with various compilers and environments.

The third problem is the OPL3 not working. You can try with the th06_04.mptm module.

It's because no suitable OPL3 emulator is used here. At the libXMP repository is a suitable task exists regarding the OPL3 support.

Possible solution : Maybe using libOpenMpt for module playback would solve the problem? Or letting the user choosing between libopenmpt, libxmp or libmodplug?

I did some attempts, and: libOpenMpt is extremely heavy thing, additionally, it's tricky or even impossible to properly build it on some platforms. In static builds it adds extra 5 or more MB of binary file size, which is a pain for low-end platforms, and therefore it can be supported optionally only.

[Wohlstand]

But, I could try to add the libOpenMPT module but it will be disabled by default (as ffmpeg is) because of dependencies.

[Wohlstand]

P.S. You really should report your problem to the official libxmp repository here: https://github.com/libxmp/libxmp/

[system64MC]

Alright, thanks! I will report those issues in the libxmp repo. I think libOpenMPT disabled, but can be optionnaly enabled is a good compromise. However, the size of the lib is big, but would it be also heavy, performances-wise?

Edit: reported the problems as you said : https://github.com/libxmp/libxmp/issues/755

[Wohlstand]

but would it be also heavy, performances-wise?

About the performance, I didn't benchmarked these things yet. To confirm that, it's need to make a separated benchmark tool that will decode the same file by different libraries and measure the time they will spend to perform the work.

[system64MC]

Benchmarking is quite an hard thing to do Also thank you a lot for this incredible improvement of SDL Mixer. Despite of the small problems in libgme and with my mptm modules, it's an excellent library. I'm considering using it in my game framework.

[system64MC]

Talking about modules, did you had a look at https://github.com/adplug/adplug?tab=readme-ov-file? It can play modules such as a2m (Adlib Tracker 2à and RAD (Reality Adlib Tracker) and more. It's licensed under LGPL.

[Wohlstand]

Playing of fully OPL based modules is possible to implement on the side of libADLMIDI library which is actually a MIDI synthesizer based on OPL3 emulation, however, right now it's licensed under GPLv3 until author of inherited files will grant me LGPL or I will replace them with my own.

[Wohlstand]

What about the AdPlug, it seems needs to be fully modified to standalone library rather than a plugin for players.

[sagamusix]

I did some attempts, and: libOpenMpt is extremely heavy thing, additionally, it's tricky or even impossible to properly build it on some platforms. In static builds it adds extra 5 or more MB of binary file size,

That is more than double the size of what I would expect of a full libopenmpt build. Which platform is that on? And which platforms do you have issues building libopenmpt on?

About the performance, I didn't benchmarked these things yet.

You don't have to take my word for it, but OpenMPT mixing routines haven't changed much in over 20 years. You can still play heavy modules on a Pentium 2 with the same performance as ModPlug Tracker did back then. Obviously, this depends on the chosen resampling quality though (using 8-point interpolation on an old machine is not a good idea no matter which module player you use), and whether the module uses other optional features such as DSP plugins.

[Wohlstand]

@sagamusix, I built it as a static library for the x86_64 Linux locally, and additionally I verified the build on other things. To make the suitable integration into my build trees, I crafted my own CMake build, otherwise, default one (autotiols) is a pain for cross-platform build (At the moment when I did such experiment). It fails to build on MSVC compilers, but successfully builds everywhere also, MinGW and on other operating systems.

Anyway, there is a long time passed after that experiment, and I should get another shot on this with the latest code.

[system64MC]

This is quite promising! I don't know much about MSVC, I mostly use gcc and MinGW to be less dependent of Visual Studio. In fact, I work on Linux.

[Wohlstand]

On my end I had a goal to make the package that will build everywhere including MSVC that I don't like by myself because it supports modern C++ standards worse than GCC and CLang.

[sagamusix]

Do you mean that you had issues building with MSVC using autotools (that is not a supported configuration on our side) or when using CMake? The latter should not be a problem at all.

Here's some instructions how to integrate libopenmpt into any build system: https://github.com/OpenMPT/openmpt/blob/master/doc/libopenmpt/gettingstarted.md#building-libopenmpt-with-any-other-build-system

[Wohlstand]

No, the building issue that code has several incompatible places that needs a polishing. Anyway, that might be no longer actual as I did that test a while ago.