MDFourier – The search for a reference

 

What is MDFourier? Let’s start this article by saying what MDFourier is not: it is not a tool to measure the “quality” of your Mega Drive/Genesis. Nope, unfortunately you can’t use it to go around showing other people how fantastic your console sounds.

So, with that in mind, what’s exactly the scope of MDFourier?

First, we need to understand how this all works.
MDFourier is made of two parts: a ROM you need to run on your Mega Drive and a PC Software to analyze your console’s output. This means you’ll need a computer with a way to record audio (ie: a sound card with line-in) and hook it up to your console’s audio output, which in turn will need a flash cart to run the MDFourier software (which is now included in the latest 240p test suite). This way, your console sends an audio signal to your computer and the MDFourier software on your PC analyzes this signal and understands how your console sounds (frequency range, noise floor, etc.), thus enabling us to see how two consoles’ audio output differ.

Now that we know how MDFourier works we’re going to delve deeper to understand the importance of Artemio’s, the mastermind and developer of MDFourier, superb work.

We have started this article saying that MDFourier is not a tool to measure “quality”, so let’s explore this concept and try to understand what we’d need to measure the quality of our own console’s audio output.

Think about something easily measurable, such as length. If my height is 2 meters, I can state that “I’m taller than most people”, which is a quality I have.
Although this may sound silly at first, we’ll be going through each step to understand why I can make such statement.
If I stay side by side with another person this can already give us an insight about who’s taller, but what about the rest of the world?
To overcome this limitation, we need to do proper measurements and the International System of Units tells us that to measure length we use the meter.
But what exactly is a meter? It is the measurement unit adopted by the scientific community to measure length and it is defined as the length of the path travelled by light in a vacuum in 1/299,792,458 of a second.
Today we all have the tools to measure length, but what if we didn’t and needed to make one?
Well, measuring the speed of light is not something manageable for us, but another viable (albeit less accurate) option is taking a plane and fly to the International Bureau of Weights and Measures in Sèvres, France, where you’ll find a metal bar known as the International Prototype Meter which is made of an alloy of 90% platinum and 10% iridium with two signs etched on it which will tell you exactly how long a single unit of meter is.
This is what we define “the reference”.
If we didn’t have the metric system, we’d have just a ruler with no markings on it which would still be useful for comparisons, of course, but we’d be unable to define any kind of length and, therefore, make statements on anything’s quality.

Now that we have established the concept of reference, we can understand what is needed to measure what we call “quality”: we need a tool to measure differences between two or more entities and a reference.

If you’ve been following us up until this point, you’ll probably have understood the point of this article: MDFourier is the tool which enables us to compare how consoles sound, but since we’re lacking a reference, we cannot establish how “good” or “accurate” our own is.

Which brings us to the main question: where is our reference? Where is our “platinum Mega Drive”? Does it even exist? And if there isn’t one, then which revision should we choose and why?

Years ago a discussion arose in several retrogaming communities about whether old videogames should be displayed with a 4:3 aspect ratio (the old TV standard) or with 1:1 pixels mapping (which is how emulators display games as standard; for example, Mega Drive NTSC resolution is 320×224, making it a 10:7 ratio) and the entire argument revolved around two concepts: following what the original developers/artists intended or what everyone at home were seeing at the time.
As you may have guessed, this is still an ongoing debate and there doesn’t seem to be a general consensus, especially because we don’t have proof of what the original artists were seeing back then on their monitors (although we know for sure that they used CRTs with a 4:3 aspect ratio) and we don’t even know if they had any kind of control over what happened to their artwork once it was digitized and imported in the game’s assets.
To wrap it up: there isn’t as of now an agreement on what ratio should be used due to the lack of a reference.

