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

[id-daemon]

id-daemon2, have you been able to pinpoint which rpm are the game's samples? You said something about 2000, 4000 and 8000, and I'm not exactly sure it's like that, but some sounds seem to obey these criteria despite not reaching such rpm in the game

I'm sure these are the right values for some cars, even if they're not reaching such rpm, they use 8000 rpm sample to produce higher range of their engine. But I only checked 2-3 cars, no more.

I will also investigate the ABK/GIN change phenomena later, if I will have time.

[Zpectre87]

I'm sure these are the right values for some cars, even if they're not reaching such rpm, they use 8000 rpm sample to produce higher range of their engine. But I only checked 2-3 cars, no more.

I will also investigate the ABK/GIN change phenomena later, if I will have time.

After further investigation I believe you're right. The sound I mentioned never goes to 8000 rpm in the game, but, there it is in the ABK.

If possible you could get the open VLTEdit by MWisBest and play around with the values in the engineaudio node, or I could also help you with that.

[id-daemon]

If possible you could get the open VLTEdit by MWisBest and play around with the values in the engineaudio node, or I could also help you with that.

I don't see how it may help?

[id-daemon]

Well, it seems the game expects GIN file to have exact number of elements in its table (for each car). Maybe it is written somewhere in the engine parameters, I don't know.

Strange is that if it has more or less elements, it works wrong, but the same way. Maybe it's also the reason for what V12-POWER reported before.

Anyway, that's easy to correct. This is a new version of GIN_encode that has one more parameter: number of elements. This number is also in the output of GIN_decode. Tested on Murcielago, seems to work.

[Zpectre87]

Many thanks! I'll test it ASAP.

EDIT: Works as intended. But you won't always be able to use the same number of elements as the original car, only if the sound exactly reproduces the acceleration increase of the original sample. In my example, the Diablo sound starts from higher rpm than Murciélago one, so if it ends at the same rpm I guessed I'd need more elements to better "split" the sample. So, instead of 180 like in the original GIN_Murcielago.gin, I used 195 or something like that, and it worked. Many thanks!

I believe the correct amount of elements can be calculated from the info you've posted a few pages back.

I can quickly build a batch file to easily replace all the ABK sounds, too, so I don't think we need a GUI for now.

[Zpectre87]

Here's a quick batch structure file I made for ABK_insert.

