A chance to update our logo and album cover art

Hi everyone,

one of our followers which works as a graphic designer has graciously offered us the opportunity to have a new unique logo made for our project and redesign our album and youtube cover art.

As with most of the decisions made in the project, you, the community, play a very important role in it.
Let’s start with a bit of lore behind what we’ve been using for the last 8 years as logo and cover art.

When this whole thing started, my idea was to just make proper recordings for the “canon” Sonic games and it made sense to me to use the Sonic & Knuckles logo which I’ve always loved and thought of as pretty cool.
As for the album and youtube art, it was the work of our original graphic designer, Truepack, that took it upon himself to design something reminiscent of the game boxes and adapt it to what would be a CD jewel box cover art.
I loved the idea and, at that time, I never thought it would have blown up like this, I thought it was just a 2-3 games work and nobody would notice it, but here we are.

The main thing I wanted to discuss is that the S&K logo, while definitely being cool, doesn’t really make sense anymore and it’s not something which reminds of “audiophile grade recordings”. So I thought that something more appropriate could be made to make our project and its goal instantly recognizable.

The big issue I see in doing so, is that I believe that by now the bond between our project and the S&K logo has become unbreakable since we’ve been using it for 8 years: I swear that everytime someone looks at the S&K logo immediately thinks of our project and viceversa, we’ve become synonymous one with each other.
I’m afraid that by suddenly changing the logo to something else we might disorient people who’ve become accustomed to our old avatar.

So it’s entirely up to you to decide what to do: bear in mind that we already have releases of other, non-SEGA consoles and will definitely make more in the future.

I’ll try to put some kind of voting system up on both Facebook and Twitter, plus you can make your voice heard in our forums and Discord channel. Every opinion matters.

In case of a draw or being it very close, I’ll just play it safe and decide to just leave things as they are now.

Thank you for following us so far and stay tuned for newer developments and releases!

Click here to comment

Devil Crush MD released!

Click on the image to go to the download page

 

While we’re still figuring out the best course of action before we start making our releases again, our community has been working hard!

Katcho comes back with another contribution, Devil Crush MD!

Thank you so much for your continued efforts and we hope to see more from you in the future!

Stay tuned to our social pages as we have more community releases ready and we’ll be rolling them out weekly!

Click here to comment

A call to arms

Link to previous part

We are (almost) set up to start archiving games again.
To quickly recap where we’re standing now:

  • We have a new accurate VGM logger in the blast’em emulator
  • We have an updated Deadfish hardware VGM Player which is able to completely disable the VDP (Video Processor) to minimize noise
  • Thanks to MDFourier, we now have the possibility of fine tuning the Deadfish VGM Player to achieve perfect timing
  • And we are working on a new workflow to make the recording process easier and faster

So, what’s missing?

To put it short: we need people to first check and then, where necessary, re-log VGMs.
Thankfully, some VGMs are already ok due to how the sound driver in some packs worked, but others, unfortunately, are off.
This means that at the beginning, we’ll be content just by compiling a list of games that are ok and others that need to be logged from scratch.

After that, if you thought that the process of recording and tagging files was long and boring, think again: VGM logging takes that boredom to an entirely new level.

I’ll briefly explain in very broad terms what’s needed to log a VGM, to give you an idea of the process:

  • Load the game’s ROM on blast’em
  • Hope to god that it has a sound test or a way to play back the music without sound effects
  • If it doesn’t, there’s a very big thread on Project2612 with all kind of hacks to let you play all the music in the game (even those hidden or unused!) without having to go through the whole game and without any SFX playing
  • You have to log the VGM and pay lots of attention to the music: the process of logging is very similar to the process of recording, but here you have to make sure that you record at least an entire loop (if the song is meant to loop)
  • Now, here comes the critical part: you have to trim the VGM you just logged so that it loops perfectly. We have a guide in the VGMrips Wiki about how this is done (link 1, link 2)
  • Finally, you have to add the GD3 tags (similar to the metatags you find in FLAC/MP3) to the tracks

Yes, this is incredibly time consuming and this is why we need help.

We have a Discord channel which is being graciously hosted on the Project2612 server and it’s pretty convenient because the server has lots of knowledgeable people how’ll be able to help you out, should you need it, to move your first steps into logging VGMs and hacking games to play the music back without SFX (although the guides I’ve linked above are pretty exhaustive).

To avoid getting the server destroyed by bots, the invite links will be shared through our Facebook and Twitter pages (or you can send me a Private Message in the forums).

If you were thinking about contributing, at this point I’d much rather have your efforts concentrated on the VGM part and I’ll be back to the recording process since it has caused much confusion among several contributors.
Plus, you won’t need any kind of recording equipment or buy anything in order to log VGMs: you just need a PC.
At this stage, even just checking the VGMs on Project2612 to see if they need to be re-logged would be really helpful.
Still, any kind of contribution will be more than welcome, as long as it follows our guidelines.