When the 16-bit Audiophile Project started, the reference dilemma immediately presented itself because we wanted to archive music not only with the best quality possible, but also trying to be as accurate as possible towards what the composers heard in the studio (and wanted the players to hear!) during the game development.
That’s when we decided to take a complete shot in the dark and tried to imagine what would have come closest to an hypothetical original Mega Drive dev kit (and how it would sound like) which the composers supposedly used during the games’ development. This lead us to the decision that our reference would be this we-don’t-even-know-if-it-exists-or-how-it-actually-is dev kit and tried to blindly get the same sound by using the earliest Japanese model 1 Mega Drive we could find and fixing the output stage by following SEGA’s own corrections in the later revisions.

We know that a MegaCD dev kit exists but it’s clear that it was made at a much later time than when the Mega Drive was conceived and released so we’re not really taking it into account as a possible reference.

Still, MDFourier has revolutionized the way we compare audio from different console revisions giving us an accurate, scientific way to do this and it will be fundamental in deciding what the reference should be. Without MDFourier we would still be trying to discern differences between console revisions by ear where our own perception and personal preferences would come into play: this should already tell you how pivotal Artemio’s work has been (and will be!) in preserving music from our beloved old videogame consoles and making emulators’ audio output as close as possible to the original hardware.

There are limits to how MDFourier can be used, though. The condition of the console and the recording interface play major roles here: when you record the same Mega Drive through different recording devices, you’ll get slightly different results, so it’s important when doing comparisons to use exactly the same recording chain, power supply, cabling and, possibly, consoles of similar age/wear: as time passes, and depending on how much the console has been used, its components will have worn down, which means that capacitors might now have lower capacitance, and resistors lower or higher resistance (back in the days carbon resistors were the norm because they were cheap and those didn’t hold up too well), thus altering the audio output.
When put into this context, it’s easy to see how MDFourier will be useful to measure the impact on sound that the wear had on two consoles with different age.
This is very interesting data and there are literally hundreds other ways to use MDFourier.

We’ve just barely scratched the surface of all the possibilities that MDFourier gives us, but as this article is already pretty long as it is, I’d like to conclude with a Q&A with MDFourier’s author, Artemio, to further discuss the topic of music preservation and the importance (or lack of) of finding a reference.

Q&A with Artemio:

16bap: Hi Artemio. Let me start by thanking you for your awesome work with both the 240p test suite and now MDFourier: those have been staples in troubleshooting issues, calibrating our monitors and now understanding the differences between console revisions audio-wise.
How do you feel about the whole idea of finding a reference expressed in this article? Do you think it’s a necessary step towards proper videogame music preservation or is it just a huge waste of time, like chasing ghosts, as we don’t really have a tangible, real entity we could refer to as a “reference”?

Artemio: Thank you for your kind words, it is my pleasure that the tools I crafted are useful for others.

There are many factors that do affect the choice of a reference: intentions, actual hardware performance, commercial decisions made at the time, costs, user perception, memories, etc. But as you mention in the article a reference can be an arbitrary choice with no meaning, simply a mark to help gain perspective.

It is important to understand that, and not to believe that a reference is the “correct” or “best” choice. It is just the yardstick used to compare and get meaningful information.

As a result, I’ve come to believe that the best is to offer options, and as many as possible. Because all: the intention, the measurable output, the individual experience, etc, have value. And not offering them gives a biased perspective.

An important part of this process is to specify how and why they differ to the best of our knowledge, so that when somebody tries to study the field, they’ll hopefully find a perspective that will help them in their efforts.

That doesn’t mean that the choice of a reference needs to be arbitrary. It can convey meaning and be valuable by itself. But there can be other equally viable choices that are not less important.

 

16bap: In our project, for the sake of consistence among recordings, we were forced to choose a reference and we did it by making an assumption about the composers’ intent (ie: “This is what I want the players to hear!”) and taking into account the community’s feedback on our choices over the years.
If we were to start anew, in light of the information uncovered so far thanks to MDFourier, what do you personally think would be the revision which makes the most sense in a preservation context?

