As you can see from my other post (http://chipmusic.org/forums/topic/16824 … m-samples/), I have become fascinated with PCM samples on the Game Boy and Game Boy Color. However, that doesn't mean that samples from other old consoles are interesting as well (although much less so), such as the NES, SNES, and SEGA consoles before the Saturn.
I want to rip samples from many of these games. Most people use Audacity to do so by using its "Import Raw Data" function at an 8-bit unsigned PCM, but they don't realize that there's a MAJOR problem with this method.
You see, Audacity, and other audio editors, only go down to 8-bit. While it technically CAN read 4-bit samples at 8-bit, it either has to play at the original frequency but double speed and an octave higher, or at the right speed and pitch, but in even worse quality than in-game (e.g. it's supposed to be at 8000hz, but imported as 4000hz), when it should be the exact opposite. Most people do the second one, and don't notice the glaring flaw, probably because it sounds so degraded in-game. I mean, you call THIS "restored"? http://youtube.com/watch?v=wFwbfN18x0I
A few months ago, I found this Python script:
http://forums.nesdev.com/viewtopic.php?t=6557 It solves the problem PERFECTLY for NES raw audio and GB/GBC, but it doesn't work with anything else. In fact, inside the script, it says:
"Limitations: Master System/Game Gear nonlinear samples are not
supported."
The lack of a PROPER way to extract 4-bit samples from SEGA Master System, Game Gear, Genesis, and CD games is really irratating me. There are only a few Genesis games that actually use 8-bit samples (most games use 4-bit non-linear), such as the original Sonic the Hedgehog, Earthworm Jim 2 (NOT the first one), and Comix Zone. I know this because of the frequency in Audacity.
I have also searched online for help, and I found two forums (http://stackoverflow.com/questions/2059014/converting-raw-audio-data-to-wav-with-scripting, and http://stackoverflow.com/questions/2600 … t-format), but neither of them give an answer.
Can someone make a program that will import unsigned 4-bit audio correctly, so I can PROPERLY extract the samples from these SEGA consoles?
The program must follow the following rules:
- Must run on Windows 8.1 64-bit (unless it's a 16-bit MS-DOS program, where I can run it with DOSbox).
- Must include the source code if not a Python script.
- Must not be a Perl script.
- Must allow editable frequency.
Thank you.
- Must not be a Perl script.
Lol!
This sounds like something I could look into. But the comment in the source code of that script is a dead giveaway, from one word: "nonlinear". Nothing would stop you from extracting the sound data if you know the format of it and where it's located, but non-linear means that the amplitude steps are not evenly spaced. In other words, you need to know the conversion curve of the SMS/GG DAC in order to restore the original audio from the sample data. This is all fine and well, but requires additional research on the hardware if it's not already documented somewhere. And likewise, it's impossible to know the correct sample playback rate without figuring out what the ROM is actually doing.
And yes, that Cannon fodder sample playback is horrible. Thank you for reminding me of this. I've now uploaded a video with the audio reconstructed from a ROM rip, in case you are interested.
https://www.youtube.com/watch?v=dKjTCSikTus
However, the Cannon Fodder audio as played back by the ROM always reminded of a version of Forever Young that V/Vm did for a Playstation commercial that never got aired. My own favorite theory is that they left the audio playback that way as some sort of homage to that commercial, although it's more likely that that's not the case.
https://www.youtube.com/watch?v=MyuvhcvVxD8
Update: I just found out that the script actually worked with a Game Gear game I tried (Krusty's Fun House). However, I had no avail with another game, and any Genesis games I tried, indicating they are nonlinear.
"This sounds like something I could look into. But the comment in the source code of that script is a dead giveaway, from one word: "nonlinear". Nothing would stop you from extracting the sound data if you know the format of it and where it's located, but non-linear means that the amplitude steps are not evenly spaced. In other words, you need to know the conversion curve of the SMS/GG DAC in order to restore the original audio from the sample data. This is all fine and well, but requires additional research on the hardware if it's not already documented somewhere."
What I was asking for was a program that would function like the "Import Raw Data" feature in Audacity (which, as I said, can read the data from the games I want just fine, but can't get to the right bitrate), except importing unsigned 4-bit. It's open-source, so maybe you could use code from that, but modified to import 4-bit. In fact, the program could be a plugin for Audacity.
"And likewise, it's impossible to know the correct sample playback rate without figuring out what the ROM is actually doing."
That wouldn't be a problem - you could rip the ROM at a chosen frequency. I stated an editable frequency in the requirements.
"And yes, that Cannon fodder sample playback is horrible. Thank you for reminding me of this. I've now uploaded a video with the audio reconstructed from a ROM rip, in case you are interested."
Thank you very much for that!
SMS and GG samples are played on the 76489 PSG, set all 3 channels Tone=$00 and feeding the 4bit Vol regs with the sample data. So while there is a little bit of a de facto standard; being software controlled, leaves the methods up to the programmer.
At SMS Power is a good doc on the 76489, http://www.smspower.org/Development/SN7 … MakesSound
Yogi
I figured it out! Apparently Genesis games actually do use 8-bit samples, but I was always setting it at "Default endianess", when it should be "No endianess", so it probably usually guessed the wrong endianess. And the Master System game I tried with the Python script actually does seem to work, as I looked more closely and I could find the samples I was looking for. It still has the frequency problem, but it might also be an endianess issue, as it's set to "Big endian". Now my sample-ripping crisis has finally been solved! 