Throughout our project’s lifespan, people have raised doubts and concerns about using NTSC 60Hz consoles to play back all games, even those that were made in Europe where 50Hz PAL was the standard and, as such, could have been marketed towards their own countries, which ultimately meant that they should have been played at 50Hz (just like JP/US games were meant to be played at 60Hz).

Up until now, 16bap has always made the assumption that, with US/JP being the dominant market making it the most important target for any Mega Drive game released, 60Hz was the standard which developers and composers targeted and developed for.
As a side note, we are still unaware if there are any Mega Drive dev kits made exclusively for the PAL market which run at 50Hz.

Still, this possibility bugged me to the point where I decided to try my luck and reach out to one of the most prolific videogame music composers based in the UK: Matt Furniss.
One more reason for trying to find out whether games developed in Europe should be played back at 50Hz was that due to recent discoveries we have to log all the VGMs again with blast’em, so it would be the perfect moment to try and solve this mystery.

To my surprise and delight, Matt replied to my inquiry and finally the truth I’ve been dreading for all this time was uncovered: all games he composed on Mega Drive were to be played back on a PAL 50Hz system.
I took this chance to hopefully discover whether this was true with all the other European composers and while he said he wasn’t 100% sure, he added that it’s probable that other UK composers used 50Hz to make their tracks on the Mega Drive.
This would make sense and, at this point, it could probably be applied to all other European composers.

It was time to go back to the drawing board and start doing research again. From scratch.
All that we’ve been doing that concerned games developed or composed by European composers has been wrong and 16bap needed a plan.

First and foremost, we needed a list of games which were made in Europe and/or had European composers.
Project2612‘s database came to help as well as SegaRetro and various Wikipedia articles.
After a first draft was finished, I got a lot of help from other very knowledgeable members such as Valleybell and ctr001 who helped me figuring out how certain sound drivers worked and which were most likely meant to be played back at 50Hz (one example is the Krisalis sound driver which, as Valleybell stated, “the sound driver pauses every 6th frame in NTSC mode”).

This took at least a month of everyday work to put together, but in the end I managed with the help of various other contributors of both vgmrips and Project2612 to create a comprehensive wiki entry in the vgmrips wiki about which games should be played at 50Hz.

I would love to say that the list is definitive and 100% accurate, but at this point I can’t make any statements about its accuracy.
The only thing we know for sure is this: if a game was made by Matt Furniss and developed by an European developer, then it must be played on a PAL 50Hz console.

This is where the second and most important part comes in: 16bap needs help in verifying that the games listed in the wiki are indeed to be played at 50Hz.
Right now the list works as follows: if a game was developed by a European developer and its music composed by a European composer, than it is highly likely that the game must be played at 50Hz.
All the other cases (EU dev + non-EU composer or EU composer + non-EU dev) need to be studied and need further research.

And this is pretty much where we’re standing right now: we have a tentative list with only a bunch of games we are certain that need to be played at 50Hz and the rest are pretty much up for debate.

Again, I must stress that any help in verifying the games listed in the vgmrips wiki page I made is more than welcome and we’re in dire need of people to help us logging the VGMs with blast’em.

As for 16bap, I’ll be making amends to our contributor guidelines and I’ll work on a revised version of the Deadfish VGM Player tailored for 50Hz playback.
I’ll make another post when I’ll have finished updating it.

Finally, I’d like to apologize to all people who have been following us for this huge mistake we’ve made.
I’d love to say that this is going to be the last time we mess up, but the reality of things is that even with all the tools at our disposal, there’s still an immense amount of guesswork involved and while we’ll always keep striving to document all our findings and sharing them with the community, we can’t assure that our work is ever going to be 100% accurate, despite our best efforts.

Thank you all so much for sticking with us through the years, it’s been quite a journey, and I’ll be back with a couple more posts in the following weeks, as we have a new updated and improved VGM logging guide in the works which is going to be hosted on the vgmrips wiki to help guide newbies in the process of logging, trimming and looping VGMs properly with blast’em.

One of the key topics we discussed with Artemio, the mastermind behind the 240p Test Suite and MDFourier, in a previous article about preservation was how much close we need to get to original hardware behavior to declare that it’s accurate enough to be considered appropriate for preservation.

Up until then, we’ve always given for granted that all Mega Drives (YM2612 equipped), apart from sound signatures, were pretty much alike and behaved the same, audio wise.

