View Issue Details

IDProjectCategoryView StatusLast Update
0001386OpenMPTFile Format Supportpublic2020-11-10 18:20
ReporterLachesis Assigned ToSaga Musix  
PrioritylowSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Platformx64OSWindowsOS Version10
Product VersionOpenMPT 1.29.05.00 / libopenmpt 0.5.3 (upgrade first) 
Target VersionOpenMPT 1.29.06.00 / libopenmpt 0.5.4 (upcoming stable)Fixed in VersionOpenMPT 1.29.06.00 / libopenmpt 0.5.4 (upcoming stable) 
Summary0001386: OctaMED 8-channel mode modules may rely on octave wrapping.
Description

https://github.com/OpenMPT/openmpt/blob/master/soundlib/Load_med.cpp#L737

    // In MMD0 / MMD1, octave wrapping is only done in 4-channel modules (hardware mixing!), and not for synth instruments
    // - It's required e.g. for automatic terminated to.mmd0
    // - dissociate.mmd0 (8 channels) and starkelsesirap.mmd0 (synth) on the other hand don't need it
    // In MMD2 / MMD3, the mix flag is used instead.
    const bool hardwareMixSamples = (version < 2 && m_nChannels == 4) || (version >= 2 && !(songHeader.flags2 & MMDSong::FLAG2_MIX));

From my testing the 8-channel mode part of this appears to be incorrect. Multiple 8-channel mode modules I have tested in OctaMED 4 rely on both types of octave wrapping for sample instruments (4-7 → 3; 8-A → -1-1), and in the 8-channel modules I've tested, octave wrapping works exactly the same way as it does in 4-channel mode.

The module mentioned in the comment (dissociate.mmd0) appears to use notes in octave 4, but from what I can tell these are actually in octave 3 due to instrument transpose (order 21).

Steps To Reproduce

Compare any of these modules in OctaMED and OpenMPT:

Module Location of octave wrapping behavior
you got to let the music.mmd1 Expects C-4 to wrap to C-3 at order 0.
did.mmd1 Expects *-4 to wrap to *-3 at order 11.
hypnotised.mmd1 Expects D-6 to wrap to D-3 at order 5.
maria.mmd1 Expects *-9/A to wrap to *-0/1 at order 1.
Additional Information

I've intentionally been avoiding modules that use IFFOCT and synth/hybrid instruments in my testing so I can't speak for how they behave in cases like these; anything I've claimed here applies to sample instruments only. (I found this bug while putting together a list of test modules for my MikMod transpose and octave wrapping patch.)

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

Activities

Saga Musix

Saga Musix

2020-11-10 17:55

administrator   ~0004506

Thanks. This is now changed in r13816. I guess I reached this incomplete conclusion when transposition was not implemented yet in the new loader.

Now the modules should sound fine, although the tempo is slightly off in "you got to let the music". MED Soundstudio imports it as 116 BPM, at which the samples loop properly. Both OpenMPT and xmp play it at a 113.6 BPM, which causes some breaks in the loops. Gotta find out where that discrepancy comes from...

Issue History

Date Modified Username Field Change
2020-11-10 05:49 Lachesis New Issue
2020-11-10 10:23 Saga Musix Assigned To => Saga Musix
2020-11-10 10:23 Saga Musix Status new => assigned
2020-11-10 17:55 Saga Musix Note Added: 0004506
2020-11-10 18:20 Saga Musix Status assigned => resolved
2020-11-10 18:20 Saga Musix Resolution open => fixed
2020-11-10 18:20 Saga Musix Fixed in Version => OpenMPT 1.29.06.00 / libopenmpt 0.5.4 (upcoming stable)
2020-11-10 18:20 Saga Musix Target Version => OpenMPT 1.29.06.00 / libopenmpt 0.5.4 (upcoming stable)