View Issue Details

IDProjectCategoryView StatusLast Update
0001919OpenMPTlibopenmptpublic2025-09-01 19:07
ReporterLouigi Verona Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status newResolutionopen 
Summary0001919: An instrument from a famous track is not played, although it is played in the original and in other players
Description

The track is gRAVEy by Hunz. It's an XM file. You can find it here: https://modarchive.org/index.php?request=view_by_moduleid&query=136344

If you play it with older players (like, the old ModPlug Player) or players like VLC, then the instrument is played correctly. If you play it with any modern application that uses libopenmpt, the instrument is ignored.

This starts in pattern 04, channels 9 and 10. Instrument is 15. The culprit is command 970. Removing it makes the instrument play again, although it is no longer playing correctly (the command is necessary for the right effect).

Steps To Reproduce

I tried playing it in a number of apps that use libopenmpt, including the OpenMPT itself, Fast Tracker II clone, modarchive's online player and Amiga Mod Guru on Android. All exhibit the same problem.

In order to hear how the track should be played, use old Modplug Player or VLC.

I also tried opening it through DosBox in the original Fast Tracker 2, and actually it also couldn't play this instrument. So, clearly something is wrong here, I'm just not sure what. It's clear that the track was intended to be played how the old Modplug Player is playing it, and I am positive that this was played correctly in the past in Fast Tracker 2. I know all Hunz's tunes by heart and this bit was always there, so much so that I immediately noticed when it wasn't.

Additional Information

The problem seems to stem from the "970" command. Removing it makes the channel work again.

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

Activities

Saga Musix

Saga Musix

2025-09-01 13:16

administrator   ~0006464

As you have observed, FT2 plays the module exactly like OpenMPT does. The tune was written in FT2 (MPT didn't even exist yet when it was written), so OpenMPT plays it like FT2 would, not like old MPT versions would (including ModPlug Player and VLC, which uses libmodplug). The offset effet is past the end of the sample, which stops sample playback in FT2.

Why is the melody there, then, when it cannot be heard even in the original tracker? Good question. It could be that Hunz optimized the samples before releasing the track, reducing their length to save space, but didn't listen to the whole track again and so he didn't spot that the lead didn't play correctly anymore. I am not aware of any FT2 version that wouldn't have this playback quirk, so I find it unlikely that you ever heard the melody like this in FT2 itself - however many players don't get this quirk right, so it's very much possible that whatever different players you would have user over the years, they all got it wrong. Or you listened to a different version of the file with a longer sample where the offset effect remains effective. But as it stands, with this particular file, the melody should not be audible in any compliant XM player.

Louigi Verona

Louigi Verona

2025-09-01 13:27

reporter   ~0006465

Last edited: 2025-09-01 13:28

This cannot be true because this exact file, not its other version, is played correctly in VLC and Modplug Player, as I have stated in the ticket. The sample is there and is played normally. Unfortunately, the issue tracker does not allow me to attach an XM file but it's the same file I linked to on modarchive. Please, try listening to it with the aforementioned players.

Louigi Verona

Louigi Verona

2025-09-01 13:32

reporter   ~0006466

And what kind of files can one attach? I just rendered a wav file from ModPlug Player with the correct playback but looks like neither wav nor mp3 are accepted.

Saga Musix

Saga Musix

2025-09-01 14:00

administrator   ~0006467

Please read my message again. I didn't claim that VLC or ModPlug Player would play the file like OpenMPT, quite the opposite. OpenMPT specifically fixed the offset bug that ModPlug Player / ModPlug Tracker / libmodplug (and by extension VLC) fail to emulate correctly, and that's why OpenMPT plays the file like FT2 does. If you load the XM file in an old ModPlug Tracker version (e.g. 1.16) and re-save it in ModPlug Tracker, then OpenMPT will play it like ModPlug Tracker / Player / libmodplug would (i.e. with ModPlug playback bugs), and then the lead can be heard.

And what kind of files can one attach?

Files need to be compressed (e.g. ZIP/7Z/RAR) before upload.

Louigi Verona

Louigi Verona

2025-09-01 14:01

reporter   ~0006468

I'm also wondering if the file would play correctly in FT2 if it was played through GUS? In my DosBox I only have a Sound Blaster option but the instrument text mentions GUS.

Saga Musix

Saga Musix

2025-09-01 14:07

administrator   ~0006469

The offset bug is identical between GUS and SB drivers in FT2.

Louigi Verona

Louigi Verona

2025-09-01 14:11

reporter   ~0006470

I contacted Hunz about this. Let's see if maybe he has the high quality version he mentions in the text. Maybe that fixes it? If not, I might do what you suggest, resave it and maybe upload the corrected version to modarchive (and assign it to Hunz)

Saga Musix

Saga Musix

2025-09-01 14:24

administrator   ~0006471

Most likely the high-quality version will sound correct, yes. It's a common mistake to shorten or downsample samples and then not listen back to the broken result (I certainly did it at least once). Please don't upload a simple re-saved version to ModArchive though - because this will, forever, manifest that the file should be played with ModPlug's playback quirks, which is simply wrong. The song was made with FT2, so it must be resaved in FT2 with a correct 9xx parameter (956 is just within the playable range of the sample). If we assume that the sample was downsamples by a factor of two, 938 would probably be more correct.

Louigi Verona

Louigi Verona

2025-09-01 14:40

reporter   ~0006472

Understood. Let me see if I can correct the command and maybe reupload the corrected version? I will make my corrections directly in the FT2 clone (https://16-bits.org/ft2.php). Good idea?

Louigi Verona

Louigi Verona

2025-09-01 15:04

reporter   ~0006473

Done! Changed 970 to 938. This seems to be the intended value. It is different from how legacy Modplug Tracker would've played it but you have convinced me that that was actually an error. There's definitely a weird blip which I don't think Hunz ever intended.

GRAVEY_FIX.xm.zip (509,546 bytes)
Saga Musix

Saga Musix

2025-09-01 19:07

administrator   ~0006474

Yeah I think that looks okay. Though it would be much nicer to have the original 2MB version!

Issue History

Date Modified Username Field Change
2025-09-01 12:51 Louigi Verona New Issue
2025-09-01 13:16 Saga Musix Note Added: 0006464
2025-09-01 13:27 Louigi Verona Note Added: 0006465
2025-09-01 13:28 Louigi Verona Note Edited: 0006465
2025-09-01 13:32 Louigi Verona Note Added: 0006466
2025-09-01 14:00 Saga Musix Note Added: 0006467
2025-09-01 14:01 Louigi Verona Note Added: 0006468
2025-09-01 14:07 Saga Musix Note Added: 0006469
2025-09-01 14:11 Louigi Verona Note Added: 0006470
2025-09-01 14:24 Saga Musix Note Added: 0006471
2025-09-01 14:40 Louigi Verona Note Added: 0006472
2025-09-01 15:04 Louigi Verona Note Added: 0006473
2025-09-01 15:04 Louigi Verona File Added: GRAVEY_FIX.xm.zip
2025-09-01 19:07 Saga Musix Note Added: 0006474