Artemio: There are several choices that could make sense. It can be argued that the earliest revision Mega Drive reflects the original design intention from the hardware standpoint. However, SEGA made revisions to the audio amplifier soon enough, and kept a stable line up using the YM2612 from VA3 to VA6 which have very slight variations between them.
It can be argued these revisions corrected flaws that could have been introduced due to financial, production line constraints, provider errors or many other reasons. I have no knowledge about the real causes, but the verifiable evidence in hardware and audio signatures shows a clear evolution that reached a plateau during Model 1 revisions.

But that is valid only if the approach is trying to preserve what we perceive to be the original intention, which was not a static target. Model 2 revisions were very common, and what a lot of people experienced. Changes were big as we all know, and there is a lot of variation between its revisions. It ended up with the CDX, Nomad and even Model 3, and one could argue those were the final evolutions – and thus intentions – from the hardware developers.
This is of course pure tongue in cheek speculation, but without any solid evidence of an intention, any argument can be made.

This is one of the reasons that made me realize that the reference within MDFourier should be versatile, and give that freedom to the community. I believe that if we can document as many audio signatures as possible we can make it easier to recreate any of these hardware revisions using any reference we want. That’s why I believe relative comparisons are useful, so we can aim to recreate any documented target we desire. If you want to use your childhood Model 1 to create a filter for a playback system, it should be great to be able to do so.

It is very hard to tell what the composer intention was, as we know many of them composed their music on a completely separate system, and only shipped the sheet music and/or a recording using their own musical equipment. Then it was the job of a different person to convert that into a working driver or implementation. There are other cases where the composer created the driver and oversaw the whole process, some with an official SDK and some with hacked consoles, or even a PC-8801. But we know many of these cases as thankfully there are some interviews that help in this regard.

My point is, we always have to compromise and reach a good enough reference. And the important part is to know that and understand what it means and how it differs from other models. I am really happy there are projects that have this commendable goal and that take audio seriously. Unfortunately audio has taken a backseat in the community, due to many reasons, and I believe it is half of the experience.

 

16bap: Preservation has always been a critical mission throughout the history of humanity. If we take books as example, we first had monks painstakingly transcribing books by hand, then the movable type revolutionized this task by not only making it faster, but also less prone to human error, and finally, with the advent of computers and digital era, we are now able to digitize text and make infinite, perfect copies which, thanks to the internet, we are able to access at any time and everywhere.
Today’s technologies have enabled us to make this process not only easier and more efficient, but also, most importantly, more accurate.
Despite this, even when considering something as deceivingly simple such as a book, we’re still unable to exactly reproduce and preserve it (think about the paper’s texture, yellowing or original color, defects in the font, etc.). Yet, for most people, just having the original text will be perfectly fine although it might not convey part of the original experience or vision the author intended.
Where do we draw the line, accuracy-wise? And what’s your take on the topic of preservation as a whole?

Artemio: As you clearly point out, I currently don’t view preservation as a black and white issue but more as a spectrum.
I believe that the concept of a “perfect copy” doesn’t help in general, since it is not specific and gives the illusion that the preservation task is over, when we still have a lot to do. It would be better to understand that we can copy data and replicate that ideally within measure, but we cannot replicate analog objects with the same freedom.

The book example is great, as you mention there are elements that are easily and accurately replicable at a massive scale which can be used to distribute what is perceived as the whole contents of the work that is being preserved. But that is not good enough for many purposes, and in some cases cannot even contain the whole work as it was generated, since they are always context dependent.
Being in the situation where you can help document a particular object or behavior, I feel that aiming for preserving as much as possible, even if it seems excessive for the regular consumer, is the only responsible thing that can be done. If we have the means to achieve it, why not do it in the best way we can?

If you look at the media we produced with digital cameras just 20 years from today, you can easily laugh at the resolution and color fidelity they achieved. We most certainly will look back to our current media as tiny when compared to what we’ll get 20 years from now. And an individual can probably relate to this when browsing their old media: wouldn’t it be great to have them at a higher resolution if possible?
Now imagine that same issue for somebody trying to replicate a game 40 years from today. Wouldn’t that person want to have as much information, context and detail as possible?

