Messages

Chris Huelsbeck has run a Kickstarter campagin to fund a new limited edition box set containing, among other things, arrangements of selected Turrican soundtracks with a real symphony orchestra, and new studio recordings and arrangements of "nearly all" Turrican tracks - in a massive, "gorgeously packaged" limited edition box set which will "will never be produced in this form again after the project is completed!"

You might justifiably think I'm a bit late in announcing this news, given that the campaign finished running this evening.

In fact, at the precise moment I first found out about it and opened the page, the text at the right read: "This project successfully raised its funding goal 6 minutes ago."

SIX MINUTES.

To say that I am slightly annoyed would be the understatement of the century.

It has to be said that it goes both ways; I've played commercial games which were soundtracked with freely available music the authors probably got off a compilation somewhere.  I bet the composers never got any royalties!

As for audio tracks, I think that if AMP isn't prepared to host the 'exotic' formats such as TFMX, RJP, etc. then it definitely shouldn't be hosting OGG files.  Don't try and compete with UnExoticA; stick to what you're best at.  Since there's no way AMP would host any CDDAs which were not from a game of some kind (otherwise, where would you stop?!), there'd be a 100% overlap between the two sites.  Just stick to collecting tracker music from every source including, but not limited to, games, and AMP will still have a purpose.

The 128KB limit on ProTracker sample size is a rather more practical one: in the file format, sample size is stored in a 16 bit word, measured in words (so divided by two).  This gives a maximum of 65,535 words (or 131,070 bytes).  Anything larger physically can't be a ProTracker file.

Wow.  Reading through my old posts, it seems I believed version 3 was close to completion back in September.  It's had - what, two major rewrites since then?

Yes, eight months is a pretty miserable amount of time to spend putting this archive together, isn't it?

Anyway, I have finally - finally! - uploaded what I sincerely hope will be the very last version to the AMP FTP.  Archive size 12,538,306 bytes.

I've changed a lot, and sometimes I changed my mind about changing things, and I decided it was finished about three times.  And it's also 4:00am, so excuse me if I have absolutely no clue why you should prefer this new archive to that old one.

