Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
9 years in videogame music preservation – Part IV
Link to Part III

There's nothing worse than trying to achieve a goal without the right tools. It makes the whole experience absolutely terrible and frustrating and the end result is seldom the best.

This is when Artemio (developer of the famous 240p Test Suite) contacted me on Twitter saying he had something he has been working on which could interest me.
The document he sent me titled MDFourier would be the beginning of a real revolution not just for our project, but for the entire world of videogame preservation, to the point were we wrote an entire article explaining what MDFourier is and how we could use it, featuring Artemio himself discussing the importance of the preservation of all forms of arts.

Thanks to MDFourier we could finally achieve what was previously unthinkable: perfect timing.
By now everyone knows we've been using VGMs which have their own shares of problems and limitations, but thanks to the valiant efforts of Project2612 and DeadFish Shitware, we were able to partially overcome them.
Or so we thought. Unfortunately MDFourier also uncovered a terrible truth: to put it short, almost all the VGMs in Project2612 which were ripped with KEGA (without getting too technical) had wrong timing.
We luckily managed to get around this (even without knowing it!) at the time because the DeadFish VGM Player had a feature to scale the playback speed to any desired amount, but this is truly devastating news because soon we'll have to make a very difficult decision on whether to re-rip (most of) the entire Project2612 library or just let them be.
As I stated in the previous article, our project isn't about just recording from real hardware anymore, it's now about videogame music preservation and we need to do this in the most accurate way possible.

With MDFourier and the incredibly skilled community behind this, we were also able to make another huge discovery.
In the MDFourier article linked above, we discussed about what Mega Drive revision we should have used and we made some assumptions without any sort of proof.
Now, by sheer luck, we know that we've nailed it.
The fundamental specification about choosing a Mega Drive (which at the time of the article we completely missed) is that it should be able to play back correctly all the games available* and there are some games which won't be played back correctly on Mega Drive VA3 and newer because SEGA decided to change the pre-amplification stage in VA3 making it a fair bit louder than the one in VA0-1-2.
This has lead to varying degrees of distortion on some tracks but, most glaringly, on Shadow of the Beast: it completely wrecked the entire game soundtrack, but on Mega Drive VA0-1-2 it plays absolutely fine without any distortion at all.
Another example of this is the Stage Clear track on Castlevania Bloodlines.

*Yes, I know, there are some games which were made specifically for the YM3438 and we'll have to wrap our heads around this. We'll need to make some very through research to decide what Mega Drive revision we should use for them. Most likely one of the newer Mega Drive Model 1s with the discrete YM3438 but don't take my word on it.

So, you might ask, after all of this, where are we standing now?
In a pretty thrilling place!
We now have a new VGM logger, courtesy of blast'em, a well known cycle accurate emulator, which has been developed hand in hand with us and Project2612 and it's absolutely perfect.
We won't have to fear any kind of inaccuracies game-wise and VGM timing-wise anymore: we tested it thoroughly and it passed all the tests with flying marks.

So we're all set up but there's one very big issue: we'll have to log all the VGMs again and, ideally, re-record all our releases from scratch.

This is something which is really disheartening but to live up to our goal, I feel like this is a necessary step. The biggest issue is that we can't do this alone: it is just too much.

As of today, we're still discussing with Project2612 the best course of action and what we're going to do in the future, which is highly uncertain, as is the future of our project since it is tightly wired to Project2612.

Since this article is already pretty long as it is, there's going to be a last part in this series which will focus on the future of our project and, most likely, a call to arms to our community (and others') because we're going to need all the help possible if we want to get through this.

Stay tuned as we'll try to outline what we're going to need and try to lay down some basic guidelines on how you can contribute to the future of our project.

(you can read the original article here: 9 years in videogame music preservation – Part IV )
I find this part interesting...

Quote:We now have a new VGM logger, courtesy of blast'em, a well known cycle accurate emulator, which has been developed hand in hand with us and Project2612 and it's absolutely perfect.

Blast'em is kind of awesome as a project, I've used it for quite a bit of games to just see it's accuracy when compared to the MiSTer FPGA's Genesis core, and it's basically the best on software emulation from what I've seen.

I'm looking forward to the new methods for contributing as I'm planning on contributing heavily since it's not fair to put this on one person. I learned and became proficient in soldering in part because I wanted to contribute to this project Smile

I also wonder why, if as has been mentioned, the MiSTer Genesis core could not just be used for this instead? I still need to get an audio interface card that supports optical audio in that is decent, but I was planning on doing something similar but on the MiSTer since dumping would in theory be easier there. With a USB cable through usb Blaster I think people are able to collect the audio data raw as well, but I'm not as familiar with that. Part of the reason I want to contribute is to do inverse comparisons with the MiSTer output and see if any random samples turn up inaccuracies too.

Thank you so much for all the updates!
(06-11-2020, 07:24 PM)aberu Wrote: I find this part interesting...

Quote:We now have a new VGM logger, courtesy of blast'em, a well known cycle accurate emulator, which has been developed hand in hand with us and Project2612 and it's absolutely perfect.

