Beyond Oasis (The Story of Thor) released!

BirdyBro is back with a new, massive release: Beyond Oasis!
The game is known also as The Story of Thor and with its 34 tracks I believe that it is among the biggest releases we’ve ever done.
If this wasn’t enough to grab your attention, then know that the composer is none other than the master of the Mega Drive soundtracks himself: Yuzo Koshiro!

Massive thanks to BirdyBro for this huge contribution and, as a reminder, we’re still accepting contributions so feel free to check our guidelines and submit any rip you want!
While we know that the tools at our disposal are not perfectly accurate, they are so close that it doesn’t really matter unless our material is being used for critical work where a nearly perfect accuracy is needed, but that’s not what Community Releases are for.

Thanks again to our contributors who’ve helped us in our mission up to today and hopefully we’ll be back soon with more news about Mega Drive rips (something amazing is in the works!) and maybe some more arcade goodness!

Click here to comment

Sonic 3D Saturn release updated!

Thanks to two kind followers on Twitter I discovered that our digital rip of the Sonic 3D Saturn release was lacking 3 tracks: those were tracks not included in the CD-Audio part of the disc, but were part of the 3 FMVs the game has.

In addition to this, there were a couple of errors in the release which have now been fixed.

A quick changelog of what has been updated:

  • Corrected the name of the artist in both file names and tags
  • Corrected the names of the Rusty Ruin Zones (they were swapped)
  • Added 3 new tracks which were part of FMVs (those have SFX in them, nothing we can do about them)

The links have already been updated so you can go and download the fixed release.

Please keep reporting us errors and mistakes so we can fix them ASAP!

Click here to comment

Recording games from Neo Geo

MV1FS Audio output

MV1FS Audio output

After one more poll on Twitter, it seems like there’s enough interest to go ahead and write a proper article about how we’re recording music from the Neo Geo instead of just a quick document in the FAQ (which is going to be a shorter version of this and it will still be made).

I think it’s fair to start with a premise which I know is going to be a major let down for lots of people: there are several games on the Neo (especially the newer ones) which are basically made of just mono-aural ADPCM samples.
It’s PCM, there’s nothing else to this. Games which have their soundtracks with only ADPCM are Metal Slug 5 (maybe even 4?), Matrimelee, the newer King of Fighters (I believe from ’99 onwards), Blazing Star (and I have to check Pulstar) and many others.

Those games won’t be recorded because it’s absolutely pointless.
Just listen to them in an emulator or in M1 or what have you, you’re going to get exactly the same sound as from real hardware (minus noise and hiss).
I could make digital rips of them, but that’s not the point of our project, so they’re going to be left out.

This said, let’s get down a bit to the technicalities.

First off, the Neo Geo was a very particular platform having the (almost) exact same hardware for both the arcade boards (known as MVS) and home console (known as AES). Both were released at the same time so SNK definitely had this plan in mind from the get go, although it’s indisputable that their main target were arcades and home consoles were just a way to get extra income. After all, most of their games (with a couple of exceptions) were all coin-ops which needed credits to play and the AES versions had minor modifications to have basic menus but were otherwise identical to the MVS ones with Free Play enabled so that no credits were required.

This has led us to choose an arcade board as a platform to record the game from (and because AES systems costs almost like a new car) and this opened another whole range of issues: several MVS boards have been made and they were all different, some having 2, 4 or even 6 slots and others having no line level stereo output (remember that the JAMMA standard has only amplified mono output which goes straight to the speakers – the MVS used a slightly different JAMMA layout which added the possibility of stereo amped audio and a fourth control button for each player side).

Much like the Mega Drive we were once again confronted with a choice: which hardware version of the MVS should we choose?

Unfortunately I couldn’t find much information on which boards were produced first (remember that the first hardware produced will always be our target), but this page from neogeodev seems to hint that “A” boards were produced first, followed by B, C and then, maybe F (made by Fujitsu). There are also boards which do not have a letter at all and those might be the absolute first to be produced and our preferred choice.

