xmp-openmpt: An XMPlay input plugin based on OpenMPT

Started by saga,

Reply Print
Go Down Pages 1 ... 12 13 14 15

saga

#326
This was caused by the Amiga resampler being used for MED files by default, and this sample (plus a few others in that file) contains stereo samples with identical but phase-flipped data on the two sample channels. Since the Amiga resampler does not support stereo samples, they are downmixed to mono, which causes the left and right channel to be added together and effectively cancel each other out. The Amiga resampler is now disabled for MED files with stereo samples.

saga

#328
This should now be playing correctly. I also found that in the aftermath of the previous FC/MED fix, instruments were now completely detuned in XM files with linear slides and a few other formats; this is now fixed as well.

saga

#330
Oh joy, another one of those undocumented behaviours that even differ between OctaMED versions (the Windows version plays the file too slow). I have added a workaround for software-mixed files in SPD mode trying to use a tempo value less than 10, but no idea if once again it's too general or too specific.

saga

#332
Seems like there is yet another opaque condition when volume command parameters are 7-bit vs 6-bit... This is fixed now based on some behaviour changes I found in MED Soundstudio for Windows, as always there is no way to be sure if this is correct though or if it breaks other modules.

saga

#334
Quote from: guest• Looped sample 6 on channel 4 plays differently in Scream Tracker 2.3
Apparently ST2 does not sanitize the loop end, so the sample loop continues playing into the next sample. This is now emulated.

saga

#337
Okay, here's another attempt at guessing when to enable 7-bit volumes and when not to. This should fix instrument 15. Instrument 27 is not fixable with OpenMPT's current pattern effect architecture.

saga

#338
I found a way to slightly improve playback of instrument 27, it's not accurate but better than before.

saga

#340
If you turn off volume ramping, some clicks can be heard because there is a bass sample that is retriggered constantly and each time it retriggers, it is at a very high point. Volume ramping is exactly meant to reduce clicks like these.

saga

#342
Last Edit: by saga
Portamento behaviour should be more in line with OctaMED now.

manx

#345
Last Edit: by manx
2024-12-01: xmp-openmpt version 0.7.12 released!

 *  [**Bug**] Fixed various undefined behaviour found with ubsan.

 *  IT: Don't report files claiming to be made with Impulse Tracker 2.08+ as IT-made if they have no edit timer.
 *  IT: Ignore sample data in slots that don't have the "sample data present" flag set, if the file vaguely looks IT-made to avoid playing garbage caused by an Impulse Tracker bug that should not be audible.
 *  S3M: Detect early Schism Tracker versions.
 *  MOD: When trying to detect MOD files with broken order lists, the file size is now rounded down to an even number. This helps identifying some malformed files (MOD files can technically not have an odd size).
 *  MOD: Also enable ProTracker-compatible tremolo ramp waveform for M!K! modules.
 *  MOD: In ProTracker 1/2 mode, retrigger with instrument-less notes now keeps using the previous sample offset.
 *  Warn when a Startrekker AM file most likely requires an (currently unsupported) external instrument definition file.
 *  DBM / IMF / MED: When merging pattern commands, allow to move offset to volume column at the expense of a lower offset resolution.
 *  MED: Fix correct octave transposition in some MED files that have hardware mixing disabled but sample transpose enabled.
 *  MED: Don't enable Amiga resampler if any stereo samples are found, as it does not support stereo samples.
 *  MED: Fix tempo in some files using software mixing mode and legacy tempo values.
 *  MED: Avoid importing effect memory for some commands.
 *  MED: Retrigger with instrument-less note now keeps using the previous sample offset.
 *  MED: Disable sample swapping on notes with portamento, and don't resume stopped notes with portamento.
 *  MED: Only use 7-bit volume commands in MMD3 files made with a new enough version of MED Soundstudio.
 *  STM: Do not sanitize sample loop data. Scream Tracker 2 reads into the next sample's data when loops exceed the sample length.
 *  When evaluating MIDI macros containing letters "u" or "v" during seeking, the initial global volume was applied to them, rather than the global volume that would be reached at that pattern position.

 *  mpg123: Update to v1.32.9 (2024-11-02).

See https://lib.openmpt.org/libopenmpt/2024/12/01/releases-0.7.12-0.6.21-0.5.35-0.4.47/

Downloads:
 * xmp-openmpt for Windows 10 21H2 (or later) and SSE2-capable CPU, or legacy version for Windows 7 SP1 (or later) and SSE2-capable CPU
 * xmp-openmpt RETRO for Windows XP SP3 (or later) or non-SSE2-capable CPU
 * xmp-openmpt RETRO for Windows 98 SE + KernelEx (or later) (without configuration dialog)

guest

#347
Quote from: saga
Quote from: guestFirst channel in 10th order starting from row 28 is played differently in OctaMED.

...should play correctly now. Let's see what this breaks...

When "Use Amiga resampler for Amiga modules" is enabled it plays as in MED Soundstudio for Windows, not as in OctaMED for Amiga.

guest

#348
When Volume Ramping is off, the plugin seems to play as if the FT2 Config -> Mixing device ctrl. -> Vol. ramping option was still enabled, e.g. instrument 3 on 7th channel is washed out.

manx

#349
Quote from: guestWhen Volume Ramping is off, the plugin seems to play as if the FT2 Config -> Mixing device ctrl. -> Vol. ramping option was still enabled, e.g. instrument 3 on 7th channel is washed out.

This is by design. Original DOS FT2 dos not have the setting you mentioned and always plays it with FT2-style volume ramping. The setting was only added in the FT2 port to modern systemsby 8bitbubsy. OpenMPT and  libopenmpt treat FT2-stype volume ramping as an original-tracker playback behaviour feature. In OpenMPT, these can be disabled (in order to facilitate conversion to other and more modern playback behaviours and/or other formats), however, libopenmpt in general does not offer tuning individual playback compatibility flags (this would be hundreds of options). libopenmpt does not enable that compatibility flag for XM modules which have been saved by other trackers than FT2 that do not implement FT2-style volume ramping (as far as detecting the other trackers is possible, if it is not possible, the format-defining tracker (i.e. original FT2) is assumed). The goal here is to play modules as much as possible as they sounded in original FT2, and in particular not as they sound in players that to not mimic the extra-soft volume ramping of FT2, which makes most XM modules not sound as intended, IMHO.

So, this is not a bug. It may be possible to make an argument whether disabling volume ramping in general should affect this particular FT2 compatibility flag, but that would better be discussed in our issue tracker at https://bugs.openmpt.org/.
Reply Print
Go Up Pages 1 ... 12 13 14 15