[Tamkis]

If one looks hard enough in the E&RE forums, one can find that many members have ripped the DAC/PCM/PWM samples from various Sonic games into standard .wav files, for use in trackers/sequencers and other things. Such Sonic games include

Sonic 1
Sonic 2B/F
Sonic 3 and its variants
Knuckles Chaotix (PWM)

One such classic Sonic game that hasn't had its samples ripped correctly from yet is the elusive Sonic CD. Perfectly timed with the re-release of Sonic CD to modern consoles via ports, I have decided to rip these samples from Sonic CD myself, with the highest-possible sound quality. This project is called SCDPSR, or "Sonic CD PCM Sound Ripping/Research".
-------------------------

Research:


Sonic CD and its betas (510, 712, and 920) store some of its music and samples into a raw type of PCM bank file, instead of in a streaming CD-DA/mp3 audio file.

Contents of the PCM files:

510 Beta:
The 510 beta only has one PCM file, called PCM000.bin, which is used for the SEGA sfx. There might be other PCM samples hidden in other files...

930 Beta and Final:
Sonic CD 930 and Sonic CD final probably have identical PCM files, used for the past music and its SMPS-PCM samples; these files are labeled as SNCBNKnB.bin, where "n" is the zone number. They both also have 2 additional files, labeled SNCBNKB1 and SNCBNKB2, theorized to be for unused loops from the Jap OST's Boss musics. Both SNCBNKB files are leftovers from Sonic CD 720.

The order of the samples are as follows:
Unique samples (samples unique to the bank)
Global samples (samples that are in all SNCBNK files, e.g. "Future", "Past", "Alright!")
Level specific samples (samples that are used as level sfx, such as the bubble break sfx in CCZ)


720 Beta:
Sonic CD 720, on the other hand, not only has the PCM files for the past and bosses, but also for every other time period for each Round. These files are labeled SNCBNKn$, where n is the Round number, and $ is a letter representing the time zone. All of the non-past PCM files are theorized to have unused loops for the Jap OST.

The order of the samples are as follows:
Unique samples
Global Samples Pt1 ("Future", "Past")
Level specific samples (usually in reverse order from Sonic CD FINAL)
Global samples Pt 2 ("Alright!", "I'm outta here!", "Yes!", "Yeah!")

SNCBNKB1 & SNCBNKB2 follow the order of Sonic CD FINAL


List of global samples:
Future
Past
Alright
I'm outta Here
Yes
Yeah


List of level specific samples:
Sneeze/Mech thump?
Bumper
Glass/Ice
Amy Love
Amy Scream


Pointer information
Much of the pointer information for the SNCBNK files came from the SCHG's Music Hacking Guide. Kudos to whoever wrote that (Tweaker?) ! The first "pointer" in the PCM table actually indicates how many PCM samples are in the SNCBNK file. Each pointer (except for the last) in the PCM table actually points to another 32-bit pointer, which then points to the starting location of the PCM sample. The last pointer is a direct pointer to the starting location of the first PCM sample. I will eventually add all of this information to the SCHG.

------------------

Ripping:

Using the pointer information from the SCHG Music Hacking Guide, I extracted each PCM sample into separate files. Each file was converted into a Wave file by putting it into a program called Snatcher PCM2Wav, which can be found here. This program, originally used for converting PCM files from the Sega CD game "Snatcher" into Wave files, works well for many other Sega CD games. Unlike another similar program, called Lunar PCM2Wav, Snatcher PCM2Wav usually converts the samples to the highest-quality Wave file possible. Lunar PCM2Wav was originally used for converting PCM files from the Sega CD game "Lunar 2: Eternal Blue", but at a lower quality than Snatcher PCM2Wav usually does. Unlike Snatcher PCM2Wav, Lunar PCM2Wav can convert the input PCM file into any valid 2-digit Khz frequency (e.g. 16khz). PCM2Wav can be downloaded here. Both have their pros & cons; nevertheless, both are good to use.

------------------

Download:

The following download contains PCM sample rips from Sonic CD. Most rips are perfect, while others are not. Please read the included readme! Currently, only sample rips from Sonic CD FINAL are included in this version (V0.25). Future rips will include Sonic CD 510 beta and Sonic CD 712 Beta. Sonic CD 920 beta rips might NOT be included, if the SNCBNK files are exactly the same as Sonic CD FINAL.

Download!
------------------

More info about SMPS-PCM files:
Spritesmind
Segaxtreme
Devster
------------------

Credits:

Andlabs - Info about SMPS-PCM (see the above links)
Contributors of the SCHG MHG
et. al. (see the readme)
------------------

EOF EOP

[Neo]

I appreciate the effort, but I still don't get why the RAR you posted is half filled with shortcuts.

Anyway, I don't know if the format contains information about the sampling rate, because it's all over the place. I just listened to all the unused clips from the 712 prototype, and worked out the intended sampling rate by ear:

Palmtree Panic:
SNCBNK1A (Present) - 24000 Hz
SNCBNK1C (Good Future) - 16000 Hz
SNCBNK1D (Bad Future) - 16000 Hz

Collision Chaos:
SNCBNK3A (Present) - 16000 Hz
SNCBNK3C (Good Future) - 16000 Hz
SNCBNK3D (Bad Future) - 16000 Hz

Tidal Tempest:
SNCBNK4A (Present) - 22050 Hz
SNCBNK4C (Good Future) - 24000 Hz
SNCBNK4D (Bad Future) - 24000 Hz

Quartz Quadrant:
SNCBNK5A (Present) - 22050 Hz
SNCBNK5C (Good Future) - 22050 Hz
SNCBNK5D (Bad Future) - 24000 Hz

Wacky Workbench:
SNCBNK6A (Present) - 22050 Hz
SNCBNK6C (Good Future) - 24000 Hz
SNCBNK6D (Bad Future) - 24000 Hz

Stardust Speedway:
SNCBNK7A (Present) - 22050 Hz
SNCBNK7C (Good Future) - 24000 Hz
SNCBNK7D (Bad Future) - 24000 Hz

Metallic Madness:
SNCBNK8A (Present) - 24000 Hz
SNCBNK8C (Good Future) - 24000 Hz
SNCBNK8D (Bad Future) - 16000 Hz

SNCBNKB1 (Boss) - 22050 Hz
SNCBNKB2 (Final Boss) - 16000 Hz

As a bonus, the SEGA chant from the 510 prototype is at 12000 Hz.

[Tamkis]

Neo, on 05 November 2011 - 01:27 PM, said:

I appreciate the effort, but I still don't get why the RAR you posted is half filled with shortcuts.

The shortcuts are there to show that those samples are one of the shared samples (e.g. "Yes!" and Amy Love). I did that to save space, instead of making putting, say, the "future" sfx in each folder. More for personal use than anything...

Quote

Anyway, I don't know if the format contains information about the sampling rate, because it's all over the place.

Maybe in the header of the PCM samples there might be a sampling rate indicator. How else would the Sega CD know how to properly play the files with different sampling rates correctly? I'll look into this

Quote

I just listened to all the unused clips from the 712 prototype, and worked out the intended sampling rate by ear:


Palmtree Panic:
SNCBNK1A (Present) - 24000 Hz
SNCBNK1C (Good Future) - 16000 Hz
SNCBNK1D (Bad Future) - 16000 Hz

Collision Chaos:
SNCBNK3A (Present) - 16000 Hz
SNCBNK3C (Good Future) - 16000 Hz
SNCBNK3D (Bad Future) - 16000 Hz

Tidal Tempest:
SNCBNK4A (Present) - 22050 Hz
SNCBNK4C (Good Future) - 24000 Hz
SNCBNK4D (Bad Future) - 24000 Hz

Quartz Quadrant:
SNCBNK5A (Present) - 22050 Hz
SNCBNK5C (Good Future) - 22050 Hz
SNCBNK5D (Bad Future) - 24000 Hz