I also wonder why, if as has been mentioned, the MiSTer Genesis core could not just be used for this instead?

Because even if it's very very close to original hardware, it still has some differences measured with MDFourier and our goal is using purely original hardware because everything which is being conveyed into the audio signal (yes, that includes a certain amount of noise generated by the console circuitry itself and the tiny little variation in timing due to how the oscillator works – mind you, we're talking of differences of ~0.005ms at best ) is relevant for preservation purposes.

Think of our work as some kind of documentation in audio form for generations to come: we don't want perfection in the strict meaning of the term itself: we want to be as accurate as possible towards what an original Mega Drive spits out of its audio outputs and that even includes the small inaccuracies the Mega Drive itself has.
If the Mega Drive has any kind of issues or inaccuracies, we need to accurately record them as well.

The MiSTer is able to model a "perfect" Mega Drive which is not what we're looking after.

Actually, it's thanks to projects such as ours and MDFourier that the MiSTer has been able to have a reference. In fact, the Mega Drive MiSTer core's audio output has been modeled after our releases Smile

EDIT: Jotego's one at least, I'm not aware of how many Mega Drive cores are out there for the MiSTer.
Vi veri veniversum vivus vici

Just for those unaware of the history and contributions, putting this out there for those curious:

The Mega Drive core for the MiSTer FPGA project is technically a clone of Gregory Estrade's (aka Torlus) core from 2010-2013 ( - Jotego (Jose Tejada) however contributed his JT12 module (which was integrated into fpgagen way later in 2019, afterwards) (, which are the sound chip cores developed for arcade cabinets which shared the same Yamaha chips basically, with very slight inaccuracies at the time he added them. Since then it's near perfect, there was a problem with Streets of Rage 2 about a year back, and there is a current potential slowdown issue with Daisenpuu/Twin Hawk that I'm not sure is a problem or not yet.

Indeed, a testament to how amazing Jotego's work has been on the sound chip was part of the reason for your having been made aware that VGM format the 16BAP had been using has timing issues (, so the continuous improvement you are making is awesome! The SOR2 problem also seems to be the result (in part) of the filter variance required to match all major revisions. Currently there isn't much of an inaccuracy in the most prominent example found over the past year comparing reference audio via MDFourier with the Genesis core using Jotego's JT12 module, which is kind of amazing.
Thanks for the detailed post, hopefully it'll be read by other people although I'm afraid those forums have become a bit of a wasteland.

Also of note that those rounding errors I was speaking of in Github are now being handled by a very good algorithm in the blast'em logger and have become so small to be negligible.
Vi veri veniversum vivus vici
I plan on getting a flash cart for my VA6 Genesis (I know the whole pre-amp situation and I'm going to mod my system accordingly although my cutoff frequency is going to be 3.4khz which I believe is what SEGA originally intended instead of the 3.39khz of the VA0-2 models or the 3.38khz that's generally accepted as the standard amongst Genesis/Mega Drive enthusiast and purists) and start contributing straight from the roms themselves, and the added benefit of that is I can essentially burn Game genie codes into the rom itself and not have to worry about the interference from an actual game genie, and I've figured out the best way to do it for games with no sound test, instead of disabling SFX codes why not use codes that redirect songs to other places, for example and I actually have this one, in Puggsy with the GG code DT2A-JACT I can change the music for the first Beach stage to the music for the first boss Polly Pirate instead which in theory should get around the SFX issue assuming you can find a spot that's completely silent in terms of SFX.

I'll be using a T.C. electronic desktop konnekt 6 (I actually bought this before you guys changed to the Yamaha Steinberg MR816X as I had planned on contributing sooner, I'll still use it) I need to know how to mod a Firewire cable to remove the power line to prevent any interference either that or I buy one from someone who'd be willing to sell me one, the person who sold me the konnekt 6 also included a firewire to thunderbolt adapter should I use a thunderbolt card instead of firewire (I'm still trying to decide which would be best)? All that's left aside from that is to mod my system.
The Desktop Konnekt 6 is a fantastic device, make sure you set the recording levels on the interface correctly though, you have two knobs to set it.

Also, we now strongly discourage using direct rips from game sound tests because we've measured an absurd amount of noise produced from the VDP and the CPU itself.

I don't know if/how this is doable, but if you're set in recording from the games' sound test, then try doing a little research to try and find how to set certain registers manually.

The ones we're interested in are the VDP registers 0x00, bit 1 (needs to be set to 1) and register 0x0C, bit 5 (needs to be set to 1 as well). When you set those registers you're completely shutting down the VDP and you're gonna get a huge drop in noise.

Also, if you're handy with cheat engines and hacking, you might want to help us in the process of re-logging the VGMs.

I'll make a new post soon about this which will tell where are we standing now and what we're going to need in the future to go on.

About your interface: get a Firewire card if possible, instead of a thunberbolt one. If you want to cut the power out of the cable, just cut the white cable inside the firewire cord. Bear in mind there's not a standard color coding, so always do some research:
Vi veri veniversum vivus vici

Forum Jump: