No Vocal Sonic Rush project

I do, and I sure will test your hack.

 

I must say Sonic Rush didn't get much attention from any of us.

 

Maybe because it isn?t Emulated yet. =P Actually Rush is better than any games from GBA.

And Sonic Rush music is nice

 

Do we know which company who made Sonic Rush?

 

I agree to an extent. While I don't mind them for the most part, it would really be refreshing to hear them from a new angle, aka without those "lyrics". I swear all I hear in Mirage road is "Dudduhduhduhduhduhduhd UH! Taco taco meat meat smack ah mah nuts! uh! taco meat meat smack ah my nuts! uh!". Im dead serious. I've listened, too.

But this is a great project Heran. Here's hoping you actually can/will see it through. Im anxious to hear any possible results.

 

Finally, you hate it as much as I. I know you hated Sonic Rush. I just needed proof.

 

Not what I said, but okay.

I actually love Sonic Rush. I just said a couple of the lyrics are nonsensical and it would be a refreshing view to hear them without lyrics. As in "Nice project Heran. I agree its a nice game with a few weird lyrics. Keep it up."

 

A part of the vocals in mirage road sounds like "masturbate" oO

 

I have to mention one thing. The ADPCM format used in Sonic Rush is close to but is NOT "Dialogic 4-bit ADPCM VOX" format (edit: now, I've just noticed you wrote: "It's not perfect mind you" on your first post).

I know it because many Genesis and System16 games use that format and they behave exactly the same when opened in a sound editor as VOX ADPCM sounds (I mean getting incorrect distortion or dynamics and they have the same aspect whatever you use Audition, Goldwave or any sound editor).

Here's an illustration of what you get by opening that kind of samples in VOX ADPCM:
http://sonicdiscovery.free.fr/music/crackers.wav (that mysterious Sonic Crackers voice)

The only tool that I know capable of decoding that kind of ADPCM properly is... SonicQX! Perhaps we should ask Saxman about the algorithm he used to decode the samples. :P

So the crashing problem might only be an "invalid" sdat file. If we find a way to create valid sdat files, there might be a chance for the game to work with those edited sdat files... unless some kind of CRC checking is performed by the game, as you said.

 

Yeah that version of the voice has the silences in it which make it sound like it's cleaner than it actually is, there's a properly decompressed version on Sonic CuLT (though it's MP3ed for some reason -_-). But yeah you'd think you could just overwrite the voice samples with silent ADPCMs compressed.

And CRCing is a standard part of many compression routines, they may very well do it, and even if it's not individual changing one would effect the whole lot anyway.

 

That's true. Normally, it should sound just corrupt. Now that I remember, each .sdat file contains more than one sample. And each sample could be preceded by a header (just like in GBA games) indicating data such as picth, loop pointers, etc.
Or, there could be a general header at the beginning of the file.

And, tacking an ADPCM .wav header on a .sdat file would work only under the condition that we have an appropriate codec to decode the created .wav file. If you take any type of ADPCM .wav header, I'm afraid it would give you crap in return. :P
I tried that once on a System 16 game sound file and haven't been able to get anything right. But who knows? Perhaps we could get something that way.

I heard that version once and was intrigued because of its clean sound. Probably someone who tried to decode it using the right ADPCM algorithm (which might be proprietary).

Obvious, now that I think of it. ADPCM is a lossy technique, just like JPEG, MPEG (for still and moving pictures) or MP3 (for sound).
This means that if you decode an ADPCM sound and then re-encode it in ADPCM, you don't have any chance to come back to the previous version of the sound this way.

I may have a solution:
- isolate a part of an .sdat file using a hexeditor
- then open this part using a sound editor in VOX ADPCM format (the only method we know at this moment)
- make some edits to it and re-encode that extracted data as VOX ADPCM.
- now, replace the original data in the .sdat file by the altered one and save the .sdat file using the hexeditor
- recompile the ROM and see what happens ^^

This way we can find out if there is indeed a CRC check to .sdat files (because only a part of the file would have been modified rather than all the file being destroyed because or lossy re-encoding).