In an earlier blog post, I wrote about Sidewinder's music. Much to my delight, I found out a while ago that many classic Sidewinder modules have been remastered for his Timeless album, and they really sound fantastic. Exactly how I want a modern remake of classic MODs to sound. Go grab it!
Saga Musix' demoscene blog.
In this "blog", I want to collect music, demos and other stuff I come across and want to share with others.
If you want, you may also subscribe to this blog.
Most people would probably expect that there's nothing left to discover in the most widespread legacy module formats in 2021.
And yet, sometimes little details are discovered that were apparently overlooked by everyone else so far, or simply noone cared about them. This is exactly what happened not too long ago when I dug around in some S3M files, and while it is of course very well possible that someone else has made the same discoveries as I have made here, I am not aware of anyone documenting them before, so here we go because this was quite an epiphany worth talking about!
For many years I have been aware that there are some small but sometimes significant differences between Gravis Ultrasound (GUS) and SoundBlaster (SB) playback in Scream Tracker 3. For example, sample swapping works with the SB driver but not the GUS driver.
This is annoying, because there's not one objectively correct way to implement an S3M player, and a few S3Ms rely on either GUS or SB playback style. For a long while I have thought how one could heuristically detect how an S3M file should be played (something that OpenMPT already does with MOD files), but I couldn't come up with any convincing heuristics. Scanning sample texts? Too fragile. Looking for panning commands? Nice idea in theory, but there are many songs written for external players which supported panning regardless of which sound card was used.
Interlude: Many oldskool trackers simply dumped their internal data structures into their file formats. This is the reason why sometimes seemingly unnecessary data fields can be found in those files. Often these can be used to fingerprint whether a file was made with the original tracker that introduced the format or a clone, because the latter would typically zero out those fields, while the original tracker might keep some random data from runtime in them (e.g. EMS handles or whatever).
For most formats this kind of fingerprinting is not necessary, but for once, this turned out to be useful.
So, a while ago in June 2021, 8bitbubsy and me were talking about Skaven's "maxtestsong", a Scream Tracker module using 32 sample channels. Scream Tracker 3 itself could only use 16 sample channels simultaneously, so the file must have been created with a custom internal Scream Tracker build that could handle more sample channels.
This lead us to talking about "Call Me An Angel (Iri Mix)", another S3M module using 32 sample channels, but using a different channel allocation table - in "maxtestsong", the extra 16 channels were turned off according to the file header, while "Call Me An Angel" essentially instructs the player to re-use the same physical sample channels that were already used for the first 16 channels, which may produce interesting results when played back in Scream Tracker. OpenMPT detected this file as being written in Scream Tracker 3 rather than a known third-party tracker. So just to be sure, I re-saved the file in Scream Tracker 3 - if the re-saved file was 100% identical to the original file, it was unlikely that another tool was used to create this track.
But... the new file wasn't identical. There were some tiny differences in the sample headers, which turned out to be in the "Int:Gp" field - the internal address of the sample in GUS memory, which is of course useless to store in the file, but it turned out to be a goldmine.
I quickly figured out that Scream Tracker 3 cleanly initializes the "Int:Gp" values to 0 for empty sample slots and 1 for normal samples when using the SB driver, while the values would differ between samples when using the GUS driver. Yes, this was it! It was possible to reliably tell if the file was last saved with the GUS or SB driver loaded, and it should be a fairly safe assumption that the last driver used while saving the file is also the driver that is intended to be used for playing the file. If Scream Tracker didn't clean this field when re-saving a previously GUS-saved file with the SB driver, this discovery might have been useless.
After figuring this out, there were some remaining questions to answer - would this work for all Scream Tracker versions? Early Scream Tracker 3.00 versions only supported SoundBlaster output, and those versions always wrote 0 into the "Int:Gp" field. But at some point in late 1992, GUS support was added, and all Scream Tracker versions since then populate the "Int:Gp" field in a way that could be easily fingerprinted.
I guess I'm incredibly lucky that I use the GUS driver by default in my Scream Tracker DOSBox setup (a relic from more than ten years ago when I was running DOSBox on a much slower CPU), because otherwise I might have never turned a closer look at the "Int:Gp field" - "Call Me An Angel" was saved with the SB driver, and that's the only reason I saw those differences in the file.
Soon after, I made another discovery that might explain a long-standing mystery that I have been wondering about for many years. In "Who is the real Timelord?", I mentioned that there were some S3M files with IRC chat logs at the end of the sample data. There are also many S3Ms with other seemingly random crap past the sample loop end. I always wondered how this could happen - did Scream Tracker not read those sample files correctly from disk and accidentally read some cluster from an unrelated file? It must have been a Scream Tracker thing, because this phenomenon is incredibly common in S3M files while being practically non-existent in other module formats.
It turned out that the answer to this is also in the sample header fields. For the SB driver, there is some sample loop unrolling code in Scream Tracker that doesn't quite do the right thing. Supposedly Scream Tracker tried to put the first 512 samples of the sample loop past its loop end, and for some reason the offset to write those samples to is stored in the "Int:512" sample header field.
However, what Scream Tracker ends up doing is moving a block of sample data 512 bytes closer to the sample loop end (which is stored in "Int:512"), but this block extends 512 bytes past the actual sample end - and this means that whatever 512 bytes were following the sample end would now become part of the sample. Often this would turn out to be some other sample data - or just random bytes left over in memory from some other application that was previously running (remember, no memory protection in the DOS days!). So if you re-save a file in Scream Tracker where the "Int:512" field of some sample is set, you will trash that sample's last 512 bytes with some more or less random memory. With this knowledge it is now also obvious why so many samples in S3M files seem to have their loop end perfectly matched up against some follow-up garbage - the garbage wasn't there when the loop was initially created.
Alright, that's it for now. I haven't written a blog post in a long while, but I thought that this topic was worth taking about in more than just some dry developer documentation.
The Roland D-50 is an amazing synthesizer, but its keyboard circuitry also has some small issues that may show up after all those years.
To detect the key velocity, there is a pair of electrical contacts below each key. Due to their arrangement, the time between closing the two contacts varies depending on how hard you hit the key. The contacts are protected by rubber caps, but small dust particles (or as my case when I got my D-50 five years ago, a piece of tin foil ) may get below the caps and prevent the circuits from closing. Depending on which contact the dust ends up on, the key no longer sounds at all (I have never experienced this), or it always sounds at full velocity (like in my case). It is also possible that this only happens randomly and not every time the key is pressed.
Luckily, it is possible to fix this issue by cleaning the circuit boards. There are various tutorials on the internet which helped me fixing the problem. However, some of these tutorials contain unnecessary steps or otherwise contradict each other, so I decided to share my experience with the procedure here. Still, you may read the other tutorial and watch the video to get a more complete idea of what you need to do. Read the whole tutorial first before doing anything!
Step 1: Opening the device
To open the D-50, it has to be put on its top. Mount it on some books or similar boxes to avoid resting the synth on the joystick and pitch bender. Remove the five screws on the back of the device and the screws on the bottom of the synth. You do not need to remove the four feet.
Step 2: Removing circuit boards
Once the synth is open, it's time to get the main board and key scan board out of the way. The main board is the big circuit board that sits in the middle of the synth. I decided to not unmount the board entirely, since I am not a masochist and do not want to disconnect all the connectors on the mainboard and ruin my fingers. I also wanted to cut a minimal amount of cable ties. I ended up cutting the two cable ties that hold the shielded cable at the bottom, as that will also help removing the key scan circuit board entirely. After that, I started disconnecting connectors on the mainboard until I could swing it away to the back of the synth.
Technically, you probably only need to unmount the key scan circuit board if you want to fix any keys below it, but I still recommend unmounting the board and keep it safe. To do this, you need to disconnect some more connectors below the board.
Once this is done, you can remove the six screws the hold the keyboard assembly in place. Have a look at the other tutorial if you are unsure where the screws are located. Also disconnect the aftertouch ribbon cable at the right end of the keyboard assembly from the board. Now you should be able to move the keyboard assembly out of the synthesizer. Be careful when doing so.
Step 3: Fixing the keyboard
To remove the keys, you first need to remove the springs that hold them in place. Note that black and white keys use springs of different length, so keep them separate! The springs for white keys have fewer coils than the springs for black keys. You will need to remove a number of keys next to the faulty key - how many pretty much depends on the length of the rubber strip below the keys, which varies across the keyboard. If you are unable to find the ends of the rubber strip, just remove more keys.
After the springs are gone, you may have to loosen the plastic film strip that holds the keys in place on the back of the keyboard assembly. You can pry it open carefully with a screwdriver. You can then remove the keys by pushing them below the film strip, but note that black keys cannot be pushed out before surrounding white keys are gone.
Now that the keys are gone, gently put the paper strips below them to the side (e.g. by fixating them with a screwdriver). Below them, you can find the rubber strips which need to be removed gently. Make note of how exactly the rubber strips were inserted (both vertical orientation and the horizontal "offset" is important!). Once those are gone as well, you can clean the contacts on the circuit board using rubbing alcohol (preferrably 90% or more) which you put on a q-tip. Be sure to clean the surroundings and the rubber caps from any debris as well - you do not want to repeat this procedure again too soon, do you?
Step 4: Putting everything back in place
Let the board dry a bit and put the rubber strips back in place. If they do not seem to fit at first, you possibly rotated them accidentally. Turn them by 180° and try again. Remember to put the black keys back first, then the surrounding white keys. Now you can put the springs back on the keys, and make sure the film strips on the back sit firmly again. If it no longer glues to the board afterwards, some tape or glue may help with keeping them in place.
Now you can mount the keyboard assembly again, reinstall the screws and connect the aftertouch ribbon. Reconnect the key scan board and install the screws. Do the same with the main board, and put some new cable ties on the shielded cable. Close the unit, put the screws back in place and you're done!
People like talking bad about ModPlug's IT/XM format hacks, and quite often they are of course right - ModPlug shouldn't extend these formats to add features that will either crash the original program or that simply make the file sound completely different. But is this true for all new features?
I wouldn't say so. One feature where I feel that quite the opposite is true are, surprise, instrument plugins (VSTi)! Why would I say that, given that VSTs are probably the most criticized feature addition? Especially VST instruments, which stay completely silent when played in any other player? Well, that's because those other players simply don't implement one of the most interesting features of Impulse Tracker and Fasttracker 2: MIDI output.
Let me give you an example. Do you hear anything apart from a drum beat when playing this with your favourite IT player? No? You don't hear an organ? Well, sorry to disappoint you, but that's not ModPlug's fault. This file was saved in Impulse Tracker. It plays correctly on Interwave and AWE soundcards, since those are the only two drivers in IT that can have sample playback and MIDI output at the same time. Instrument plugins are just a layer on top of this MIDI mechanism, and instead of having to tell people which synth they have to hook their computer up to, you can simply store a reference to a softsynth and all its parameters in the module file, making this awesome feature of IT and FT2 way more portable. If you compose a song with VST instruments in OpenMPT, you can, in theory, load it into IT, use one of the two MIDI drivers and play it there as well! The additional information that's required to store the VST references won't interfere with IT or FT2, so it's no problem really.
I do agree, though, that effect plugins are slightly more critical than instrument plugins, but keep in mind that there's worse - like IT's AWE32 driver which could enable hardware reverb and chorus, but the settings for those two effects were actually not stored in your IT files. This is just like adding a chorus or reverb plugin to your song, except that with plugins, you can also store the exact settings. I do not necessarily think that it's a good idea to spread such IT files with embedded plugin settings, but the same is of course true about IT files written in Impulse Tracker that make use of AWE32 effects or IT files that make use of Impulse Tracker's MIDI output. And the same holds for XMs, of course.
Some of you may remember the story about A Scam Artist called Jay, a person that ripped of several well known modules by various tracker artists and sold them as his own on his band's CD. I'm not aware of many cases where people claimed to have written some tracked music that wasn't theirs, but recently The Mod Archive was contacted by two persons claiming to own the music released under the handle Timelord. Well, I was curious to find out who of the two was the real artist... So I did some research and wrote a story about it. Have fun reading it!
Some of you might be using my program Mod Library for performing searches on their module collection. It works great for finding sample texts and similar things. However, what do you do if you don't want to know which module contains a certain sample text, but rather which module contains a certain melody? I often have melodies playing in my head, most of the time I even know that they are from a module, and typically I even know the module format and the rough time frame in which it was written (most often this would be an XM module written around 1997, but that's a different story ).
Wouldn't it be cool to have a program which would let you search for exactly this kind of stuff? It certainly would. And would it actually be doable? Yes, it would! And who would do it? Well, maybe I would! I am currently thinking about completely rewriting Mod Library. The new version might replace the BASS library (which is great for what Mod Library currently can do, but sadly not for what the new version should be able to do) with the OpenMPT core for loading modules and analysing their patterns. The note information from the patterns would then be stored in a database using relative offsets (so that it doesn't matter if a tune was written in A minor or D minor). I find this idea very intriguing, but I can make absolutely no estimates if / when I will be able to code this. Is anyone else actually interested in such a project?
Update: In May 2014, development has finally started!
Hoffman of Unstable Label has released an awesome jungle musicdisk called 8-Bit Jungle at the Sunrise Demoparty last weekend. Although it's not entirely new material, you can safely say that this is one of the best music disks for the Amiga for some time. The download includes Amiga diskette images as well as the original Protracker MOD files as well as MP3 renders. Download and enjoy!
Finally, The Sound of SceneSat Volume 2 musicdisk is available in high quality Ogg Vorbis and FLAC! This epic collection of 73 fine tunes is nothing less than awesome.
Yersterday, I've come across some music by Maxus, and I was instantly captivated. On his website, you can find some really excellent chillout and psytrance music, all made with MadTracker. Some tracks I am especially fond of are:
- Andromeda (also check out the MadTracker source file!)
- Happy Flower
- Something Positive
- Colors of Life
- Off-Line (also featured on the Drone musicdisk)
If you like this, you will probably like other compilations by New Age Beats as well. "Andromeda" is for example included on M-Ether 2.
I haven't heard a tune as great as Human Nature by cTrix in a while. Positive, upbeat, light-hearted, and tracked to perfection, as I'm used to it from cTrix. Although this has been just released as MP3, his advanced tracking skill is evident here. Just listen to it!