This is where we are and, again, this is absolutely too much for me alone to handle.

If you have any kind of question or doubt, please reach out via Facebook, Twitter, Forums or Discord and remember that while Discord might be great to handle instant communication, it’s pretty terrible for storing and finding information (which is why our Forums will still be left open).

Thanks everyone for getting through all those articles, I hope you’ve enjoyed them and I look forward getting back to archiving game music soon.

Click here to comment

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 it, 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.

Click here to comment

9 years in videogame music preservation – Part III

Link to Part II

What happens when you go beyond what is humanly possible to hear, when no matter how hard you try, you can’t tell a difference?
Well, for most of us we’d say “that’s it, it’s good enough”.
And sure enough, there would always be cases when that “good” wouldn’t cut it.

After 7 years I started getting messages from emulator developers (both software and FPGA implementations) asking if they could use our work to fine tune their emulators. We were super stoked to know that we had reached a point where people would start using our releases for other purposes than just listening to the music.
Bear in mind that, until then, emulators never really took too much interest in shaping the audio output to try and get the sound as close to a real Mega Drive: they were happy enough with having the Yamaha YM2612 and PSG perfectly emulated, ignoring all the circuitry used in the audio output section of the console. This brought results which were pretty far from what a real Mega Drive sounded.

Up until last year we were still using very primitive tools (besides our ears – and our community’s) to understand if our work was accurate enough and it served us well so far.
The issue arose when we started to realize that the goal of the project was shifting once again.
All we ever wanted was to just record music from original hardware, trying to stay as close as possible to the original sound signature, recording using the most transparent equipment we could afford and let people enjoy our work.

When I started receiving those messages about our work being used in contexts where even a fraction of microsecond could make a difference I really wanted a more advanced tool to understand if we were doing things properly.
It became clear that our project wasn’t just about recording music as good as possible. We weren’t sharing music for our community’s pleasure.
We were doing something much more important: we were archiving Mega Drive music for preservation.

Although this seems a bit like an apocalyptic scenario, one day all our beloved old consoles might start failing to the point where they can’t be repaired anymore. Sure, emulators will still likely be around, but there wouldn’t be what we started referring to as a “reference”, a good, proper recording from original hardware.
A proper recording in an open source format such as FLAC will always be available to anyone and can be played back on any OS and architecture, even future ones which don’t exist today, because the source code of FLAC is publicly available and anyone can compile it and make a new player for a new OS or CPU.
And since our work has received lots of praise and seen use in several contexts, we just can’t screw this up anymore, we have to do things properly and with the right tools.

This is when everything changed again thanks to a new, incredible tool that suddenly became available, and the upcoming part will finally unveil the actual state of this project, what we’ve been doing so far and what’s going to happen in the future.

Hope you’ve enjoyed this small series of articles so far, stay tuned for the final part which is coming in the following days!

Click here to comment

9 years in videogame music preservation – Part II

Link to Part I

How big of an impact can a 0.951% difference in speed have on the listener?

For a long time, we couldn’t really tell, that’s why we kept on using our modded PAL Mega Drive with region switch mod and swapped oscillator.
And yet… after a couple years of activity, people have started telling me they could hear that something was off in our releases and the best description they could give is that some instruments had wrong pitch.
They were, of course, right, because changing the speed at which a track plays means you end up changing the pitch as well.
At the 16-bit Audiohphile Project we could never tell this difference, but once more and more people started pointing this out, we just couldn’t ignore it anymore and we had to do some through investigation to understand what was wrong.

Mind you, those were times where something like MDFourier didn’t exist so we had to use our ears and listen through different tracks over and over again.
Eventually, it became clear that there was indeed a difference which, once you noticed it, you couldn’t just stop noticing it and you could hear it all over the work we’ve done.
At the time we were releasing games at full steam so we had a pretty substantial library of games which had to be ripped again.

This was really an eye opener for me: up until that moment, my goal was just to share Mega Drive soundtracks recorded from original hardware in the best way possible, but it became evident that what I considered “best” wasn’t good enough for our community and that’s when our project had its first big change in scope: it wasn’t anymore about myself sharing my recordings, it was about listening our community and improving over and over again to meet their (very!) high expectations.

If there was something which our community could hear which was wrong, it was time to step it up.
So I decided to do lots of research and eventually came up with using an early Japanese Mega Drive I , revision VA1 which needed a fix due to SEGA making an error in its output stage.
This wouldn’t have been possible without the help of Ace which wrote an exceptional thread in the Sega-16 forums about all the different revisions of Mega Drives and the fixes needed for each one.

And so our adventure continued and we had to introduce the concept of “Remasters” which were our old releases re-recorded from scratch with the new hardware.

You might think this would be the end of the story (and it could have been indeed) but our project managed to draw the attention of another group of people that I never thought they would use our material for their own work and this would eventually lead us into re-thinking everything we did up until then… again.

To be continued…

Click here to comment