Obviously what we are concerned most with is the audio circuitry and luckily, unlike the Mega Drive, all the MVS hardware used the Yamaha YM2610 and YM3016 so it’s all a matter of studying what was used in the audio output circuit.
Looking at board scans kindly provided by mvs-scans, we can see what a MV1 (possibly the first board revision produced) was like and, comparing it to the MV1FS for which we have an actual schematic, thanks again to neogeodev, we can see that they share the same audio output using a pre-amp section with 3x 4558 opamps and a JRC 2066D headphone amp (much like the Mega Drive, although it uses a Sony CX1034P headphone amp – the MVS head amp is much more powerful!).

I already had a couple of MV1FZ motherboards so I decided to pick one and gut its entire audio output stage and replace it with the same one found in the MV1 (4558 and 2066D are still available today) so that we had basically the same board audio-wise and that was pretty much it.

Now I’d like to take a moment to give a big shoutout to Razoola and his Unibios because without him the rips we’re putting out wouldn’t have been possible: with the Unibios you can reproduce all the music in any game thanks to its Jukebox function and the best part is that since the game is not actually running the noise generated by all other components is really really low (almost lower than our Mega Drive!). This proved to be a very, very convenient solution and made recording games from the Neo a far easier job than the Mega Drive.

Finally, the last part was trying to find the unitary gain to get all our release recorded at the correct volume and this proved to be a guessing game: I just picked the loudest game/track I know of which is the intro of King of Fighters ’99 (which is so loud that even by playing it back normally you can hear it sound distorted/clipped) and lower the volume on the headphone amp until it didn’t clip on the recording side.
And even then… when I was recording Metal Slug I found out that there was a very loud part in “Final Attack” which clipped pretty badly and I had to reduce the volume further.

Now, what about the games?
While a NeoSD would be the ideal solution, unfortunately I don’t have one and the cost is just too high for me, so I stuck to my trusty, modded/fixed 138-in-1 cart and, before recording, I used another tool from the Unibios which checks the ROMs for their integrity to make sure that they weren’t tampered with and, so far, all the games I recorded on the Neo checked out fine!
Remember that this means that there are several games (like Fatal Fury) which are not in the cart, so I won’t be able to record those.

And with that I think that I covered all the bases for what we’re doing to record Neo Geo music.

If I missed anything please make sure to let me know through our Forums or social media!

Thanks for reading!

P.S.: a final note, just to reiterate something I already said in a previous post: we’re not giving up the Mega Drive releases, we’re just waiting for the new tools to be coded and tested. This whole Neo Geo thing is just a way to fill the void and give something to all of you who’ve been so kind to follow us so far.
This also means that we are not accepting requests for Neo Geo or other arcade hardware and not all games for the Neo will be released.

Metal Slug 2 released!

Click on the image to go to the download page


Well, I guess people have spoken and it looks like that, after all, you wanted more Neo Geo releases.
Not sure why the previous one (yeah, we released the first Metal Slug a week ago) didn’t get traction at all, maybe you don’t like the first ‘slug soundtrack? It’s one of my all time favorites! :'(

Anyway, there are going to be more Neo Geo releases in the future along with other arcade games (I have some PCBs).

Meanwhile, I think I’ll do a new poll on Twitter tomorrow (Facebook removed the option, thanks Mark) to see if you’d be interested in an in-depth article about how we’re ripping music from the Neo, so stay tuned!

Hope you’ll enjoy this release as much as I did recording it. This one is my all time favorite arcade games and it holds a special place in my heart.

And for those “in the know”, I’ll make a statement here, feel free to flame me for this…

2 > X


See you! ;D

Click here to comment

Metal Slug released!

Click on the image to go to the download page


I won’t spend much time talking about this because first I’m interested in two thing:

  1. Do you like it?
  2. Do you want more?

Please make us hear your voice, either through our social media channels (Facebook/Twitter) or our Forums, whatever works best with you.

Before you ask: yes, we’ll keep on doing Mega Drive releases once we have all the tools we need to do it properly.
Meanwhile, this could be a cool thing to fill the big, empty spaces we’ve left in the last years.

Once again: please, let us hear your voice and thank you so much for sticking with us through all of these years.

If there’s enough interest, I’ll follow this up with a nice, lengthy article about all the technical things behind the scene and how we’re ripping Neo Geo games.

Click here to comment

On the importance of defining tolerances

TL;DR – Click to show/Hide

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

Sonic 2 Test

Sonic 2 Test
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.