Frogger 3D (.VB + .VH)

[Xiron]

Alternatively known as Frogger: He's Back!

After doing some research, I found that these extensions are the standard format for PSX games (which this game was also on as well as PC). I think though that the .VH and .VB files may have got changed up a bit when being ported to the PC considering PSounds, a PSX sound extracting tool, can't get anything out of them.

I've attached a few files from the PC version if anyone wants to take a look.

[aluigi]

raw 16bit pcm, mono, 22050hz?

[Xiron]

Could be. I have no idea, I've never reversed audio before. =P Did you guess that or did you actually look at the files?

Importing the .VB files into audacity with what you said, 11025hz gives the proper speed of majority of the sounds, though there are a few sounds like when you get 1up that are 22050.

Any way I can go about extracting the files the proper way? Would the .VH files be attached in any way, or is is just a file to do something like tell the game where to use the sounds?

[aluigi]

Interpreting the VH file is not immediate because there are no easy references to length, freq and channels.
A comparison between two different VH files doesn't help in guessing these fields.

[Xiron]

Various sources say that VH is the head(er) and VB is the body, so I guess both work hand-in-hand somehow. If I may ask, why would one choose to have the header and body separately in two different files instead of just one? What are the known beneficiaries?

Well I did notice one thing, all the .VH files except for Generic.VH start largely the exact same (even going up to half the file at some times). I'll attach generic below.
The generic one is also the only one I really noticed that had the few 22050hz sounds in it, and is accessed in every zone.

[atom0s]

Various sources say that VH is the head(er) and VB is the body, so I guess both work hand-in-hand somehow. If I may ask, why would one choose to have the header and body separately in two different files instead of just one? What are the known beneficiaries?

No benefits to be honest, just lets game makers make the ease of ripping resources tougher. More or less a minor and simple way to protect their assets.

[atom0s]

This is a complete guess at the .VH file setup but, from what I can see:
- The first 4 bytes is an entry count.
- The rest of the file data is entries.
- The file size / entry count equals a perfect 28 bytes, so this leads me to believe each entry is 28 bytes long.

Code: Select all

struct Entry
{
    unsigned char Data[28];
};

struct File
{
    unsigned int Count;
    Entry Entries[Count];
};

From there, looking at the entries data, there are a few spots where the data looks to be something useful.

Code: Select all

struct Entry
{
    unsigned int A; // Always 0 or 1, possibly channels
    unsigned int B; // Seems to be data start offset.
    unsigned int C; // Seems to be size of data.
    unsigned int D; // Unknown (Seems to be 1 all the time.)
    unsigned int E; // Unknown (Seems to be 1 all the time.)
    unsigned int F; // Hz (Seems to be 11025 all the time.)
    unsigned int G; // Bit count possibly, seems to be 16 always.
};

Is what I could come up with. I'm not a sound file guy but seems pretty straight forward. Hope that helps.

[atom0s]

Alright, here is a static compiled setup of the file you gave converted to a .wav using a tool I wrote real quick.
It seems like they compress multiple sounds into the single file. So the entries I showed above seem to be a single sound each.

The way I built this was to force all sounds into a single file. I can adjust the tool to write separate sounds as well. The other issue is, is that I'm not 100% certain what some of the entry fields are for so I cannot guarantee this will work for all files you make.

[Xiron]

Heh, well at least you can write programs, I'm helpless.
I wonder how the game tells the sounds apart when it is all packed into one file... time frames?

If it isn't too much trouble, having them extract separately would be great.
Thank you for your time!

[atom0s]

The header info I posted above is how it knows the sound files per-file. When I get some free time later tonight I'll make another tool that will dump them all to separate files.

[Xiron]

For the sakes of game modding, would the challenge of recreating a new file(s) be something you're up to afterwards?
I fully understand if you'd rather invest your time elsewhere.

[atom0s]

Alright here is a tool that will let you drag and drop the .vh file onto the form and it will dump all the sound files into a new 'ExtractedSounds' folder where the .vh file is located at.