Wacky Workbench:
SNCBNK6A (Present) - 22050 Hz
SNCBNK6C (Good Future) - 24000 Hz
SNCBNK6D (Bad Future) - 24000 Hz

Stardust Speedway:
SNCBNK7A (Present) - 22050 Hz
SNCBNK7C (Good Future) - 24000 Hz
SNCBNK7D (Bad Future) - 24000 Hz

Metallic Madness:
SNCBNK8A (Present) - 24000 Hz
SNCBNK8C (Good Future) - 24000 Hz
SNCBNK8D (Bad Future) - 16000 Hz

SNCBNKB1 (Boss) - 22050 Hz
SNCBNKB2 (Final Boss) - 16000 Hz

As a bonus, the SEGA chant from the 510 prototype is at 12000 Hz.

I knew/guessed that the SEGA chant from the 510 prototype was a different frequency, since almost every other Sonic game iirc uses a similar frequency. But I didn't know that the non-Past SNCBNKs from 712 had different frequencies! That might be problematic for trying to get HQ rips from the 712 beta.

As quoted from the manual of Snatcher PCM2Wav

Quote

The full resolution is decoded by
SPCM2WAV, at 16 kilohertz (also mono and 8 bits). As you might guess, those
extra kilohertz make a world of difference!

Since in Lunar PCM2Wav, you can change the output frequency, I tried converting some of those files with the frequency you suggested, but the outputted wav files still sounded like geezers or chipmunks. Interesting. Luckily the source (in C) is included with Snatcher PCM2Wav. Maybe somebody can modify the program so that different input frequencies can be outputted correctly. I don't remember much C programming, nor do I understand the contents of the source, even with what I know of C.

[Neo]

Tamkis, on 05 November 2011 - 02:44 PM, said:

How else would the Sega CD know how to properly play the files with different sampling rates correctly?

The sampling rate could be hardcoded on a sample-by-sample basis.

Tamkis, on 05 November 2011 - 02:44 PM, said:

I knew/guessed that the SEGA chant from the 510 prototype was a different frequency, since almost every other Sonic game iirc uses a similar frequency. But I didn't know that the non-Past SNCBNKs from 712 had different frequencies! That might be problematic for trying to get HQ rips from the 712 beta.

As quoted from the manual of Snatcher PCM2Wav

Quote

The full resolution is decoded by
SPCM2WAV, at 16 kilohertz (also mono and 8 bits). As you might guess, those
extra kilohertz make a world of difference!

Since in Lunar PCM2Wav, you can change the output frequency, I tried converting some of those files with the frequency you suggested, but the outputted wav files still sounded like geezers or chipmunks. Interesting. Luckily the source (in C) is included with Snatcher PCM2Wav. Maybe somebody can modify the program so that different input frequencies can be outputted correctly. I don't remember much C programming, nor do I understand the contents of the source, even with what I know of C.

The data in the wavefile would be the same, the only thing different would be the header. I assumed all the program did was wrap the bin file in a Windows wave format header.

[GerbilSoft]

Neo, on 05 November 2011 - 05:39 PM, said:

The data in the wavefile would be the same, the only thing different would be the header. I assumed all the program did was wrap the bin file in a Windows wave format header.

Sega CD does *not* use standard 8-bit unsigned PCM. If you attempt to play an 8-bit unsigned PCM sample on Sega CD by simply stripping the WAV header, you're going to end up with static.

Sega CD's PCM format is 8-bit sign/magnitude, which can represent values from -127 to +127. (Unsigned 8-bit is -128 to +127, biased at 0 == 0x80.) Here's a simple conversion table:

+--------+----------+------+
| Sample |   Bits   | Byte |
+--------+----------+------+
|  -127  | 11111111 | 0xFF |
|  -126  | 11111110 | 0xFE |
|  -125  | 11111101 | 0xFD |
|  -124  | 11111100 | 0xFC |
+--------+----------+------+
|    -3  | 10000011 | 0x83 |
|    -2  | 10000010 | 0x82 |
|    -1  | 10000001 | 0x81 |
|    -0  | 10000000 | 0x80 |
|    +0  | 00000000 | 0x00 |
|    +1  | 00000001 | 0x01 |
|    +2  | 00000010 | 0x02 |
|    +3  | 00000011 | 0x03 |
+--------+----------+------+
|  +124  | 01111100 | 0x7C |
|  +125  | 01111101 | 0x7D |
|  +126  | 01111110 | 0x7E |
|  +127  | 01111111 | 0x7F |
+--------+----------+------+

Note that since this is sign-magnitude representation, there's two zeroes. Also, 0xFF is used as a "repeat" marker of some sort, so -127 isn't actually representable.

[Chilly Willy]

0xFF tells the PCM chip to load the wave pointer for the channel from the loop pointer. Note that you need enough 0xFF bytes to allow for the fixed point increment added to the wave pointer. So if the channel can step by up to four, you need at least four 0xFF bytes at the end of the sample to make it loop properly.

[Andlabs]

If I come off as a jerk with this post then I apologize in advance.

I wrote the stuff on the SCHG and have had 90% of this done already, in a fully correct state, for several months (if not a year) now. The only issue is, as I've repeatedly stated in at least two forums now (here and SpritesMind), figuring out what the correct frequency that the RF5C164(?) chip runs at. I got several answers, but still seeing conflicting information — I can try what I do have and give the results to see which one sounds most correct, though sometime I'd like to see some chip measurements from NTSC hardware in particular, since I'm working with that version of Sonic CD (and even still, it could help improve the accuracy of emulation code, which is always a plus). I also have the driver itself disassembled and half documented.

Caveat if you're going to go about this the manual way, though: SNCBNKB1 has a sample > 64KB. If you're just reading the data raw this won't be a problem, however within the context of the Mega CD's hardware, it will. I think there's separate code in the driver for handling this.

Neo: the frequency of each sample has to be determined manually, by analyzing the sound data to find what the effective frequency number for C4 is. I have this as part of my setup. If you'd like, I can upload what I made, however again it's still hindered by inaccurate timing (plus the timing quirks of the Gens chip emulator).

Also I haven't looked at the prototypes at all :/

This post has been edited by Andlabs: 05 November 2011 - 11:35 PM

[Shadow Hog]

GerbilSoft, on 05 November 2011 - 10:26 PM, said:

Sega CD's PCM format is 8-bit sign/magnitude, which can represent values from -127 to +127. (Unsigned 8-bit is -128 to +127, biased at 0 == 0x80.)

Sorry for being a pedant, but if it's -128 to +127, then technically it's a signed 8-bit number. Unsigned 8-bit is 0 to +255.

[Neo]

GerbilSoft, on 05 November 2011 - 10:26 PM, said:

Sega CD does *not* use standard 8-bit unsigned PCM. If you attempt to play an 8-bit unsigned PCM sample on Sega CD by simply stripping the WAV header, you're going to end up with static.

Sega CD's PCM format is 8-bit sign/magnitude, which can represent values from -127 to +127. (Unsigned 8-bit is -128 to +127, biased at 0 == 0x80.)

I hereby stand corrected. I immediately noticed this when I opened up the SNCBNK file in a hex editor.

Andlabs, on 05 November 2011 - 11:14 PM, said:

Neo: the frequency of each sample has to be determined manually, by analyzing the sound data to find what the effective frequency number for C4 is.

I was actually wondering how the game does it, whether if each sample has information about its sampling rate, or if the program is hardcoded to play this sample at this frequency, etc.

[Andlabs]

Nope: the raw notes are taken, offset by some predefined amount that changes throughout the song to make sure they are in range of the chip, then the chip frequency is looked up in an array, possibly(?) added to by some other raw constant, and finally sent to the chip for output. The samples have no inherent rate, so what I was doing was figuring out what frequency would spit them out at either the frequency they're always playing in (drusm, SFX) or the equivalent to C4 (music). I don't know what tools Sega used when making the sound (probably holdovers from their RF5C68-based arcades (the RF5C164 is either a clone of this chip or made with a different fabrication process), like the System 18) so I don't know what input they used.