While doing research on the VGM format and discussing with all the people involved in this complete rehaul, starting from the new VGM logger thanks to blast’em, I’ve started questioning the accuracy of original hardware itself.
As already stated, I’ve always thought of Mega Drives as “perfect machines”, but it turned out not to be the case.

What we’ll be focusing on in this article is timing and how much “reliable” the Mega Drive is (ie: its ability to keep a steady tempo throughout a track), because the differences in sound signatures have already been discussed ad nauseam and the reasons for choosing an early Japanese model 1 Mega Drive for this preservation project have already been explained.

The only way to reliably measure and study those differences are, of course, via MDFourier.

Please note that all those tests won’t be using any VGMs or Deadfish VGM Player for the sake of everyone’s peace of mind.

The first test is just playing and recording the MDFourier test on the same Mega Drive revision (we’ll be using ours, Jap model 1 VA1) over and over again and analyze the detected frame rate which is going to tell us about the average speed at which the test is being played back.

It will become apparent that the there is a tiny drift in speed every time the test is run.
What we’re interested in is looking for the biggest drift we can measure and make a mental note of it.

Those are the partial results (for brevity sake) of 10 MDFourier analysis (note: to avoid drifts due to components heating up, the Mega Drive has been turned on 20 minutes before the start of the tests and the room temperature has been kept constant to the best of my possibilities):

– Detected 59.9223 Hz video signal (16.6883ms per frame) from Audio file
– Detected 59.9225 Hz video signal (16.6882ms per frame) from Audio file
– Detected 59.9226 Hz video signal (16.6882ms per frame) from Audio file
– Detected 59.9223 Hz video signal (16.6883ms per frame) from Audio file
– Detected 59.9226 Hz video signal (16.6882ms per frame) from Audio file
– Detected 59.9225 Hz video signal (16.6882ms per frame) from Audio file
– Detected 59.9224 Hz video signal (16.6883ms per frame) from Audio file
– Detected 59.9226 Hz video signal (16.6882ms per frame) from Audio file
– Detected 59.9222 Hz video signal (16.6883ms per frame) from Audio file
– Detected 59.9223 Hz video signal (16.6883ms per frame) from Audio file

Even on the very same Mega Drive, after doing some basic math ( [(1 / 59.9223Hz) – (1 / 59.9225Hz)] * 60s * 1000 ) we can see that there is a drift of ~0.5 ms every minute.

What happens, though, when we try and measure different revisions of Mega Drive?
Thanks to Artemio who has provided recordings from several Mega Drive revisions, we have access to the results of single runs of MDFourier on every one of them (bear in mind that some revisions might have a higher intrinsic audio drift than the one we measured on our model 1, so the differences might be even bigger):

– Detected 59.9219 Hz video signal (16.6884ms per frame) from Audio file (Jap Model 1 VA1 made in Japan)
– Detected 59.9221 Hz video signal (16.6883ms per frame) from Audio file (Jap Model 1 VA6 made in Japan)
– Detected 59.9221 Hz video signal (16.6883ms per frame) from Audio file (US Model 1 VA6 made in Japan)
– Detected 59.9219 Hz video signal (16.6884ms per frame) from Audio file (US Model 1 VA3 made in Japan)
– Detected 59.9234 Hz video signal (16.688ms per frame) from Audio file (US Model 1 VA3 made in China)
– Detected 59.9235 Hz video signal (16.6879ms per frame) from Audio file (US Model 1 VA7 made in Japan)
– Detected 59.9232 Hz video signal (16.688ms per frame) from Audio file (US Model 1 VA6.5 made in Japan)
– Detected 59.9227 Hz video signal (16.6882ms per frame) from Audio file (US Model 1 VA2 made in Taiwan)
– Detected 59.9231 Hz video signal (16.6881ms per frame) from Audio file (US Model 2 VA3 Made in China)
– Detected 59.9233 Hz video signal (16.688ms per frame) from Audio file (US Model 2 VA4 Made in China)
– Detected 59.9233 Hz video signal (16.688ms per frame) from Audio file (US Model 2 VA2.3 Made in ?)
– Detected 59.9233 Hz video signal (16.688ms per frame) from Audio file (US Model 2 VA0 Made in Japan)
– Detected 59.9234 Hz video signal (16.688ms per frame) from Audio file (US Model 2 VA1 Made in Taiwan)
– Detected 59.9233 Hz video signal (16.688ms per frame) from Audio file (US Model 2 VA1.8 Made in Taiwan)
– Detected 59.9138 Hz video signal (16.6907ms per frame) from Audio file (US Model 3 VA1 Made in ?)
– Detected 59.9232 Hz video signal (16.688ms per frame) from Audio file (US Model 3 VA2 Made in ?)