Some rules for this to work:
- The .vh and .vb files must be in the same folder.
- The .vh and .vb files must share the same file name. (For example: GENERIC.vh and GENERIC.vb)

Should create the .wav files properly no matter the hz playback rate. I'm not a sound expert though so I could have done things wrong. Also there are a block of sounds I'm unsure of due to how they are stored in the file. Because of how they are stored I just skip them for now until someone else has some feedback on how they should be handled. All files play fine with what you supplied. Hope this is what you wanted.

[Xiron]

Should create the .wav files properly no matter the hz playback rate.

Kinda. Like 1/10 chances I'll have of hitting the correctly trimmed sound. There are bunch of different files for each sound, lots cut or overlapping into the next, sometimes even having the wrong hertz.

Aside from these factors, everything is fine.

Also there are a block of sounds I'm unsure of due to how they are stored in the file.

Example of one of these blocks?

[atom0s]

The hz I use come from the headers for each entry. So they should be correct. Is there specific files that are not working properly? I can take a look at them.

[Xiron]

Erm, yeah. I suppose. I tried the generic one which was one of the ones I attached and it worked perfectly (aside from the ones you said you couldn't figure). The cave one and the desert on the other hand that are also attached... well, as you can tell by the first 10 sounds of the cave that come out, they are all the same sound extracted, with different cuts, some even different hertz.

[atom0s]

Erm, yeah. I suppose. I tried the generic one which was one of the ones I attached and it worked perfectly (aside from the ones you said you couldn't figure). The cave one and the desert on the other hand that are also attached... well, as you can tell by the first 10 sounds of the cave that come out, they are all the same sound extracted, with different cuts, some even different hertz.

Looking at the .VH files, everything lines up fine with how my extractor saves things. It seems like some of the files could be just non-used sounds that are there for possible reusage later on or something. It seems only a small hand few in each of the other files are like this while the rest play fine and have a single sound playing. I could be wrong though, but that is how it looks to me.

[Xiron]

Only a small handful? Erm, at least 70% of all the sounds that come out of the cave one is that one sound of the bat (or whatever that high pitched sound is, I don't even know.). As it turns out though, only the first 31 sounds (70%) are like that. The remainder (#032-045) afterwards are the proper sounds and are the only thing that needs to come out. Everything prior is just garbage extra.

[atom0s]

The second half of entries in the .VH files looks like this:


(First image is GENERIC.VH, second is CAVES.VH)

Field wise, things start looking like:
- 1: Always set to 0 in the second half of the files.
- 2: Usually set to the .VB file length. (some are not like this though)
- 3: Set to an unknown value that is not a size that I can understand.
- 4: Usually always set to 1.
- 5: Usually always set to 1.
- 6: Still seems to be a hz value.
- 7: Still seems to be a bitrate or block size value.

I'm not too sure what to do with that block without really debugging the game making use of them.

[Kneesnap]

Field wise, things start looking like:
- 1: Always set to 0 in the second half of the files.
- 2: Usually set to the .VB file length. (some are not like this though)
- 3: Set to an unknown value that is not a size that I can understand.
- 4: Usually always set to 1.
- 5: Usually always set to 1.
- 6: Still seems to be a hz value.
- 7: Still seems to be a bitrate or block size value.

Thanks for this outlier. I was able to complete the format information based on some of the information you gave. We can currently export and import these sounds now.

However, recently re realized the Playstation sound format is a bit different from the PC version. I've attached the files below. PSound can extract these sounds, but it's not open source so that doesn't help me very much.

I've been having trouble finding documentation on how the audio bank is stored. The header isn't an issue.

If you could help again, that'd be fantastic.

Thanks!

[atom0s]

There are several tools that can extract the sounds, such as:
http://hitmen.c02.at/files/releases/psx/hit-snd.zip

In this case, the frequency looks to be 11025. Using that tool, you can extract and play the converted wav files fine.

This is another project that is open source:
https://github.com/vgmtrans/vgmtrans