View Issue Details

IDProjectCategoryView StatusLast Update
0001179OpenMPT[All Projects] Playback Compatibilitypublic2019-01-08 20:20
ReporterSlenderAssigned ToSaga Musix 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
Product VersionOpenMPT 1.28.01.00 / libopenmpt 0.4.0 (upgrade first) 
Target VersionFixed in Version 
Summary0001179: Several notes oddly stand out in this module
Description

IN menu.mo3 from the Rainbow Web soundtrack, https://www.dropbox.com/s/bsiobot8311srj4/menu.mo3?dl=1, several notes in the string section of the module seem to become louder at odd times when played in OpenMPT, most noticeable at about 0:23 in to the module. This does not appear to happen with XMPlay or other module players.

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)r11106

Activities

Saga Musix

Saga Musix

2018-12-23 19:32

administrator   ~0003766

The problem here is not that OpenMPT is wrong; the problem is rather that it used to be wrong in the past. :)

The original IT source file was writen with ModPlug Tracker 1.16 or maybe an early OpenMPT versions. The MO3 converter sets a flag to tell the player that the file should be played like MPT; but that's all the information we get. It doesn't tell us which version of MPT was used to write the file, so we can only guess which compatibility flags to disable. Currently we do not use this information at all, but maybe we can make an educated guess based on the MO3 version (this is a MO3 v1 file, so probably 10+ years old).

Slender

Slender

2018-12-23 19:41

reporter   ~0003767

That would probably be correct, the game was made somewhere around 2007.

Saga Musix

Saga Musix

2018-12-23 22:13

administrator   ~0003768

Ah, in that case it was most likely written with OpenMPT 1.17, which is known for putting those pesky instrument numbers next to note-offs, which is the source of the trouble here.
If you want to listen to the track in OpenMPT/libopenmpt, you can go to the compatibility settings and remove the checkbox next to "Instrument number with note-off recalls default volume" (third option from bottom at the time of writing) and re-save as IT to get this instrument to sound correct. Technically you can uncheck all of those boxes, as all but maybe two of them would be disabled if OpenMPT realized that the file was created with version 1.17.

Slender

Slender

2018-12-24 03:13

reporter   ~0003769

Incidentally, this appears to be the only fully tracked module in the soundtrack, so if you end up going the Operation Stealth root and working around issues in this module, it should be the only tune you'll have to worry about.

Saga Musix

Saga Musix

2018-12-24 10:36

administrator   ~0003770

Well, there difference between the SFX and MO3 case is that there are many MO3 files around, and there are people still creating new MO3 files, so it's harder to apply file-specific patches there. And it would be wrong, because we know that there are probably dozens of other MO3 files out there with the same problem. The correct way to fix this is to apply the "play like ModPlug would" flag from the MO3 header, but I will first ask Ian from un4seen which playback behaviours this flag should be applied to. There will be a fix, just don't expected it to be done in the next few days.

Saga Musix

Saga Musix

2019-01-01 23:42

administrator   ~0003790

Note: This is being handled in https://www.un4seen.com/forum/?topic=18350.0 - seems like XMPlay handles this playback quirk wrongly no matter if the file was originally created with OpenMPT or Impulse Tracker.

Saga Musix

Saga Musix

2019-01-04 20:23

administrator   ~0003800

So, the outcome of this is: OpenMPT now respects the "modplug mode" flag in MO3 files, however this doesn't with that specific file because the flag is not set here. XMPlay's own playback quirk is now also fixed, meaning that the file will also sound broken in XMPlay and other BASS-based players. Since there is no clear indication in the file that it was made with ModPlug (stereo samples and extended filter range are also supported e.g. by BeRoTracker), I am not sure we can heuristically make this working again. Since the file is essentially broken, I would advise to re-save it as an IT file, but apply either of those two fixes:

  • disable the "Instrument number with note-off recalls default volume" compatibility setting in the song properties (only works for libopenmpt-based players)
  • remove all note numbers next to note-offs (works in all players)
Saga Musix

Saga Musix

2019-01-08 20:20

administrator   ~0003804

I'll close this as it basically just plays as intended. Please use the workarounds described above if you want to listen to the song in either OpenMPT or current XMPlay versions.

Issue History

Date Modified Username Field Change
2018-12-23 19:09 Slender New Issue
2018-12-23 19:32 Saga Musix Note Added: 0003766
2018-12-23 19:41 Slender Note Added: 0003767
2018-12-23 22:13 Saga Musix Note Added: 0003768
2018-12-23 22:15 Saga Musix Product Version => OpenMPT 1.28.01.00 / libopenmpt 0.4.0 (upgrade first)
2018-12-23 22:15 Saga Musix Assigned To => Saga Musix
2018-12-23 22:15 Saga Musix Status new => assigned
2018-12-23 22:38 Slender Description Updated View Revisions
2018-12-24 03:13 Slender Note Added: 0003769
2018-12-24 10:36 Saga Musix Note Added: 0003770
2019-01-01 23:42 Saga Musix Note Added: 0003790
2019-01-04 20:23 Saga Musix Note Added: 0003800
2019-01-08 20:20 Saga Musix Status assigned => closed
2019-01-08 20:20 Saga Musix Resolution open => no change required
2019-01-08 20:20 Saga Musix Note Added: 0003804