As you can see the gap grows way wider, now reaching up to 162ms every minute.
Notice though that the analysis of the US Model 3 VA1 (which is the same as a US Model 2 VA4, just in a smaller package) is a bit suspect.
This is why, in this context, we’re going to exclude this outlier from our measurements and consider only the other ones: this brings the drift among most of the existing Mega Drive revisions to 2.67ms.

Now, for the sake of completion, let’s try and take a “real game” in consideration, such as Sonic 2.
To measure the differences, the tracks will be recorded and aligned in Audacity and then the drift in timing will be measured at the 60 seconds mark.
The track chosen will be Emerald Hill Zone.
The tests will be done in the Option Screen of the game with the Sound Test.
To make the comparison more readable, only the left channel will be represented (there’s no drift in timing between channels).

It is immediately apparent from the fist picture that even the simplest task as trying to align the start of the tracks is a real struggle, even when zoomed this in.
The biggest issue at hand are, fundamentally, two: the lack of resolution (the highest we can sample is at 96Khz, sampling at 352Khz would have really helped) and human error.

Anyway, I’ve done my best here and by looking at the second picture, where the cut at the 1 minute mark happens, the reason for using a synthetic benchmark such as MDFourier becomes apparent: good luck telling exactly where the drift is happening; not only there’s simply not enough resolution, but you need to make a judgment “by eye” and that’s almost as bad as judging sound “by ear”.

You can tell that there are some samples off in some tracks but they could be due to a small drift in the frequency spectrum which will mess up our reference point in the waveform.
Ultimately, we can conclude that the drift happens in a “real game” as well, but we are unable to properly measure it.

I personally believe this is the best example up to today of why we need tools such as MDFourier. Without them, we wouldn’t be able to make precise calculations and studies and we’d be back in the dark era of “guessing”, using our ears and eyes to try and interpret the data available to us.

In the above example with Sonic 2 we’ve kind of cherry-picked how to record the music by using the sound test. You can actually expect even a bigger drift when the actual game is run.
This is due to how the Mega Drive is structured and works and, without going into further technical detail, the reason is that the CPUs at work (the Z80 and the 68000) are doing other tasks in parallel with playing music.
You can think of the bus (the ensemble of data lines connecting the various components) like a highway: there are many cars, each with a specific task (play music, draw sprites, play SFX, etc.), but there can only be a certain number at the same time before they have to slow down – this is an oversimplification, but that’s how it works broadly.
As you can imagine, the difference gets even more dramatic when the game is playing in full swing since there’s more activity (scrolling, enemies spawning and other animations, sound effects), not to mention that some games even have slowdown in some scenes due to lots of stuff happening at the same time with the CPU unable to keep up (ie: Sonic getting hit and losing lots of rings).

The drift in timing is unpredictable and there’s simply no way to capture and reproduce them accurately because the original hardware itself is not accurate and is constantly changing in an inconsistent way.

This leads us to try and understand what we want to preserve when we’re recording music from a Mega Drive (or any other console, really).
We know that capturing all the small, tiny drifts that happen while the game is running is impossible due to too many variables (ie: the same track will not be played exactly the same twice), therefore we need to go back to the beginning and ask ourselves: “What is our goal? What is the ultimate scope of the project? What are we trying to achieve?”.

If you’ve read our past series of articles about how our project evolved, you already know that the 16bap’s goals have changed significantly over the past 9 years, so we’re no strangers to going back and starting from scratch.

Ultimately, while many considerations could be made about what’s important and what’s not about music in videogames, one thing we could hang onto and focus on is the composer’s intention.
As already discussed in the MDFourier article, we can only speculate about this, but I’d bet that no one composed music with the various drifts and slowdowns that the game could run into in mind.
The composer, most realistically, just sat at his workstation and composed the music which would then be “translated” to accommodate the Mega Drive limitations and put into the various parts of the game (for example Yuzo Koshiro composed music on a NEC PC-8801 and the music had to be adapted for the Mega Drive’s YM2612).

Our ultimate goal would then be trying to capture the music as close as possible to the author’s intention while, at the same time, trying to work around the hardware’s own limitations without cheating or breaking them in order to record them with the best quality achievable.

This is why it’s fundamental to define tolerances, because it’s impossible to get an exact 1:1 analog recording from original hardware. As a consequence we need to test and measure our recordings to know if they are close enough to how the original hardware, with all its imperfections and limitations, sounds.

