Audacious - OLD, PLEASE USE GITHUB DISCUSSIONS/ISSUES

My advice: Don't "switch", but introduce a separate input plugin for a new MOD backend lib.

The rationale is simple. Hardly any MOD player lib is perfect. There are many thousands of MOD files. (Side-note: when I use the term "MOD" I don't refer to only the ancient .mod files from the late 80's and early 90's, but also the many derivatives that have been published later.) Typically, authors of new MOD playing libs start with a new set of test files, such as their favorite ones and new problematic ones pointed out in bug reports. A lib would need to be really popular for more users to give it a try and test it with old and new files in their own mod file collections.

Audacious runs fine with multiple MOD input plugins installed. Users may choose to disable individual plugins. No harm is done, if keeping alternative input plugins for some time.

About XMP and its plugin for Audacious: The plugin has been ported to Audacious 3 a long time ago and continues to work fine. I'm not aware of any immediate maintenance requirements. Libxmp is in a fine state and continues to receive fixes for problematic files when they come up. I don't think it supports the .dsm format of your test file. In modplug 0.8.9, some of the samples sound slightly out of tune here.

Interestingly, the "problematic module" attached to this ticket crashes openmpt123.

Going through a dir of testmods, I've found a few that don't play correctly (probably because Soundtracker detection isn't easy and some of the original mods are available as versions converted to Protracker) and one file that isn't recognized. Had files a modplug bug about it in 2011: https://sourceforge.net/p/modplug-xmms/bugs/13/

necros_-_spatial_distortion.dsm

$ openmpt123 necros_-_spatial_distortion.dsm 
openmpt123 v0.4.0, libopenmpt 0.4.0+r11103.pkg (OpenMPT 1.28.01.00 https://source.openmpt.org/svn/openmpt/tags/libopenmpt-0.4.0@11103 (2018-12-23T13:06:52.605038Z) clean-pkg)
Copyright (c) 2013-2018 OpenMPT developers <https://lib.openmpt.org/>

/usr/include/c++/8/bits/stl_vector.h:932: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = OpenMPT::ModCommand; _Alloc = std::allocator<OpenMPT::ModCommand>; std::vector<_Tp, _Alloc>::reference = OpenMPT::ModCommand&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.
Aborted (core dumped)

Debian Testing is somewhat behind Fedora because of Red Hat's involvement with GCC.

$ rpm -q gcc-c++ libstdc++
gcc-c++-8.2.1-6.fc29.x86_64
libstdc++-8.2.1-6.fc29.x86_64

It's the only file that crashes openmpt123 so far while parsing the pattern data.

Chris Spiegel has created a working audacious plugin for this already

I will wait for a request from Chris himself before "absorbing" his plugin into audacious-plugins. There is nothing wrong with him maintaining it out-of-tree if he prefers to do so (and it is probably less work for him that way).

(I am the libopenmpt maintainer)

necros_-_spatial_distortion.dsm

Interestingly, the "problematic module" attached to this ticket crashes openmpt123.

This is a libopenmpt bug, I added a ticket to our bug tracker at https://bugs.openmpt.org/view.php?id=1191 . We will release a fix ASAP.

necros_-_spatial_distortion.dsm

Interestingly, the "problematic module" attached to this ticket crashes openmpt123.

This is a libopenmpt bug, I added a ticket to our bug tracker at https://bugs.openmpt.org/view.php?id=1191 . We will release a fix ASAP.

Fixed in libopenmpt 0.4.2: https://lib.openmpt.org/libopenmpt/2019/01/22/security-updates-0.4.2-0.3.15-0.2.11253-beta37-0.2.7561-beta20.5-p13-0.2.7386-beta20.3-p16/

John Lindgren wrote:

Chris Spiegel has created a working audacious plugin for this already

I will wait for a request from Chris himself before "absorbing" his plugin into audacious-plugins. There is nothing wrong with him maintaining it out-of-tree if he prefers to do so (and it is probably less work for him that way).

Hi, I'm the author of this plugin. If you'd like it integrated with audacious-plugins, I'd be happy to move it there. It's 2-clause BSD licensed (I've just added an explicit LICENSE file to clarify this) so should be no issues there. If you're interested, let me know what I can do to help get it moved over.

Chris Spiegel wrote:

John Lindgren wrote:

Chris Spiegel has created a working audacious plugin for this already

I will wait for a request from Chris himself before "absorbing" his plugin into audacious-plugins. There is nothing wrong with him maintaining it out-of-tree if he prefers to do so (and it is probably less work for him that way).

Hi, I'm the author of this plugin. If you'd like it integrated with audacious-plugins, I'd be happy to move it there. It's 2-clause BSD licensed (I've just added an explicit LICENSE file to clarify this) so should be no issues there. If you're interested, let me know what I can do to help get it moved over.

I decided to just take a look and see the level of effort needed to incorporate the plugin into audacious-plugins, and it was very easy. So I've now got a preliminary pull request at https://github.com/audacious-media-player/audacious-plugins/pull/68.

As noted in the pull request, I didn't replace the libmodplug plugin, instead just making it lower priority, so that anybody without access to libopenmpt can still have a tracker plugin.