Development: Test Cases/S3M
This test suite is a collection of S3M modules that were created while discovering playback bugs in OpenMPT. It is meant to be an easy way to check for regressions when code is changed, or to verify your own player’s routines if you are concerned about playback compatibility. The tests are designed in a way so that it is easy to figure out if your player is working correctly. In most test cases, your own player’s output can be heard on the left channel, while Scream Tracker 3’s output is heard on the right channel. This way, it is easy to find out whether everything works as intended or if there are any discrepancies without having to read any long test descriptions. When it is impossible to do such a cross-verification, a more detailed description of the test can usually be found in the sample, instrument or comment text.
Bit-exact output is not the goal of this test suite, correct playback is, so slight deviations from Scream Tracker 3’s output (e.g. different resampling algorithms, pop reduction, etc.) are acceptable. Some tests will only sound correct on the first run. Unless stated otherwise, it is not important that the test output sounds identical when looping the module.
Most test cases are documented (more or less) in OpenMPT’s source code with a reference to the filename of the test case. I am sorry that many tests do not have proper descriptions − I have started this documentation years after I have fixed some of these issues and can thus not remember all the details anymore. If you are stuck with one of the tests, you may have a look at specific source code revisions that are provided with most tests to see what was changed in the code to make it work correctly.
Last but not least, please keep in mind that some descriptions might be wrong or too general. Sometimes, the description might be correct in the given test case, but changing the test case might invalidate the description. If you know better than me, please correct the texts, and please ask me if you need more information one of the test cases. The documentation is not always optimal because the test cases have been written long before I have created this site.
Current status: OpenMPT passes this test since revision 1198.
Description: If “Force Amiga Limits” is enabled, the limits should also be enfored on the stored period, not only on the computed period.
Current status: OpenMPT passes this test since revision 1134.
Description: Scream Tracker 3 stops playback if the period is too low (the frequency is too high), but there is no maximum threshold above which playback is cut.
Current status: OpenMPT passes this test since revision 6127.
Description: Scream Tracker 3 resets the start position of the last pattern loop on every pattern transition. Each time pattern 1 is played, seven notes should be heard.
Current status: OpenMPT passes this test since revision 11602.
Description: Related to ParamMemory.s3m, even empty effect cells with a non-zero parameter contribute to the effect memory. In this example, a major arpeggio should be heard, as there is a 37 no-op effect on the first row.
Current status: OpenMPT passes this test since revision 10915.
Description: When Scream Tracker 3 encounters a note without instrument number, it recalls the previous note′s offset. But unlike ProTracker, it does not add up offset values. When played correctly, this module should stay silent.
Current status: OpenMPT passes this test since revision 1053.
Description: Scream Tracker 3 uses the last non-zero effect parameter as a memory for most effects: Dxy, Kxy, Lxy, Exx, Fxx, Ixy, Jxy, Qxy, Rxy, Sxy. Other effects may have their own memory or share it with another command (such as Hxy / Uxy).
Current status: OpenMPT passes this test since revision 1221.
Description: When there are multiple row delays (SEx), only the first one is considered. The tricky part here is that the “first one” might not always be the “leftmost” one, because Scream Tracker 3 first evaluates all “left” channels (whose name starts with L in the pan table), and then all “right” channels (whose name starts with R in the pan table). This test case does not exploit this behaviour, the first row delay is always found on a left channel or there are only row delays on a right channel. I do not really know if it is worth emulating this idiosynchrasy. Note: Scream Tracker 3 does not have tick delay (S6x) commands, but they are tested here for completeness (Impulse Tracker supports them as well, so its playback behaviour is used as a reference).
Current status: OpenMPT passes this test since revision 1221.
Description: Rows on which a row delay (SEx) effect is placed have multiple “first ticks”, i.e. you should set your “first tick flag” on every tick that is a multiple of the song speed (or speed + tick delay if you support tick delays in your S3M player). In this test module, the note pitch is changed multiple times per row, depending on the row delay values.
Note: This test case broke in r3520 and was fixed again in r4895.
Current status: OpenMPT passes this test since revision 4796.
Description: ScreamTracker 3 limits the final output period to be at least 64, i.e. when playing a note that is too high or when sliding the period lower than 64, the output period will simply be clamped to 64. However, when reaching a period of 0 through slides, the output on the channel should be stopped. When played correctly, both channels in this module should play identically.
Current status: OpenMPT passes this test since revision 7525.
Description: A portamento up or portamento down effect immediately following an arpeggio effect should slide from the last arpeggiated note, and not from the channel frequency as it was before the arpeggio. Tone portamento is not affected. When played correctly, both channels in this module should play identically.
Current status: OpenMPT passes this test since revision 3578.
Description: If the sample number next to a portamento effect differs from the previous number, the old sample should be kept, but the new sample's default volume should still be applied.
Current status: OpenMPT passes this test since revision 6316.
Description: Hxx and Uxx use the same effect memory for the vibrato depth. For example, U1F followed by H00 causes the second effect to be played as H1F and vice versa. This also effectively means that Kxx will always plays “normal” vibratos, even if a fine vibrato has previously been used. When played correctly, this module should remain silent.
Current status: OpenMPT currently fails this test.
Description: A “broken” pattern loop. The voice should say “1” and then repeat “4 2 1 2”. Interestingly, the playback differs between various versions of ScreamTracker 3.
In total, OpenMPT passes 12 out of 13 tests.