.gin and .abk sound formats (Need for Speed mw 2005)(help)

[MWisBest]

I saw someone on GTRCars reversed my EXEs, but that was not a secret, I told you about codec types here. There's no reason comparing them with ffmpeg codecs, this will not help at all.

I simply understand things better by looking at code, I am completely unfamiliar with this codec so I just wanted to get a better idea of it.

Good news. Now i know why swapping ABK files didn't work. They have car ID at 0x126c. Just change that ID and you can replace any car ABK with another. That proves that there's nothing specific for different ABK files and the game can use any of them if needed.

Bad news is that ABK structure has a lot of sound properties and I don't think we can ever identify them all. Let's just hope we can identify those that you really need.

It may be possible to figure some of these out by digging into the VLT database stuff for engineaudio and turbosfx. Basically the game has a database containing all sorts of values, from car performance to traffic patterns to audio stuff. Unfortunately rather than using a string for the row/column names it generally uses a 32-bit hash derived from such a string, but it's usually not super difficult to figure out the original string, anything that's less than 8-9 characters can even be just plain bruteforced.
For example, I already found one new entry name : http://i.imgur.com/D00Wqr2.png

[id-daemon]

I use rfactor sounds as I have them at hand

I can't yet understand why your samples didn't work as expected.

Here's something I was able to encode from some guy's roar on youtube. Check if you can hear it working on your Gallardo.

[V12-POWER]

I use rfactor sounds as I have them at hand

I can't yet understand why your samples didn't work as expected.

Here's something I was able to encode from some guy's roar on youtube. Check if you can hear it working on your Gallardo.

It sounds like a dinosaur after using your decoder and listening to the sample, was this on purpose or not? In game you can hear the sample playing, but it does not resembles any car sound, that's why I tried with the decoder.

[id-daemon]

Yes that was on purpose. I wanted to be sure it will be heard along the whole acceleration curve.

[V12-POWER]

Yes that was on purpose. I wanted to be sure it will be heard along the whole acceleration curve.

then it sounds alright, it's a loopless system so it isn't such a task to blend samples as the abk

[id-daemon]

Alright, I think now we have enough info to make the engine mods.

1. ABK

- we don't know anything about the 3 tables in the beginning, but we have a lot of different ABK files to choose as a template for a new engine.

- we know all about the PT header and can change it

- we can replace the sounds with SX.exe. Typical car has 3 on throttle sounds recorded at 2000, 4000 and 8000 RPM. So if we want to make the right engine sound, we have to make audios with these freqs.

2. GIN

- the first table is a RPM/samples relationship to determine the exact number of sample in the audio that must be played at certain RPM.

- the second table is a loop table, so having a sample number from the first table, the game chooses one of the loops (the one containing that sample) to play at current RPM. So the sample is never pitched up or down, it's always played as it is.

- we have a working encoder for the sample itself. I'm not sure it will work 100%, but it works for the ones I tried.

I can go further into explaining how this all works, with pictures maybe. Then we need to decide which tools to write to help automating the process.

[V12-POWER]

Alright, I think now we have enough info to make the engine mods.

1. ABK

- we don't know anything about the 3 tables in the beginning, but we have a lot of different ABK files to choose as a template for a new engine.

- we know all about the PT header and can change it

- we can replace the sounds with SX.exe. Typical car has 3 on throttle sounds recorded at 2000, 4000 and 8000 RPM. So if we want to make the right engine sound, we have to make audios with these freqs.

2. GIN

- the first table is a RPM/samples relationship to determine the exact number of sample in the audio that must be played at certain RPM.

- the second table is a loop table, so having a sample number from the first table, the game chooses one of the loops (the one containing that sample) to play at current RPM. So the sample is never pitched up or down, it's always played as it is.

- we have a working encoder for the sample itself. I'm not sure it will work 100%, but it works for the ones I tried.

I can go further into explaining how this all works, with pictures maybe. Then we need to decide which tools to write to help automating the process.

I'd be glad if you could explain this for everyone, as for the tools we can discuss this later. As for the abk tables, we should get how many data strings there are for the first table at the offset table at the end. First field gives count of strings for the very first data table at the start. Second offset table at the end gives offset for the second data table. Along with this, the offsets for the third and last part (the volume curve) are given in the second data table.

[id-daemon]

First field gives count of strings for the very first data table at the start. Second offset table at the end gives offset for the second data table. Along with this, the offsets for the third and last part (the volume curve) are given in the second data table.

Yes, but this leads to nothing. I see no meaning in the first table. The second table has some values, but we don't know how they are connected.

So let's return to GIN structure now.

I've made a vocal sample for the experiments how it works. This is what I found.

