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.


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.


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 is:

mod s3m xm it mptm stm nst m15 stk wow ult 669 mtm med far mdl ams dsm amf okt dmf ptm psm mt2 dbm digi imf j2b gdm umx plm pt36 sfx sfx2 mms mo3 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.