In response to your question, I try to draw the line at the limit of what can be achieved. Lesser copies can be made from that highly detailed documentation for regular use. These lower detail copies are easier to replicate exactly as you describe. But a good case study is floppies or even CD-ROMs for example.
Floppy disks are analog media, and as such they need to be interpreted by the hardware that reads them in order to produce the digital data stored within them. Protection was sometimes part of the analog to digital conversion, and as such the equivalent of a “perfect copy” of the binary contents is not sufficient to reproduce the disk contents, since the unreliable analog nature or even the manufacturing process was used to check for authenticity.

In essence, one should try to document as much detail as possible.

 

16bap: As you’ve stated, as technology advances, we have better means to try and replicate carefully any kind of works.
Thanks to MDFourier we’re now seeing a huge leap forward in accuracy in the Mega Drive audio department, to the point where we have examples such as MiSTer‘s Mega Drive Core and Plogue chipsynt MD software which are so close to the real hardware that it’s indistinguishable with our own ears.
Do you think The 16-Bit Audiophile Project will soon become obsolete, as people will just playback .VGM files (which are way smaller and convenient than our own rips) with software like chipsynth MD?

Artemio: I don’t think that the 16-Bit Audiophile Project will become obsolete, and I have several reasons to believe that.

First of all, a reference recording will always be welcome when implementing new revisions of the future iterations of emulators, FPGA implementations and whatever the future holds for preservation. It will always be easier to preserve an audio file than a complete solution.

Let me elaborate. All preservation efforts rely on context, and that context must be preserved along with the solution for it to function. Such context needs knowledge when moving it along to future platforms.
It is interesting how we solve these issues. We start with a stand alone platform, composed by vintage hardware and software, that we want to replicate in a modern way. However, we naturally do this with hardware and software that are plentiful and accessible to us in the current time frame, but that might not be the case in the future. These newer platforms need an environment, that is composed of different parts such as an operating system, drivers, frame works, vendor specific languages, a maker friendly commercial environment, etc. On top of that, the implementations need specific knowledge if we want to move them forward into future systems. And the people with that knowledge, combined with the knowledge of how the vintage hardware works will reduce generation by generation.

I believe that a parallel solution to complement this is documentation. The best would be detailed text files filled with notes about how these work, without making anything obvious since these things that seem obvious to us might be context dependent and inaccessible to future generations.

High quality audio recordings from documented hardware in well documented formats also fall in this category. They provide an excellent source of the results that are to be expected of such an implementation, and a benchmark to test against. Such a recording is way easier to preserve.

You talked about “perfect copies” before, and the audio recordings fall in that category easier than any of our current implementations in software or FPGA solutions, since those require a lot more context to move forward into future platforms. What I mean is, they require active participation by a smaller and more technically skilled set of people to port to every iteration of future platforms, if we don’t want to end up with emulators or virtualization for our current solutions.

 

16bap: Thank you so much for your time. Your contributions in this Q&A have been really valuable and I hope they’ll contribute to raise awareness towards the importance of preservation of all forms of works and spark a new interest among internet communities.

Artemio: Thank you for taking the time to talk about these issues and lending me your space. I have been a huge fan of your work, and I hope the community will continue to grow and help preservation projects.

 

Further reading and links:

MDFourier complete documentation – https://junkerhq.net/MDFourier/files/mdfourier.pdf

RetroRGB interview with Artemio – https://www.youtube.com/watch?v=hTXxxVxU-7Q

An in-depth comparison of most of the known Mega Drive/Genesis models and revisions – https://www.sega-16.com/forum/showthread.php?7796-GUIDE-Telling-apart-good-Genesis-1s-and-Genesis-2s-from-bad-ones

Artemio’s Twitter – https://twitter.com/Artemio

Closing note: as we speak, MDFourier is being very actively developed and will have support for many more platforms other than Mega Drive/Genesis, so make sure to follow Artemio on Twitter or check the MDFourier’s webpage regularly to stay updated!

 

