I’ve produced game soundtracks for mobile phones for over 9 years now. When I was starting out I thought that all I had to do was simply to make a MIDI file. A piece of cake! But I was so wrong…
The feedback that I was receiving from the clients showed me how much. They were often saying that the music was sounding good on the computer, whilst on the mobile device it sounded terrible or even wasn’t playing at all. And I’m not sure what is worst. So I became forced to experiment – I was laboriously trying every single instrument, controller and effect combined with trial and error problem solving. Why does a certain effect work, while the other doesn’t, why some devices refuse to play some instrument, while on the other ones it works fine etc. Years of work. Of course I didn’t learn everything from my own research only. Looking back I am so happy that I was given the opportunity to meet people who taught me many things and shared their experience with me (thanks to all of them!).
After several years, through a focused effort, I managed to develop a system that apparently works, as requests for adjustments are rare now. I thought it would be worthwhile sharing some tips and knowledge that I have picked up along the way.
Just a little word of caution. It is impossible to prepare the MIDI file that plays perfectly on all phones, albeit some time ago I thought it was possible. Now I know it’s an utopia. There are plenty of models and differences relating not only to the GM patches, but also to the speaker. It is possible to avoid most common mistakes and make the MIDI sound acceptable on most phones, however.
And one last thing. The text requires the basic knowledge of the MIDI format and sequencers. It’s by no means a guide for beginners who want to just start their mobile career, it’s rather for those who are already familiar with the topic and have some experience.
It would seem that these days, when majority of mobile phones are capable of playing a truly large number of MIDI voices at the same time you’re allowed to go a little bit crazy and don’t have to care for polyphony at all. Well, nothing more wrong.
Bear in mind that you are working with typically small speakers that have limited bandwidth, and if the arrangement is too busy you‘ll hear nothing but one big noise. At the beginning of my career… I’m not a careerist person, so I’m hesitant to call it a career, but, say, in my past I had a tendency to make rather complex arrangements – piano, organs and guitars, trumpet and synth lines, not to mention sweeping pads in the background. I was proud and kept playing such a MIDI track on the computer, enjoying a massive wall of sound and imagining an overwhelming enthusiasm of the game players! But the very next morning the producers were saying that my track is so great that after 10 seconds everyone wants to turn off the sound immediately. Oh, how I hated them then! But hey, they were damn right.
I had to face the painful truth that on the cell phones the tracks with a simple, three-element arrangements work best. These elements are: 1) rhythm, 2) background, 3) melody, where each instrument occupies its own frequency range. You can of course have many instruments in the background, but do not use the same octaves as the bass and melody are using. And do not let all of them play at the same time.
So – what polyphony value is safe, how many voices can a MIDI track have to sound decent on the cell phones? Well, there are no strict rules. In any case, I try to limit the realtime polyphony to 16 voices. What is realtime polyphony and how to check it? This needs a brief explanation. There are different tools for these purposes – such as the Nokia Suite, but the problem is that most of them do not show the actual polyphony, they simply show maximum voice usage per channel, in other words – they count how many notes are triggered at exact same time. So – if we have a part with very fast and short notes of, for example, String Ensemble 1 (Program Change 49) we’ll get the information, that there has been used only 1
voice. And that’s not right. All the string notes release and eat up much, much more voices.
That’s why we need a secret superweapon. It is Beatnik Mobile Sound Builder.
1 – Here we see maximum voice usage per channel determined via file analysis (this is the “fake” polyphony described above).
2 – And here we have a realtime display of voices used by the renderer per channel during audition (and this is the realtime polyphony, yikes!)
3 – This is another extremely handy feature – it shows the maximum value of the realtime voice usage per channel. And then, at the bottom, you see a cumulative polyphony value.
4 – In this row you can define the maximum voice usage.
5 – And here we have the values used to create an SP-Midi information.
Do I have to say that I love Beatnik?
Unfortunately, the program is no longer evaluated and the developer’s website does not exist anymore, so you have to ask Google nicely for help in getting it.
2. Choice of instruments.
As we all know, the General MIDI bank has 128 instruments + a set of percussion samples, but how many of them can we actually use? Through years of experiments and mistakes I have found that many phones, especially the older ones, have a very limited set of sounds and some instruments are being replaced by different, similar ones. I’ve also discovered there is a group of patches, that sound too quiet, too loud, or just poor on most devices. But in order:
Other kits such as Power Kit or Electronic Kit sometimes do not play at all. As for the sounds I suggest to stick with the basic ones, such as: (C1) Bass Drum, (C#1) Side Stick, (D1) Acoustic Snare, (D#) Hand Clap, (E1) Electric Snare, (F#1) Closed Hi Hat, (A#) Open Hi- Hat, (C#2) Crash Cymbal 1. Toms is something that I use rarely. Just every now and then. Not that they sound bad or something, it’s just because I don’t want to waste the precious polyphony for something that appears once or twice in the whole song. I also suggest to be careful with Tambourine (F # 2) – on certain LG models it tends to sound too loud and aggressive, no matter how low the velocity is. The same goes to hand percussion like congas and bongos. On few Samsung hand phones there is a strange, long and bassy reverb tail attached to them. Very unpleasant. And it’s better not to touch other percussion instruments. Yeah, they may sound fine on the newer devices, but the older ones won’t play them or, in the worst scenario, we get a piercing screech instead.
And what about the bass? We have quite a nice selection of bass patches in General Midi bank, but the one that works best on mobile phones is Synth Bass 2 (Program Change 40) – unlike the rest bass patches it’s perfectly audible on all devices which I had the opportunity to check. However, it is relatively rough, dominant sound. Therefore, if we need a delicate, more subtle bass, we can experiment with Acoustic Bass (PCH 33).
As for the piano, the most safe patch is Acoustic Grand Piano (PCH 1). Especially on old phones (see section 10). With other patches there is always a risk, For example, the Rhodes Piano sounds way too faint on some Siemens devices.
Organ sounds. Well, sometimes they play okay, while some other time they stand out from the tune because of their volume and their distinct timbre. (I would point out here the old Samsung phones and especially the SMAF format mentioned later in the article).
Acoustic Guitar. Again – the most safe is Acoustic Guitar Steel (PCH 26).
Rhythm guitar – Electric Guitar Clean (PCH 28). Distortion Guitar (PCH 31) is better for riff playing than Overdrive (PCH 30). Sometimes I use 2 layers of both patches and blend them to taste – when it works well, it’s a nice complex sound that adds depth and thickness.
Strings and pads. I have not noticed any major problems here. One thing that you should keep in mind is that you can’t use any EQ or reverb to move the instruments intro the background, all you can do is to play with the volume. But not quite. Older Sony Ericssons (such as K300 or K700) had an interesting bug – some instruments, for example orchestral strings, are blurred in strange way, as if they were filtered. Of course, it’s impossible to make an orchestral tune to sound good with these strings and you had to look for alternative patches, but with some creativity, you can make a good use of that bug. The bugged instruments sound
like they were EQ’ed fairly brutally with lowpass filter and drowned in long Hall type reverb. So you can combine a dry melody with them to create an illusion of depth. It sounds pretty neat. See section 6 for a suitable audio clip.
Unfortunately, the bug has been removed from newer models.
There is one general rule here. Avoid the sounds that are too low and too high pitched. The threshold of security for bass is the C1 note – lower tones may be (but don’t have to) inaudible. The upper limit is around C6 – the high notes have the tendency to sound really fatiguing on cell phones, even at low volume and velocity settings. So it’s better just to avoid them.
One important thing for SONAR users. It starts counting with MIDI Note 0 as C0. You can change the “Base Octave For Pitches” on the Options -> Global. I have mine at -2 to match Cubase, where Middle C is C3 (and what is the most common value, by the way).
4. Time-shifting the notes
I once made an embarrassing discovery. On some phones (e.g. Samsung E700) one can hear a loud crack at the beginning of the MIDI file. Short, yet very annoying. What’s that? Well, on top of every MDI channel there are controllers (see section 6) with the Control Change # 7 (volume) being the most important in this case. The problem is that the controllers demand a bit of time to take effect, so you need to time-shift a little all the notes from the top of the track. Shifting by a 64th note will be fine. This way we give the controllers the necessary time to kick on and the crack disappears.
5. Velocity and Volume.
Another extremely important issue.
A general advice – it’s much better to set the channel volume using the controller (CC # 7) instead of velocity. First off – some phones (e.g. the old Sagem models) simply ignore the velocity value. Second off – when the velocity is low, some other devices tend to play so quiet, that you can barely hear anything. And third off, and that’s even more important than anything mentioned above, you often need to change the volume of the whole MIDI song and it’s much easier and faster to do with the controller.
I always set the velocity to maximum value (127, that is) on practically everything. The exceptions are some elements of a drum kit – cymbals, crash, which I set to 50-75, otherwise they are way too loud and cover all the other instruments (like on Siemens phones). Sometimes I play with the velocity to achieve a sort of an echo effect, although more often I use the controller # 7 for this purpose.
There was a time, when the most frequently asked customer request were: “please make the MIDI file lower in volume by 50%” and “please make it louder by 50%”. When it became a plague I came to the conclusion that I had to do something with it. It turned out that some cell phones were simply louder than the “standard” was, while the other for a change, a lot quieter. So at some point I came up with the idea of providing each MIDI file in 3 volume versions: standard (100%), quieter by half (50%) and louder about half (150%).
Usually I set the volume controller to 85 for the melody and drums, for bass to 70, and to 50-70 for background instruments. In version 50% it is respectively: 42, 35, 25-35, and in the 150% version – 127, 105, 75-105. Of course, these values may slightly change when testing the file on the real phone (see section 10).
Anyway, ever since I started to prepare the 3 volume version, all the volume requests have gone out. As if by magic!
About the author: Piotr “JazzCat” Pacyna is a Poland based producer, who specializes in video game sound effects and music. He has scored a number of Java games for mobile phones and, most recently, iPhone/iPad platforms. You can license some of his tracks here.