I think the major changes are that it's now much more intelligent about writing sample data, and doesn't perform conversions where unnecessary, and it also tries to make the pattern lengths in the conversion line up as much as possible as those in the original data (you'll have noticed that there used to be a lot of patterns which start in the middle of a phrase).

An unnecessary sample conversion is one where there's a more or less 1:1 mapping between the RJP sample info and the S3M equivalent (say, a reasonably straightforward snare drum), which means the original data can just be written straight in without having to 'record' it, losing quality.  As a result, some tunes (try FotAQ-12-02) are now noticeably higher quality, as well as smaller in file size, than before.

And there's loads of miscellaneous stuff too.  In the previous version I recorded some samples at half quality because I thought they played so low you wouldn't be able to tell the difference, but it turned out you could, so now everything's in high quality.  Unfortunately that caused all the file sizes to near-double, hence all the time I've been spending trying to optimise the conversions by other means.  I've also got a little doohickey which detects sample which are identical in all but volume, preventing duplication of sample data.

But the real reason the archive's a megabyte smaller is that I cheated and deleted a load of songs which were either duplicates (a lot of Chaos Engine music) or dull (Diggers ingame music - well, that's my excuse, the real reason was that I couldn't get the S3M format to play nicely with the newly astronomical file size).  There are now 209 S3Ms.

In summary: higher quality (maybe), more accurate conversions (possibly), smaller file sizes (in some exceptional cases).

Please don't hate me.

Source attached.  I know how you all love reading that stuff.

I'm afraid that was subsong 33, not 34!

34 should be the very last one.

(33 isn't in my RJP archive because it's a copy of the last few sequence positions of the previous subsong, 32.  I can only assume it must be a quirk of whatever program was used to compose the music, since such subsongs appear to be bewilderingly common - I have also caught them after the Chaos Engine credits music, and the Robocod title music, among others.)

OK, all being well (which is unlikely, since this program has a fondness for going disastrously wrong just when I think I've found the last bug*), a new version of my RJP->S3M format converter is nearing completion.  It now copies original sample data where possible (rather than recording it at different pitches) for better quality playback, and no longer downsamples some instruments (since it sounded awful).  It detects duplicate samples, and those which differ only in volume, resulting in much smaller files in some cases (notably Sensible Golf).  It also attempts to intelligently determine how many beats are in a bar so that the pattern lengths better match up to the rhythm of the music, meaning fewer patterns should be required (most dramatically in Flight of the Amazon Queen 12-01).  A number of other optimisations and accuracy improvements are present.  Unfortunately, since the samples are now of twice their previous quality, most files are much bigger.

* (And, right on schedule, just as I was typing the above paragraph, I heard a piece of truncated sample data in the James Pond 3 music playing in the background.  Better luck next time? )

Anyway, since I'm looking at Richard Joseph's music once again, I want to ask a question I've been meaning to for a while: Is the Diggers ingame music supposed to sound like that?

I'm talking about subsong 34 here, the one which plays (plus sound effects) while you're actually digging through the planet Zarg.  Currently, this is a conversion nightmare, due to using nothing more than two very long samples which both quote pointers to other samples in both their vibrato and tremolo data pointers - a more or less nonsensical thing to do, although not unheard of (world 3 of the Chaos Engine uses a similar trick to great effect).

I remember watching my big sister play the RISC OS port of this very game, and I don't remember the pitch of the strings wobbling all over the place like it does in my conversion.  Sadly, I haven't been able to get the game working again, and in any case, the fidelity of Archimedes conversions of Amiga music players has historically been, erm, variable.

Nor, apparently, is it available on Amiga Longplay (a criminal omission in my opinion), and I haven't been able to find any other ingame footage of the original (not CD32) version on YouTube either.

So, can anybody supply some kind of recording of the background music as it is played in the original Diggers game itself?

I have a suspicion that the vibrato and tremolo pointers were actually ignored by the version of the player used - I certainly found a recording of the intro from Cannon Fodder 2 where the player used seemed to have no support for them, resulting in the siren sample at the beginning (which is supposed to slide up and then down) sound like a glitch.  Before I write anything, however, I'd like to know if my theory was correct, or if the music in the original game really was that weird.

This page is all in bold:

http://www.amp.dascene.net/analyzer2.php?idx=41015

A look at the source leaves me in no doubt why:

Code Select Expand

<p align="center">
was unranked at <b>The Party IV</b> for the <b>amiga music</b> compo in <b>1994
</p>

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!

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?

(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.

Well, that was quicker than I was expecting!

New file on FTP: Jason_Page_v2.zip, size 4785416 bytes.

This incorporates the technical improvements made in my Richard Joseph converter, principally the sample trimmer (bits at the end of samples which are, in practice, never heard in the tune not saved) and proper handling of pitch slides (replacing the old vague guesstimate of slide depth).  Many minor improvements have been made as well, including native S3M export (instead of a slightly dodgy second-stage converter) and pattern optimisation (smarter than just having as many patterns as positions).

I've also removed all the junk (or, at least, what I assume is junk) and duplicates (e.g. the second Uridium 2 file, which differs only in the ingame samples available - the music is identical).

Unfortunately, the optimisations weren't enough to push the Realms title music under file size limit, so that one has half-quality samples once again.

Export of original BASIC source not attached because my browser has suddenly decided to refuse to upload anything ending in ".txt" or ".zip" at all.

(Not sure if this should be in the FTP uploads forum?)

EDIT: After much grief, I've managed to circumvent the attachment problem.  Sorry, no comments as usual.

Version 2 is now on FTP!  Filename rjpconv2.zip, size 13,849,840 bytes.

It's much smaller than the last one because the main change is that I've removed all of the duplicates and junk that I could find.  I've also removed all the songs and subsongs which were just sound effects (e.g. most of Cannon Fodder, Sensible World of Soccer and Rome AD 92), although I could put them back if you want.  In total, there are 231 S3Ms.

If there's demand I'll put it on Modland as well, so everyone can listen to it.  (NB: The modules used are those from UnExoticA, as I found the Modland ones to be unreliable - the third world of the Chaos Engine had truncated sample data, and the Diggers song was from the CD32 version with half the subsongs missing!)

Source attached again.

Next I want to move all the technical improvements in this converter into a new version of my JPN converter, which now looks pretty pathetic in comparison.

Yes, I've had lots of problems with this as well, and it's really annoying.  Maybe the AMP database could be extended to include a "known alternate names" field?  That would certainly make a lot of things easier, even on existing pages where there are a lot of duplicates under different names already.  For example, Spaceman's page has about 4 or 5 copies of the first music from "Digital Innovation", all under totally different names!  (And I can add at least one to that - the ripped copy I've got, from before I discovered AMP, is called "di1".)

EDIT: Shit, hit post too soon!

The most annoying problem is when it turns out the tune I'm looking for is in the AMP database, but under a slightly different name, or with hyphens or spaces added or removed, or a slight truncation, so I can only find it by accident!  Example: Bruno's "on the road", which is "ONTHEROAD" in my copy.  Tunes where the name is hyphenated in one copy (as in "troubled-journey") but not in another are even more vexing.

Anyway, the attachment is one of the tunes which puzzled me.  I can't find it, but that may be because I don't really know what I'm looking for (the tune's filename, for example, is "airborne", but the track name is "air").  Sample quality is awful because it's been converted to an Acorn format with logarithmic samples and then back again.

yup : Bit / Eon for example.

Ouch.  There's a story there, isn't there?

It finished uploading seven hours ago, so you should have it!

No, it was automated.  I take the view that if you have to manually alter anything, you've failed in writing a converter.

I suppose I might as well put the source code here, since it'll be some time before there's any kind of documentation... it's all in BBC BASIC, though!  (With no comments, because I'm terrible at commenting, except for the assembler bits.)