A new Community Release has arrived, it’s Eliminate Down by Katcho!

Thanks to Klatcho for his kind contribution!

 

 

Lilmattere is at it again, this time with Dangerous Seed!

Thanks again to our contributor, this is his third release here and hopefully more will come in the future.

I’ll take this opportunity to remember that anyone can contribute to our project as long as you’ll follow our guidelines. Just send us a message through our forums, Facebook page or Twitter!

 

Hello everyone, and welcome back to a new community release!

This time is Earthworm Jim, ripped by our community member Lilmattere who also did Streets of Rage 3 recently!

A big thank you to Lilmattere for his recent efforts and remember that anyone can contribute by sending in their recordings as far as they are closely following our guidelines.

Stay tuned on our Facebook page because as Christmas approach, I’ll finally have some free time to dedicate to the project and I need your input on deciding what to do next. There will be a poll where you’ll be able to vote what to do next.

Thanks again for sticking with us and please keep giving us feedback to improve our project!

Click on the image to go to the download page

Hello everyone and welcome to a new milestone in our project, our first Community Release which is none other than one of the most requested game we had lately: Streets of Rage 3!

For those who’ve missed our previous posts and are wondering what a “Community Release” is: those are releases made by our community following our very strict guidelines (which you can read here) which ensure that the resulting tracks follow our very high quality and accuracy standards.

This release is kind of a particular one because I’ve been in talks with its author, Lilmattere, for quite a long time as he dedicated lots of time in trying to squeeze the best sound possible out of his Mega Drive.

The last word on our first community release will, of course, be all of you, so make sure to let us hear your feedback and let us know how we can improve Community Releases in any way: we’re always looking for ways to improve not just on audio quality and accuracy, but also bringing the knowledge to do proper rips to our own community and help us out in our mission.

Hope you enjoy our first community release and, as already said, please make sure to report any issues either in our forums in the release’s own thread or through our Facebook or Twitter page so we can notify the author and get the release fixed ASAP if needed.

Happy listening!

Hi everyone,

this is a turning point in the project and although there are many, MANY important topics to discuss, I feel like this is the most important of all.

As you may have noticed, we have already accepted community releases in the past (for example from Roareye – I had sent my him old recording equipment to record 32x and Amiga games) and now I’ve decided it’s time to open the project up to external contributions.

One important thing: although those releases will be shared through our website and with our “label” on it (which has always been the hallmark of utmost quality and accuracy), those will be clearly labeled as “Community Release” to distinguish them from our own releases.
Hopefully this won’t be received as a form of discrimination, but as we still don’t have a group of people dedicated to closely listen to the contributions and decide whether to accept or reject them, we don’t want to mess it up.

Speaking of which, I really need a group of people to listen to the contributions to make sure they adhere to our (very) high standards. This means that there will be something like “The Golden Ears Committee” who’ll be able to mainly discern bad rips and judge the recording quality.

I don’t have the time to follow all of this, I need help keeping this project rolling.

To sum it up: right now everyone can contribute and there won’t be any kind of quality check on the contributions *BUT* all of the contributions will have to adhere to some rules. After posting this, I’ll be making a new page in the website (and axing the “Articles” section which, unfortunately, never really took off) named “Contribute” where you’ll find the guidelines which you MUST follow if you want your contribution to make it into our releases.
As of now, only Mega Drive/Genesis contributions will be accepted. This might change in the future, but one rule will always apply: no matter what: NO NINTENDO GAMES. And by this I don’t mean strictly Nintendo consoles, but whatever games were made or published directly by Nintendo (think super mario, zelda, etc…). Nintendo has always been extremely hostile to those kind of projects and I don’t want to see this 7 year project fall to a Cease and Desist case.

This is all happening very quickly, so there might be changes over time, it’s all very unstable right now but since I have some spare time, I want to do this now and, eventually, revise it at a later time.

Before starting sending in your rips, please read the guidelines,

Thanks for sticking with us and stay tuned, hopefully I’ll manage to squeeze another release before getting back to work!