Edit it with a text editor. Replace XX with sound ID (can be found with VLTEdit tool), switch between EE and SPU when necessary, and replace [file#] with your samples. Delete/add lines as needed.

You MUST have everything in the same folder. This batch WILL delete the original ABK file in the folder, so make backups!

It would be easier if the ABK_insert tool accepted wildcards, but I couldn't make it work.

[id-daemon]

But you won't always be able to use the same number of elements as the original car

No, you always can use the same number. And I suggest you doing so.

I think 180 is more than enough for any car. Also, for best results you must manually adjust ALL the elements, and my tool doesn't support it anyway, so it doesn't matter how many elements are used.

[Zpectre87]

No, you always can use the same number. And I suggest you doing so.

I think 180 is more than enough for any car. Also, for best results you must manually adjust ALL the elements, and my tool doesn't support it anyway, so it doesn't matter how many elements are used.

Is there negative consequence for using more than that? GIN_Murcielago.gin has 180 elements. When reencoding I tried:

180: I had the same issue I was having earlier.
184: GIN_Diablo.gin number of elements. A bit better.
195: Worked correctly, but I agree that you don't need this much, I just threw in a high number to see what happened.

I insist that depending on the sound you may need more or less elements, because it's very hard to bend the sample's pitch exactly like the original sound, so the most you can have is an approximation. 180 may work if the approximation is good enough, but this particular car (Murciélago) was not the only one I had problems with. When reencoding the sample extracted from GIN_Ferrari_360.gin to replace GIN_Gallardo.gin with, I had very similar problems, which don't happen when you simply replace GIN_Gallardo.gin with the original GIN_Ferrari_360.gin, and this is important since both sounds have very close top end. (BTW Gallardo with Ferrari exhaust sounds awesome!)

I've been having some fun with your tools lately but haven't made a "right" sounding bank yet, due to procrastination.

[id-daemon]

Is there negative consequence for using more than that?

I still can't understand why number of GIN elements can affect ABK sounds. With 160 and 260 it fails. So it can be broken anytime, because we don't understand the reason. I can only hope that at least with the same number it will work correctly.

[Zpectre87]

I also have no idea. I was considering it could be because you may need more elements to correspond to how the GIN bends and increases rpm, and could also be related to the wildcard values you've used.

ABK works fine though, in fact with ABK_insert working right I can increase the pitch of ABK samples instead and keep GIN elements intact. I suspect it would work, but needs testing.

[id-daemon]

I was considering it could be because you may need more elements to correspond to how the GIN bends and increases rpm

I'd understand if it could lead to GIN sounding worse, but ABK? How can it affect that?

and could also be related to the wildcard values you've used.

Wildcard values? Where?

[Zpectre87]

I'd understand if it could lead to GIN sounding worse, but ABK? How can it affect that?

It's possible the number of elements in the GIN affect some rpm value relative to both GIN and ABK, so if you have the wrong number the GIN plays right but the ABK doesn't.

Example: wrong table has 180 elements across the sample. This number of elements somehow doesn't give enough "length" for the ABK to play until the end. If you add some elements, you "increase" this "length" and give room for the ABK to hit the correct rpm.

If you do the reverse... Low revving GIN with high revving ABK, the GIN halts at the end of the sample when reaching max rpm. Why? Not enough elements! I looked at GIN_MBZ_CL55.gin, sound from 1st upgrade Mercedes SL 500. It revs very low (around 6000 rpm). How many elements does the GIN have? Only 130. 50 less than Murciélago, which hits around 8000 rpm on redline.

So the elements seem very important to find the right balance between GIN and ABK. It REALLY depends on the sample you use, and your tool also uses automated encoding of the file, so the element number will have to be different for the same car when reencoding with your tool. I suspect we'll need to calculate according to the formula you presented a few pages back.

Wildcard values? Where?

I misunderstood. I think you said earlier that GIN_encode used standard table values to build GIN files. Those are what I called "wildcard".

[id-daemon]

the GIN halts at the end of the sample when reaching max rpm. Why? Not enough elements!

That's impossible. No matter how many elements you have in GIN file, it always plays correctly on any rpm. The whole idea of the second GIN table is to distribute all the elements across the whole sample. And it never "bends" any sound. It just plays the right parts of the sample in loops. I did a lot of tests on that.

[Zpectre87]

That's impossible. No matter how many elements you have in GIN file, it always plays correctly on any rpm. The whole idea of the second GIN table is to distribute all the elements across the whole sample. And it never "bends" any sound. It just plays the right parts of the sample in loops. I did a lot of tests on that.

Man, you are completely right. My apologies.

The reason it sounded different was because my sample was longer than the original. After encoding a sample of same length with same number of elements, the sound works fine. (actually the new sample was slightly smaller but that's not very important)

I've personally got a wish to get my hands on those Carbon ABK samples but I've seen here in the thread that it's not very simple. Have you had any progress with them?

[id-daemon]

The reason it sounded different was because my sample was longer than the original. After encoding a sample of same length with same number of elements, the sound works fine.

I'm in doubt again. My plan was to make sample of any length playing correctly. If not, then there's no reason to make new tables, and just leave the original ones. Probably I need to do more tests, and I don't have time for this now.

I've personally got a wish to get my hands on those Carbon ABK samples but I've seen here in the thread that it's not very simple. Have you had any progress with them?

No, Carbon ABK is no problem. Another codec, but I'm familiar with it. Some other game had this codec too.

Try this

[Zpectre87]

You are great, mate! Many thanks!

I'll keep testing and reporting back.

EDIT: Here's what your tools made possible. This is the stock DB9 sound from NFS Carbon but in MW format.

Transitions between ABK samples are a bit poor. The sounds won't be like in Carbon unfortunately, because MW's engine is a bit different. I hope it's ok to post this here as these aren't "exactly" the files from the game, I edited them a bit.

[Zpectre87]

Ok... I'm not sure if ABK_insert is working right.

All my samples are 22050Hz.

I'm running the following batch (tool renamed for ease of use):

copy CAR_75_ENG_MB_EE.abk CAR_75_ENG_MB_EE.old
abkins CAR_75_ENG_MB_EE.abk CAR_86_EXH_MB_EE_01.wav 1
del CAR_??_ENG_MB_EE.abk
ren CAR_??_ENG_MB_EEm.abk CAR_??_ENG_MB_EE.abk
abkins CAR_75_ENG_MB_EE.abk CAR_86_EXH_MB_EE_02.wav 2
del CAR_??_ENG_MB_EE.abk
ren CAR_??_ENG_MB_EEm.abk CAR_??_ENG_MB_EE.abk
abkins CAR_75_ENG_MB_EE.abk CAR_86_EXH_MB_EE_03.wav 3
del CAR_??_ENG_MB_EE.abk
ren CAR_??_ENG_MB_EEm.abk CAR_??_ENG_MB_EE.abk
abkins CAR_75_ENG_MB_EE.abk CAR_86_EXH_MB_EE_04.wav 4
del CAR_??_ENG_MB_EE.abk
ren CAR_??_ENG_MB_EEm.abk CAR_??_ENG_MB_EE.abk
abkins CAR_75_ENG_MB_EE.abk CAR_86_EXH_MB_EE_05.wav 5
del CAR_??_ENG_MB_EE.abk
ren CAR_??_ENG_MB_EEm.abk CAR_??_ENG_MB_EE.abk
abkins CAR_75_ENG_MB_EE.abk CAR_86_EXH_MB_EE_06.wav 6
del CAR_??_ENG_MB_EE.abk
ren CAR_??_ENG_MB_EEm.abk CAR_??_ENG_MB_EE.abk
abkins CAR_75_ENG_MB_EE.abk CAR_86_EXH_MB_EE_07.wav 7
del CAR_??_ENG_MB_EE.abk
ren CAR_??_ENG_MB_EEm.abk CAR_??_ENG_MB_EE.abk
abkins CAR_75_ENG_MB_EE.abk CAR_86_EXH_MB_EE_08.wav 8
del CAR_??_ENG_MB_EE.abk
ren CAR_??_ENG_MB_EEm.abk CAR_??_ENG_MB_EE.abk

But, even if the samples are the same as the original, the resulting ABK still grows in size compared to the original. This doesn't happen with GIN_encode.

In the game I'm getting a "vibration" sound at high rpm acceleration. This is with original number of elements. GIN plays fine.

It's possible something is going wrong with the insertion of the samples, or it could be a compression issue. I wondered if it had anything to do with the size of the modded samples, but it doesn't. Even with original samples I still get bigger ABK than the original.

Also, sometimes the sound goes silent, mostly against the Audis.

I've attached the ABK for reference.

[V12-POWER]

I have got no sound at all. not even in free roam. and the new gin encoder is not working for me.

[Zpectre87]

I have got no sound at all. not even in free roam. and the new gin encoder is not working for me.

Syntax: GIN_encode [wav file] [rpm1] [rpm2] [elements]

Works fine here.

Elements are a mystery, it's recommended to use the number of elements the original car used.

Have you been able to successfully insert sound into the ABK? I could, but I've got that problem in the above post.

[id-daemon]

Checked your files. I need to think about it.