A more complete overview of the earlier ModPlug history can be found at https://openmpt.org/legacy_software.

In December 1999, Olivier sent the module-playing parts of ModPlug Trackers’s source code to Kenton Varda, licensed under the GPL, to write a plugin for XMMS based on the code. The source code was later released to the public domain, and the mod-playing code was split off into a separate library, libmodplug, maintained as part of the ModPlug XMMS Plugin project. Today, libmodplug comes pre-installed on many Linux distributions and serves as a base for many other players and trackers such as Schism Tracker.

After ModPlug Tracker was open-sourced completely in 2004, OpenMPT development began, but initially no care was taken to keep the module-playing parts compilable as a separate library. In the following years, both Schism Tracker and OpenMPT progressed further regarding format support and playback accuracy compared to libmodplug. In 2013, the OpenMPT code base was refactored to support building a separate module playback library from the same source code base again. This library is called libopenmpt. In order to avoid possible future source code fragmentation, libopenmpt is, and will continue to be, developed together with OpenMPT itself in the same source code repository.

How is libopenmpt spelled and pronounced?

libopenmpt is spelled as libopenmpt (all lower case), and not LibOpenMPT, libOpenMPT, libOPENMPt, OpenMPT-lib, or anything else.

libopenmpt is pronounced as lib-open-m-p-t. It is common to pronounce the last 3 letters in native language and not necessarily in English. Please avoid pronouncing it as lib-open-modplug or lib-open-modplug-tracker in order to avoid confusion with libmodplug.

What are the differences between libopenmpt and libmodplug?

libopenmpt advantages:

  • libopenmpt has no global state and thus can be used by multiple threads (using different module instances) simultaneously. libmodplug, however, stores a lot of state globally (e.g. the mixer settings or the whole mixing buffer itself) and is therefore not usable in such a situation.
  • libopenmpt has a clean, designed from scratch, C and C++ API. The libmodplug API looks rather confusing in comparison.
  • 4 channel surround output actually works in libopenmpt for modules that use the surround pattern command. This is broken in libmodplug.
  • libopenmpt generally has better and more accurate playback quality and aims at mostly emulating the original trackers as close as possible.
  • libopenmpt can output un-clipped floating point PCM data.
  • libopenmpt is actively maintained.
  • libopenmpt is less crash-prone with malformed input files. We constantly fuzz-test the library to locate possible issues.
  • libopenmpt minor or patch version updates do not break binary compatibility. libmodplug broke the C ABI from 0.8.7 to 0.8.8.

libmodplug features missing in libopenmpt:

  • ABC file support: ABC is not really a module format, so libopenmpt has no plans to support this.
  • MIDI file support: Again, MIDI is no module format. There are better solutions available to play MIDI files, such as timidity, WildMIDI or FluidSynth.
  • Surround, extra bass, equalizer, automated gain control and noise reduction DSP effects: libopenmpt only tries to decode the actual module file itself and does not try to implement a general post-processing effect chain. Any effects could easily be applied by any player program externally after decoding via libopenmpt.
  • File export: libopenmpt (for now) aims to be a pure module playback library.
  • Live interaction: libopenmpt (for now) aims to be a pure module playback library. Functionality such as pattern editing might get implemented as a libopenmpt extension in the future.

Are the libopenmpt API and ABI stable?

Yes. libopenmpt API and ABI for both, C and C++, are stable since version 0.2-beta1. They will both be supported and provided by future libopenmpt versions.

Programs will continue to build against later versions of the API and programs linked will continue to work with the ABI of later dynamic libraries. In case we add new API and/or ABI functionality, we will increase the minor version number. Libtool and .so versioning is also provided conciously.

The API and ABI of libopenmpt_ext is not stable and subject to change. However, the API and ABI provided by any particular interface ID will stay unchanged. Support for any interface ID may disappear. If changes to an interface are made, a new unique ID will be used.

Is playback identical to OpenMPT?

For editing purposes, OpenMPT converts all formats into one of its five native formats (MOD, XM, S3M, IT, MPTM). libopenmpt does not need to do this, so some inaccuracies that are present in other formats in OpenMPT might play just fine in libopenmpt.

Furthermore, libopenmpt does currently not support VST plugins. Apart from this, libopenmpt and OpenMPT playback is practically identical.

What are the differences between the various provided source code packages?

  autotools makefile msvc
source code line endings LF LF CRLF
GNU Autotools build system (with cross-compiling support) yes no no
custom Makefile build system for Unix-like systems no yes no
custom Makefile build system for Emscripten no yes no
custom Makefile build system for Haiku no yes no
custom Makefile build system for cross-compiling with MinGW-W64 no yes no
Android NDK build system no yes no
Microsoft Visual Studio project files no no yes
bundled with zlib, mpg123, ogg, vorbis no no yes
bundled with miniz, minimp3, stb_vorbis no yes yes
bundled with FLAC, PortAudio no no yes
bundled with pugixml no no yes

How do I use xmp-openmpt in XMPlay for file types which are natively supported by XMPlay?

Set the file types you want to be handled by xmp-openmpt in the Priority filetypes box in the XMPlay plugin options for OpenMPT.

The full list of supported file types for libopenmpt 0.7 is:

mptm mod s3m xm it 667 669 amf ams c67 dbm digi dmf dsm dsym dtm far fmt fst imf ice j2b m15 mdl med mms mt2 mtm mus nst okt plm psm pt36 ptm sfx sfx2 st26 stk stm stx stp symmod gtk gt2 ult wow xmf gdm mo3 oxm umx xpk ppm mmcmp

The full list of supported file types for libopenmpt 0.6 is:

mptm mod s3m xm it 669 amf ams c67 dbm digi dmf dsm dsym dtm far fmt imf ice j2b m15 mdl med mms mt2 mtm mus nst okt plm psm pt36 ptm sfx sfx2 st26 stk stm stx stp symmod ult wow gdm mo3 oxm umx xpk ppm mmcmp

The full list of supported file types for libopenmpt 0.5 is:

mptm mod s3m xm it 669 amf ams c67 dbm digi dmf dsm dtm far imf ice j2b m15 mdl med mms mt2 mtm nst okt plm psm pt36 ptm sfx sfx2 st26 stk stm stp ult wow gdm mo3 oxm umx xpk ppm mmcmp

The full list of supported file types for libopenmpt 0.4 is:

mptm mod s3m xm it 669 amf ams c67 dbm digi dmf dsm dtm far imf ice j2b m15 mdl med mms mt2 mtm nst okt plm psm pt36 ptm sfx sfx2 st26 stk stm stp ult wow gdm mo3 umx xpk ppm mmcmp

You should, at the very least, put mptm there, because XMPlay does not support all OpenMPT extensions and detects these files as it.

How do I use in_openmpt in Winamp for file types which are supported by the bundled in_mod.dll?

Just uninstall the bundled in_mod.dll plugin. in_openmpt should be able to handle all file formats which in_mod.dll supports.

How can I access plugin configuration in foo_openmpt?

Go to File/Preferences/Advanced/Decoding/OpenMPT Component.