(Jet Set) Static output for OSBs / analysis of incorectly handled SFX #1
Comments
|
There's a lot of "extra data" in the OSB files that simply aren't documented properly yet. AMKR, NITS, PALP, EMUN, IPTC, RPCE, and ETTX metadata are all skipped, however, this doesn't apply to Adding some quick debug console output gives us a hint: Looking at how file the offset data is parsed, we can see a pattern to our bad data chunks: Lines 88 to 92 in 0d474f2 Currently, I am handling that value If we look at the lengths for hints, for file 8, HOWEVER, simply setting So the |
biggestsonicfan
added
bug
|
ADPCM this whole time? Certainly makes us feel silly. 11-13 don't loop, they should just be weapon sounds that are unused (Police don't have guns in JGR), actually they're identical to Onishima's as well, which those are single-use event sounds. |
|
As for the other half of this issue then, I do support different sample rates: Lines 27 to 28 in 0d474f2 Do you have a specific example of a pitched-up extraction so I can look at the metadata? |
|
A good example, from both regions (e_snd_se, snd_se) would be Combo's voice lines (cv09_combo). In audacity, Combo can be pitched properly with -9%, Japanese -30%; This was the first one I tried to fix manually. A majority of the US SFX seem to be from 9-11%, Japanese being 26-30%; Some of the gangs like Love Shockers also change speed, not just pitch, so they come out a little warbly if you have one aspect corrected but not the other. A good example for that would be Japanese Tab (cv09_yoyo), when he goes "YOOOOO"; Sounds terrible if you only pitch fix it. I don't know what speed it's at, I did it by ear comparing in game and it still sounds terrible, warbly.... Same thing with a few Love Shock sounds. |
|
Analyzing So, let's take a look at the "unknown data" within the If we assume that only the data that's identical between 0-13 and 15 is where the pitch/speed change is different from 14, we get this: Now let's go back and look at our friend We can see that bytes 32-35 (with the exception of I'm gonna see if I can figure anything out based on this data. |
|
I suppose you could put one pattern over the other, in the OSB, and see how the sound plays in game. Take the one from 14 that plays properly and put it over a pitched index. "HEY!" should be a common combo jump sound, easy to replicate. |
|
It's not a solution, but changing the sample rate to 32 kHz seems to do the trick for most high-pitched audio. For now I can add a parameter for sample rate to override the default 44.1 kHz, so audio can at least be extracted and listened to properly. I can't promise a timeframe on the next release, but it should be soon. I want to try to move the project to .net core so I can automate build releases here on GitHub. |
|
When you get around it, all be sure to test further. |
|
Sorry for the wait @Laserdisc9X , but I decided to do a lot of changes with the latest release. Give it a shot! |
This is a two-parter, first expanding upon the Loop flag I mentioned on twitter and second my theory on why sounds are handled incorrectly, based on my decade+ modding experience with this game.
Firstly, some sound banks output static when a specific index is extracted. For this demonstration, we will use E_POLICE.OSB, primarily focusing on indexes 08, 09 and 10, in E_SND_SE.OSB.
These 3 indexes are extracted as static, or corrupted audio; I have deduced that these sounds, among the others that extract improperly, have one thing in common: They're flagged to "loop" indefinitely.
For example, when the Police chase the player, a "HUP HUP HUP" sound is looped until the player escapes,, If you import the OSB into audacity as raw, pitch/speed shift it a bit, you can somewhat hear this sound and the two others.
Furthermore, I've deduced that this "looping flag" is done within the binary, not in-game. I can prove this by swapping the police sounds with any of the playable characters, none of which have looping audio. I switched out Tab's (CV04_YOYO (yes, it's named wrong)) and it just so happens the "HUP HUP HUP" is the same index as one of Tab's jumps, so the sound is easy to produce.
Jumping with Tab, after swapping the sfx banks, produces the police "HUP", and it indeed DOES loop, proving it's handled in-binary, since none of the players have looping audio.
Something is being read wrong, perhaps a pattern that hasn't been noticed; Something is being read improperly.
Secondly, about the incorrectly handled audio: I'm convinced it's actually correct.. (Not the static but the sounds that are the wrong pitch / speed.)
I've observed this for sometime, and played around with swapping sounds/putting new sounds; I think this was done to save space on the GD-ROM, even though the game is only like 800mb normally.
Sounds for Characters like Combo or Goji are pitched improperly, some even more complex with changed speeds, and I believe the game applies an algorithm to re-pitch them depending on their size in the binary. The manatee driver for the Dreamcast clearly has this ability given the sewers adds revert to the voices, and they're definitely not baked in given how they can glitch. (buggy port).
I swapped all of Combo's sounds, which extract """wrong""" as +9% (pitched high), with accurately pitched versions that I did in Audacity; This resulted in the game slowing down the sounds, If I pitch them properly, but speed them up, they play how I pitched them but now at a different speed.
I did the same with Goji, same result.
There is some sort of algo in the game, or it's one of the unknown header definitions, it all seems overly engineered; I cannot say i'm surprised, every level has duplicate textures, and textures from other areas. There are about 22 files that have textures for characters and enemies that never get loaded.
Just a mess.
The text was updated successfully, but these errors were encountered: