V12-POWER, posted Thu Oct 08, 2015 3:30 pm (8207)

---

id-daemon2 wrote:

Can you give me an example of a car where I can hear GIN file? Because on low end cars I almost can't hear it.

you can try swapping some abks. the not so obvious becomes obvious when you listen to the rpm buildup sequence. As I said, we can "fix" the need for gin replacement by using more samples in the abk, but this will need more file knowledge for samples crossfade and mixer properties. yet again if the plan is to move to later games like pro street then we will be forced to replace gin files. their format is .tmx but is a container, gin files reside inside it

id-daemon, posted Thu Oct 08, 2015 3:41 pm (8209)

---

V12-POWER wrote:

you can try swapping some abks

That's what I did. I tried VW Golf with GINs from audi and ferrari and can't hear almost any difference. That's why I'm asking for an example.

Another info. ABK files from Carbon use yet another codec.

V12-POWER, posted Thu Oct 08, 2015 4:04 pm (8212)

---

id-daemon2 wrote:

V12-POWER wrote:

you can try swapping some abks

That's what I did. I tried VW Golf with GINs from audi and ferrari and can't hear almost any difference. That's why I'm asking for an example.

Another info. ABK files from Carbon use yet another codec.

when I used (abks) from lamborghini gallardo, tvr_cerbera (bmw m3 gtr), corvette, or truck sounds I noticed that the gin is used in the background in the higher rpm range, having dominance in the middle rpm range. when shifting or lifting the throttle you hear the gin sound. there's also small hints of the gin when coming close to the rev limiter. I tested this over and over to be sure that it wasnt a mistake of perception.

replacing the gins should have the same effects, otherwise those guys who used to make "sound mods" by exchanging .gin files were doing nothing at all

id-daemon, posted Thu Oct 08, 2015 4:11 pm (8213)

---

Thank you for the example, I'll check it.

V12-POWER wrote:

... those guys who used to make "sound mods" by exchanging .gin files were doing nothing at all

Yes, they couldn't exchange ABK files and now we know why.

Can we return to that SX.exe problem? What could be wrong? Are you sure you used the right options? Did you use original WAV extracted on changed it somehow?

V12-POWER, posted Thu Oct 08, 2015 4:39 pm (8214)

---

it works now, forgot to tell ya, I did input the command lines wrong so thats why it did not work. I used many samples, however in game it does not sound as someone would expect it - im talking about completely different sounds when comparing in-game to audacity samples - I changed the sample rate and put it to mono, but not in anyway it should sound like it does in game (think about a big v8) instead of a small 4 cylinder engine

This might be because of sample rate (original 44.1khz to 22.05khz) and nothing serious but felt the need to say it

About the new Abks of nfscarbon. I knew about the new codec because of the audio organization, but did not recognize the exact codec however

id-daemon, posted Thu Oct 08, 2015 4:47 pm (8217)

---

Did you change the sample length in ABK?

V12-POWER, posted Thu Oct 08, 2015 4:50 pm (8218)

---

id-daemon2 wrote:

Did you change the sample length in ABK?

used the same lengths as the original abk.

id-daemon, posted Thu Oct 08, 2015 5:36 pm (8222)

---

Ok tried gallardo and yes, for this car GIN file is playing a big part. I haven't played NFS since 2000, now just started this MW game, so everything I had was that Golf with the first race engine and for this one GIN is not that important.

Give me some time to make experiments.

V12-POWER, posted Thu Oct 08, 2015 6:57 pm (8240)

---

take all the time you need bro

id-daemon, posted Thu Oct 08, 2015 8:07 pm (8250)

---

I tried installing locomotive engine onto WV Golf. That was fun, yet you can hear when 3 parts of speedup sound overlaps, they must be accurately adjusted or you get phase artifacts like these.

p.s. can you describe which samples you replaced, and give me your wav files?

V12-POWER, posted Thu Oct 08, 2015 9:06 pm (8252)

---

id-daemon2 wrote:

I tried installing locomotive engine onto WV Golf. That was fun, yet you can hear when 3 parts of speedup sound overlaps, they must be accurately adjusted or you get phase artifacts like these.

p.s. can you describe which samples you replaced, and give me your wav files?

sure, I use rfactor sounds as I have them at hand. I replaced the 2 off throttle samples, replaced the 2 on throttle samples and then the idle sound which is the one that works the most. the number of the samples is 6 for high rpm on throttle, 3 for high off throttle, 1 for idle, 2 and 4 for low rpm off and on throttle. I did cut parts of these files to match the original sizes.

the attached file lacks the veryhigh sample, which is attached in my post above

edit: the locomotive sounds awesome!

MWisBest, posted Thu Oct 08, 2015 11:27 pm (8254)

---

id-daemon2 wrote:

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.

id-daemon2 wrote:

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, posted Fri Oct 09, 2015 9:48 pm (8286)

---

V12-POWER wrote:

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, posted Fri Oct 09, 2015 11:17 pm (8287)

---

id-daemon2 wrote:

V12-POWER wrote:

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, posted Sat Oct 10, 2015 5:51 am (8293)

---

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

V12-POWER, posted Sat Oct 10, 2015 11:14 pm (8328)

---

id-daemon2 wrote:

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, posted Sun Oct 11, 2015 4:16 pm (8358)

---

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, posted Sun Oct 11, 2015 6:35 pm (8363)

---

id-daemon2 wrote:

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, posted Sun Oct 11, 2015 8:12 pm (8366)

---

V12-POWER wrote:

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, posted Sun Oct 11, 2015 8:35 pm (8367)

---

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, posted Sun Oct 11, 2015 9:12 pm (8368)

---

id-daemon2 wrote:

V12-POWER wrote:

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, posted Mon Oct 12, 2015 3:07 pm (8380)

---

V12-POWER wrote:

There are few variables depending on which byte signature it has

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

V12-POWER wrote:

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, posted Mon Oct 12, 2015 3:55 pm (8383)

---

id-daemon2 wrote:

V12-POWER wrote:

There are few variables depending on which byte signature it has

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

V12-POWER wrote:

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, posted Mon Oct 12, 2015 4:26 pm (8384)

---

V12-POWER wrote:

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, posted Mon Oct 12, 2015 5:10 pm (8386)

---

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.