How is libopenmpt related to other descendants of ModPlug, in particular, libmodplug?
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 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?
|source code line endings||LF||LF||CRLF||LF||LF||CRLF|
|GNU Autotools build system (with cross-compiling support)||yes||no||no||yes||no||no|
|custom Makefile build system for Unix-like systems||no||yes||no||no||yes||no|
|custom Makefile build system for Emscripten||no||yes||no||no||yes||no|
|custom Makefile build system for Haiku||no||yes||no||no||yes||no|
|custom Makefile build system for cross-compiling with MinGW-W64||no||yes||no||no||yes||no|
|Android NDK build system||no||yes||no||no||yes||no|
|Microsoft Visual Studio project files||no||no||yes||no||no||yes|
|bundled with zlib, ogg, vorbis||no||no||yes||no||no||yes|
|bundled with miniz, stb_vorbis||no||yes||yes||no||yes||yes|
|bundled with mpg123||no||no||yes||no||no||no|
|bundled with minimp3||no||yes||yes||no||no||no|
|bundled with FLAC||no||no||yes||no||no||yes|
|bundled with PortAudio||no||no||yes||no||no||yes|
|bundled with pugixml||no||no||yes||no||no||yes|
|bundled with Foobar2000 SDK||no||no||yes||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
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
The full list of supported file types for libopenmpt 0.3 is:
mod s3m xm it mptm stm pt36 nst m15 stk st26 ice wow ult 669 mtm med far mdl ams dsm amf okt dmf ptm psm mt2 dbm digi imf j2b plm sfx sfx2 mms stp dtm gdm umx mo3 xpk ppm mmcmp
The full list of supported file types for libopenmpt 0.2 is:
mod s3m xm it mptm stm pt36 nst m15 stk st26 ice wow ult 669 mtm med far mdl ams dsm amf okt dmf ptm psm mt2 dbm digi imf j2b plm sfx sfx2 mms gdm umx 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
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
How can I access plugin configuration in foo_openmpt?