This post has been edited by Andlabs: 06 November 2011 - 09:54 AM

[GerbilSoft]

Shadow Hog, on 05 November 2011 - 11:19 PM, said:

GerbilSoft, on 05 November 2011 - 10:26 PM, said:

Sega CD's PCM format is 8-bit sign/magnitude, which can represent values from -127 to +127. (Unsigned 8-bit is -128 to +127, biased at 0 == 0x80.)

Sorry for being a pedant, but if it's -128 to +127, then technically it's a signed 8-bit number. Unsigned 8-bit is 0 to +255.

Unsigned refers to the fact that the byte value is treated as unsigned. The waveform is always -128 to +127, but with unsigned 8-bit, it's handled as an unsigned byte, and the "0" point is at 0x80. (Well, it's technically 0 to 255 with centerpoint of 128, but the centerpoint is effectively zero.)

Signed 8-bit would use standard 2's complement notation instead of biasing. That is, 0 would be 0x00, +127 would be 0x7F, and -128 would be 0x80.

From Wikipedia:

Quote

If the sample is 16-bit signed, the sample range is from −32768 to 32767, with a centerpoint of 0 (for example, signed LPCM data is used on Audio CD, DVD Video, 16-bit LPCM in WAV, audio/L16, etc.) If the sample is 16-bit unsigned, the sample range is from 0 to 65,535, with a centerpoint of 32,768.

This post has been edited by GerbilSoft: 06 November 2011 - 06:17 PM

[Chilly Willy]

Andlabs, on 05 November 2011 - 11:14 PM, said:

I wrote the stuff on the SCHG and have had 90% of this done already, in a fully correct state, for several months (if not a year) now. The only issue is, as I've repeatedly stated in at least two forums now (here and SpritesMind), figuring out what the correct frequency that the RF5C164(?) chip runs at. I got several answers, but still seeing conflicting information — I can try what I do have and give the results to see which one sounds most correct, though sometime I'd like to see some chip measurements from NTSC hardware in particular, since I'm working with that version of Sonic CD (and even still, it could help improve the accuracy of emulation code, which is always a plus). I also have the driver itself disassembled and half documented.

The CD runs off a 12.5 MHz master clock. This is also used for the PCM chip, which divides the clock by 384 for the base frequency used to update the pointers. Updates are ALWAYS at this fixed rate! The way you produce different tones is to change the increment used by the pointers for the channels. Each channel has it's own fixed point increment that can vary between 0 and 31.999755859 (5.11 fixed point number). Adding 1.0 each time will play the sample at the "natural" rate - the same sample rate as the clock (12.5M/384). Adding 2.0 each time will play the sample one octave higher, and adding 0.5 will play the sample one octave lower.

[ICEknight]

Neo, on 06 November 2011 - 05:30 AM, said:

I was actually wondering how the game does it, whether if each sample has information about its sampling rate, or if the program is hardcoded to play this sample at this frequency, etc.

Doesn't the game itself get confused about it sometimes, in the sound test?

I remember it occasionally playing them in different pitches than usual, and even mixing parts of adjacent samples for some odd reason.


PAL version, by the way.

This post has been edited by ICEknight: 08 November 2011 - 10:46 AM

[Andlabs]

IDK, but the routine for determining chip frequency is simple and is the same for YM2612 and SN76489 SMPS (and even the non-SMPS games used by arcade games, from which SMPS evolved from): there are two effects/coordination flags; I'll use $E0 and $E1. $E0 adds to the note value taken from the song, and $E1 adds to the chip frequency. So the routine is

• Take note value from song
  
• Add value of $E0 coordination flag — the note offset
  
• Look up new value in frequency table to get chip frequency
  
• Add value of $E1 coordination flag — the frequency offset
  
• Send result to chip