The first GIN table always has 50 segments (51 numbers). But for example let's say it only has 6, for the RPM from 1000 to 7000. 1st segment from 1000 to 2000, and so on. Let's also say the sound has total of 150000 samples. We're running at 6500 RPM. This means we are in the last segment of this table and it gives us sample numbers from 120000 to 150000 (these are the values 6 & 7 from the table). Now we calculate a proportion within this segment to determine that 6500 RPM gives us sample number:

(150000-120000)/(7000-6000)*(6500-6000)+120000 = 135000

So the game must play the sound in the region of sample number 135000. This is approximately how the 1st table works.

[id-daemon]

Now to the second table.

It has variable size depending on length and complexity of a sample. Let's say our table 2 has these values:

0, 10000, 25000, 40000, 65000, 90000, 120000, 130000, 140000, 150000.

So if we got sample number 135000 as described before, the game will start playing a part of the audio from sample 130000 to sample 140000, looping it while the RPM stays in the same range.

[V12-POWER]

First field gives count of strings for the very first data table at the start. Second offset table at the end gives offset for the second data table. Along with this, the offsets for the third and last part (the volume curve) are given in the second data table.

Yes, but this leads to nothing. I see no meaning in the first table. The second table has some values, but we don't know how they are connected.

So let's return to GIN structure now.

I've made a vocal sample for the experiments how it works. This is what I found.

The first GIN table always has 50 segments (51 numbers). But for example let's say it only has 6, for the RPM from 1000 to 7000. 1st segment from 1000 to 2000, and so on. Let's also say the sound has total of 150000 samples. We're running at 6500 RPM. This means we are in the last segment of this table and it gives us sample numbers from 120000 to 150000 (these are the values 6 & 7 from the table). Now we calculate a proportion within this segment to determine that 6500 RPM gives us sample number:

(150000-120000)/(7000-6000)*(6500-6000)+120000 = 135000

So the game must play the sound in the region of sample number 135000. This is approximately how the 1st table works.

The first data table is important tho. There are few variables depending on which byte signature it has, for each string. aside from that im not familiar with the changes and properties of this part.

But amazing job bro, neat. We ready for the automatizing part now? because for the gin files it has not that much info to change in the header, but the abk header (first 92 bytes) need changes if we plan on adding sounds or replacing them with bigger sizes, some offsets at the very end of the file would need too.

[id-daemon]

There are few variables depending on which byte signature it has

You mean 89 86 is always followed by 4-byte offset?

the abk header (first 92 bytes) need changes if we plan on adding sounds or replacing them with bigger sizes

I don't think we can plan adding sounds. Seems impossible now. As for bigger sizes, it won't even require changing the header.

[V12-POWER]

There are few variables depending on which byte signature it has

You mean 89 86 is always followed by 4-byte offset?

the abk header (first 92 bytes) need changes if we plan on adding sounds or replacing them with bigger sizes

I don't think we can plan adding sounds. Seems impossible now. As for bigger sizes, it won't even require changing the header.

yes. 89 46 always has the offsets, only thing is that these offsets make no sense whatsoever. There's also an 8B and 83C6 bytes but I don't know if the last (C6) is part of the signature or not.

Btw, you don't need to change the file size and respective offsets when replacing sounds with bigger ones?

[id-daemon]

Btw, you don't need to change the file size and respective offsets when replacing sounds with bigger ones?

No. You can append the sounds to the end, and change PT table offsets and sizes. No need to change headers or other structures.

[id-daemon]

Ahem... I know what the first ABK table is. It's not a table. It's f..ng plain assembly code. One big routine with a lot of calls to the main EXE and "ret" in the end.

89 86 is mov [esi+...],eax

The table in the end is a table of CALL offsets. When the game loads ABK, it fills these offsets with real addresses in the EXE. I found it by debugging.

[V12-POWER]

arrggg shit. I suspected this a while ago when I learnt to use ollydbg but thought it was strange to have code in a sound file, anyways, so it uses functions directly from the exe to blend samples and creating the sound from there, you have the offsets in the exe for abk file reading function?

[id-daemon]

Yes I have them

[id-daemon]

That's the whole WV Golf routine with addresses filled

http://pastebin.com/JtvwaZ2S

[V12-POWER]

I'll see what I can research of the audio system...im not using cheatengine like you do so even the call offsets are different.

shit, I couldn't even find the abk-loading code, found it loaded into memory (the abk files) but can't seem to find when the exe loads the abk files. my debugging skills have got really rusty in the past months

[id-daemon]

I performed some analyzing. Some ABK files have multiple routines. They all have separate data segments (that was what we supposed to be the second table). The code is long, generally its just a sequence of calls, each with its own data section from the data segment. There's nothing much interesting about the loading code, it just changes relative offsets to absolute using tables from the end.

So i think after detailed research we could add some code to make more sounds or change the existing effects. But I think it's not worth it for a little mod changing engine sounds.

[V12-POWER]

It's up to you - I can't code for sht