Finally we’re at the crux of this article: tolerances must be defined because they are going to tell us if our recording is accurate enough.

We’ve seen that if you’d play a track on several revisions of the Mega Drive, you’d find that there is a 2.67ms drift over a minute.
This, right here, is our tolerance, which means that if our recording drifts less than 2.67ms every minute, than it’s accurate enough, because that’s how much a track from a real Mega Drive game would drift every time by playing it on the various revisions.

For the sake of “then how much are all your recordings off”, know that with rare exceptions aside (such as Rocket Knight Adventures which have been only recently fixed in blast’em due to a bug in YM2612 Timer B – and I believe that blast’em is the only emulator which has this bug fixed), the biggest drift I’ve seen every minute is ~32ms.

Now we need to really stop for a moment and think about the order of magnitude of those drifts.

Let’s take a game that runs at a steady 60Hz, which means every second, 60 images are drawn one after the other on your screen. That’s an image update every 16,68ms.

The tolerance we’ve defined is 2.67ms, almost an eighth of that. EVERY MINUTE.
Again, to put this in perspective, the AVERAGE human reaction time is ~200ms. That is, when you look at something on the screen, on average you take 200ms to recognize it and react to it.
We’re talking almost one hundredth.
Yes it’s that small.
Yes, even considering how far off our own recordings are at ~32ms. EVERY MINUTE. We’re talking about 0.53ms every second.

I think that’s enough perspective to let people understand that there’s no need to panic, our whole work hasn’t gone to waste and it is still plenty accurate (and it’s going to be basically undistinguishable from the new releases we’ll be making).

And now, for some closing thoughts.

We’ve been guilty of using the word “perfection”. Yes, we’ve used that word far too much, just use the search engine on our website and you’ll realize how much we’ve been telling people how “perfect” our work has always been without realizing not only that it wasn’t, but it could have never been because our source wasn’t perfect itself.
Someone could point out that such subtle differences which are undetectable by the human ear could be ignored (after all, if you can’t hear it, does it really makes a difference?), but since our recordings could be used one day to study in detail the music produced by a Mega Drive, we really need to make sure that every little detail is within tolerances of the hardware being recorded and studied.

But the gist of this whole article can be summed up as: stop looking for perfection where perfection isn’t in the first place.

And this is why it’s fundamental to define tolerances and always keep them in mind when doing preservation work in the analog domain. Assuming that your source is always perfect will inevitably lead to wasting a lot of time trying to attain something which is unattainable simply because it is not there.

Hopefully this has shed some light on how difficult preserving something deceptively easy and straightforward as videogame music can be and how hard are some decisions to make when confronted with the inevitability of doing “imperfect” rips and having to come down to terms with how analog audio works and its limitations.

As stated, going forward, despite our work being already ridiculously accurate to the original material, we want to close that tiny gap, if anything for everyone’s peace of mind (and my own sanity).

Hope you enjoyed this article, see you next time!

Closing note: Artemio himself has kindly pointed out that, as described in the MDFourier documentation, “Frame rate variations in the order of 0.001ms are natural, since we have an error of 1∕4 of a millisecond during alignment, and differences also occur by the deviations in sample rates and audio card limitations.”
At the time the documentation was written, MDFourier still only supported 44.1Khz and 48Khz sampling rates at 16-bit. Now it supports a way wider array of sampling rates (including 24-bit and 32-bit float).
All our tests have been done at 96Khz, 24-bit.

EDIT (13/04/2021): Artemio further specified in a tweet concerning this article that “That limitation is unchanged when you use higher sample rates, since it comes from sync pulses being 8 kHz tones and the cycle lengths associated with the frequency.”
Still, despite this tiny error in calculations within MDFourier, our measurements are not invalidated.

(This awesome comparison was made by Roareye in the game’s release thread and it thoroughly deserves to be a Featured Article on this website, straight to the front page.
I really hope this will also encourage other people writing for us: we’d love to hear your voice, every single opinion matters and helps us growing and getting better.
Thank you Roareye, I hope to read more from you!)

It’s fair to say Streets of Rage II is a personal favourite of mine, and likely of many other people here. The late 80s house/early 90s rave themes are quintessential to the atmosphere of the brand and maybe that is partly why it is stuck in limbo now.

I own this soundtrack several times over. I’ll focus on the best two for this comparison (The Bare Knuckle remastered Soundtracks and the 16 Bit Audiophile version), however for information’s sake I’ve included the Yuzo Koshiro Best Collection vol.2 in the lineup of information.

Continue reading →