Any ScreamTracker 3 experts in the house?

[swirlythingy]

(Please note: I'm well aware that AMP is far from the most appropriate place for this kind of post, but I'm damned if I know where to start looking for a better one.)

The attached file is a fruit of the latest version of my now hideously overrun project to automatically convert RJP music files to S3M files (It's Complicated, as Mr Zuckerberg might say).  Some of you might have noticed the new additions to the downloads page - rest assured they do not exhibit this bug, which was introduced in the process of making the tuning more accurate.  This file also contains a number of other as yet unreleased optimisations.

I've been tearing my hair out over this bug for two days, and have studied the ScreamTracker documentation very carefully, and just now I carefully calculated all of the relevant period values involved (or, at least, what I thought they should be) to find out where I was going wrong.  My calculations returned the answer I least expected - the original values in the RJP file are entirely consistent with the converted values saved to the S3M file.  It was at this point I decided external help was going to be necessary.

There are two possibilities remaining: Either I've fundamentally misunderstood some little nook of the documentation and haven't noticed yet, or there's a bug in my S3M player.

In the file as I hear it, the pitch slides are broken, in that they slide the pitch by about half of the value I would expect them to.  In this text I shall refer to channel 4 of pattern 5, which plays at position 5 (both numbers counting from 0).

The note D#4 on row 0xC uses the not uncommon compositional technique of starting on one note and then immediately sliding to another note slightly above - two semitones, in this case, or F-4.  RJP has no portamento function, so the only way to do this is to specify a duration in addition to a depth.  The converted pattern data looks like this:

Code Select Expand

Row Nte Sm Vo Efct
0B  --- -- -- - --
0C  D#4 0F -- F 02
0D  --- -- -- F 02
0E  --- -- -- - --

Now, according to my interpretation of the documentation, the period values ScreamTracker translates notes to vary according to the C-4 frequency specified in the sample list.  In this case, for various complicated reasons, it's 16574 Hz - about twice the default of 8363.  The file format documentation yields the following:

Code Select Expand

        Table for note frequencies used by ST3:

          note:  C    C#   D    D#   E    F    F#   G    G#   A    A#   B
        period: 1712,1616,1524,1440,1356,1280,1208,1140,1076,1016,0960,0907

        middle octave is 4.

                         8363 * 16 * ( period(NOTE) >> octave(NOTE) )
        note_st3period = --------------------------------------------
                         middle_c_finetunevalue(INSTRUMENT)

        note_amigaperiod = note_st3period / 4

        note_herz=14317056 / note_st3period

        Note that ST3 uses period values that are 4 times larger than the
        amiga to allow for extra fine slides (which are 4 times finer
        than normal fine slides).

(In the following, all numbers are rounded down, since I do not believe software of ScreamTracker's age is usually obsessively accurate.)

As I'm on the middle octave, the shift right business simplifies to period(NOTE), which is 1440.  Therefore, note_st3period = 1440*8363/16574 = 726.

Here comes another opportunity for me to have got things wrong: I believe the conventional slide commands (as opposed to "extra fine slides") act on the Amiga period, for compatibility.  So, note_amigaperiod = 726/4 = 181.

I didn't mention it before now, but the speed of the song is 6, and the "fast slides" option is off.  So, the amount subtracted from the Amiga period is (speed-1)*(value)*(two rows)=5*2*2=20.  The new note_amigaperiod is 161, and note_st3period is 644.

To get it back to period(NOTE), use: 644*16574/8363 = 1276.  This is more or less exactly F-4 - but the note I'm actually hearing is E-4!  Which is, coincidentally, more or less exactly what I'd expect if the periods were twice as far apart as I thought - i.e. played at 8363 Hz, instead of 16574!

So, two requests: Firstly, if there are any clangers in the above arithmetic, please point them out, and secondly, please play the S3M on your own computers and tell me if you hear the same problem.  Also, please tell me if it plays one octave too high or low.

[Asle]

Hey,

Quite a post
OK, I'm not the best to answer to much technical question. However, I loaded the file in DP2 and it sounds right. I loaded it in Milky and again, it sounds right.
You can edit like that:

Code Select Expand


Row Nte Sm Vo Efct
0B  --- -- -- - --
0C  D#4 0F -- F 02
0D  F-4 0F -- G 0F
0E  --- -- -- - --

The result is the same, from what I can hear.
G is the portamento fx and G 0F is to be sure we get there . right value may be G 02.

I know it doesn't help much. Still, I'm afraid that's the best I can manage.

Sylvain

[swirlythingy]

However, I loaded the file in DP2 and it sounds right. I loaded it in Milky and again, it sounds right.

OK, now, this is interesting...

I've attached a recorded snippet, starting from just before the position 4/5 boundary, showing what I hear when that pattern plays.  Could you do the same with MilkyTracker or similar?

[Asle]

I've attached the result from DP2.

[swirlythingy]

Asle's recording is correct and mine isn't.  Sigh - time to get a-emailing.  At least it's nice to know I'm not at fault for once!