19 replies to this topic

[Sam.]

When analyzing all the audio files in vanilla IE games (BG1: ToSC, BGII: ToB, IWD: TotLM, and PS:T) I noticed that THUNDER3.WAV is hosed in vanilla Tales of the Sword Coast.  I have un-hosed it without altering or degrading the original audio data, but doing so required specific knowledge of the WAVE file format, which I wouldn't think is typically in the purview of most modders.  My question is:  do any of the fixpack/unfinished business/content restoring mods restore this file, or would this be something new?  Running a --change-log (PS WeiDU (Un)Installer can also do change-logs) on THUNDER3.WAV in a mega-modded BG1 game would be a convenient way to check...  I can hit the major suspects, but there are an awful lot of mods out there...

 

Thanks for any insight you can provide,

Sam.

[Miloch]

That file appears hosed in both BG:EE and BWP, so I'm sure we'd appreciate a fixed version (also a --change-log doesn't show anything's touched it beyond BGT copying it originally). NI doesn't show that it's used; maybe it's hardcoded to weather or something?

 

If something's amok in the header, is it possible just to patch the file, or does its hosing go beyond that?

[Sam.]

NI doesn't show that it's used; maybe it's hardcoded to weather or something?

I checked the same thing. My guess is that it is hard-coded to weather, if it is used at all.

If something's amok in the header, is it possible just to patch the file, or does its hosing go beyond that?

It is just the header that is messed up, making it fairly straightforward to patch with WeiDU if you know what you are doing. Here are the repaired and original versions that can be diffed:
 Repaired.rar   18.46K   363 downloads

[Tash]

Hmm, for some reason 7zip refuses to open your rar, so I can't check this one out.

Sam, do you have some kind of an audio mod in mind? I'm always interested in those!

Anyways, I have no idea how to "unhose" a wav like this; importing as raw data into Audacity produces noise. A lot of noise. Do I need some kind of a header editor?

[The Imp]

I checked the same thing. My guess is that it is hard-coded to weather, if it is used at all.

Or it could be that the game lags a lot if it's used but not actually usable... ambient sounds bug in BGT ???

[Miloch]

Or it could be that the game lags a lot if it's used but not actually usable... ambient sounds bug in BGT ???

If so, you would probably only notice such lag in a lightning storm. Have you? It could be it's also unused, but there's no reason not to fix it so that it *can* be used. Which turns out to be quite easy with some elementary WeiFU.

 

From the command line (have weidu.exe and both of Sam.'s wav's in your game folder):

weidu --cmp-from thunder_original3.wav --cmp-to thunder3.wav --out thundiff.txt

This produces a patch file with:

COPY ~thunorg3.wav~ ~thunder3.wav~
// patches to turn [thunder_original3.wav] into [thunder3.wav]
    WRITE_BYTE 0x6 0 // 0x00
    WRITE_BYTE 0x7 0 // 0x00
    WRITE_BYTE 0x11 0 // 0x00
    WRITE_BYTE 0x12 0 // 0x00
    WRITE_BYTE 0x13 0 // 0x00
    WRITE_BYTE 0x15 0 // 0x00
    WRITE_BYTE 0x17 0 // 0x00
    WRITE_BYTE 0x1a 0 // 0x00
    WRITE_BYTE 0x1b 0 // 0x00
    WRITE_BYTE 0x1e 0 // 0x00
    WRITE_BYTE 0x1f 0 // 0x00
    WRITE_BYTE 0x21 0 // 0x00
    WRITE_BYTE 0x23 0 // 0x00
    WRITE_BYTE 0x2a 0 // 0x00
    WRITE_BYTE 0x2b 0 // 0x00

We can shorten this a tad by concatenating adjacent WRITE_BYTEs to WRITE_SHORTs:

COPY_EXISTING ~thunder3.wav~ ~override~
  WRITE_SHORT 0x6 0
  WRITE_BYTE 0x11 0
  WRITE_SHORT 0x12 0
  WRITE_BYTE 0x15 0
  WRITE_BYTE 0x17 0
  WRITE_SHORT 0x1a 0
  WRITE_SHORT 0x1e 0
  WRITE_BYTE 0x21 0
  WRITE_BYTE 0x23 0
  WRITE_SHORT 0x2a 0
BUT_ONLY

I have not tested the result, but feel free to do so and report.

[The Imp]

Erhm, so is there any plans for this that anyone has come up with ? Or a conformation that a fix for it is out already ?

Case the BG2Fixpack could use this, or Unfinished Business or even the Almateria's Restoration Project. Or all of them, cause it won't matter if more than one had it, if the patch is made so that it checks that the file is bad, with something like... and preferably with more than one check, but here's one:

READ_SHORT 0x6 ~nonzero~ 
PATCH_IF (nonzero != 0 ) BEGIN

[Miloch]

There is no existing fix for this; I already checked that above.

if the patch is made so that it checks that the file is bad

BUT_ONLY already accounts for that (WeiDU won't patch the file if those WRITEs don't change anything). You could put more checks in, but WeiDU is so fast these days, it's not really worth it.

[The Imp]

BUT_ONLY already accounts for that...

Erhm, but only if the files are exactly the same... but what happens if the Imp goes and replaces the file with a working one and then this patch is applied to that file? Could it ruin the file ? You would hate it that happened too. This is why there should be more than one condition... and at least one positive check rather than all negative ones.

Edited by The Imp, 12 December 2014 - 03:32 PM.

[Miloch]

BUT_ONLY already accounts for that...

Erhm, but only if the files are exactly the same... but what happens if the Imp goes and replaces the file with a working one and then this patch is applied to that file? Could it ruin the file ? You would hate it that happened too. This is why there should be more than one condition... and at least one positive check rather than all negative ones.

No, they don't have to be exactly the same. If you replaced your file with e.g. Sam.'s above, the patch will do nothing whatsoever (at least that's the theory; like I said, I didn't test it).

 

BUT_ONLY_IF_IT_CHANGES True only if the file is actually changed by patching actions. Unlike all other when clauses, this one is evaluated just before the result would be written out to the disk. You may use BUT_ONLY as a synonym for BUT_ONLY_IF_IT_CHANGES.

[aqrit]

I agree with Jarno,
It seems dangerous to blindly write over the RIFF chunk headers & PCMWAVEFORMAT structure.

COPY_EXISTING ~thunder3.wav~ ~override~
	READ_LONG 4 riff_len
	PATCH_IF( riff_len > SOURCE_SIZE - 8 ) BEGIN
		// todo: patch
	END
BUT_ONLY

@Tash
http://www.rarlab.com/rar_add.htm

Edited by aqrit, 12 December 2014 - 10:04 PM.

[Sam.]

Hmm, for some reason 7zip refuses to open your rar, so I can't check this one out.

You will need something that can open a WinRAR v5 archive, like the latest version of WinRAR.

 

As for who/where this can and should be used, I have found no other such corrupted audio files in any of the other IE games, so there isn't nearly enough content for a stand-alone audio mod.  With that being said, anyone and any mod that wants to include or use my repaired file, or create a patch derived from it, has my permission to do so (with or without crediting me, although credit is nice ).  The Unified Whatever Fixpack and Unfinished Business are two likely candidates that came to mind, but like I said, any mod that wants to include it can.  For that matter, Beamdog is encouraged to convert it to OGG and include it in BG:EE.

[Tash]

Maybe it's just bad luck, but I couldn't hear "THUNDERx" sound effects during storm/rain. Instead, both BG1 and BG2 play "AMB_E13x" at random; these are better quality.

[The Imp]

Maybe it's just bad luck, but I couldn't hear "THUNDERx" sound effects during storm/rain. Instead, both BG1 and BG2 play "AMB_E13x" at random; these are better quality.

But you are never able to hear it cause the file is damaged ... the fact that the file is damaged also might account for the reports that some people over the years have made that show lag in the case the ambient sounds are not turned off, on different setups, while others don't experience it at all. The reports mostly constraint to the BGT(-weidu) and for example the Gnoll Fortress, while also a few parts of the rest of the cost area. Especially during rain.

...

But the BUT_ONLY doesn't cover the amateur kind fix which just for example could take the thunder2.wav and paste it as thunder3.wav ... which is the point I was trying to make, the check needs to be able to positively identify that the file needs the fix, or at least that it won't break already made fix, what ever the level of trickery used. PS, the example is hypothetical, I don't even know if the thunder2.wav -exists, and you should understand that it doesn't really need to.

Edited by The Imp, 02 January 2015 - 09:07 AM.

[Tash]

I didn't drink, Imp ; I was sober during the tests, so I copied Sam's fixed file to my BG1/BG2 overrides. None of "THUNDER2," "THUNDER3" and "THUNDER4" are played during the weather effect; a set of five "AMB_E13x" lightning sound effects are played. I'm trying to find out where and when these files are used, but chances are they're just leftovers.

[Tash]

I've recently played through BG1, so I'm pretty sure these "THUNDERx" sound effects are never played.

 

I have an idea, though. If you combine the duration of all three sound effects, you get 18 seconds. How long does it take for Call Lightning to strike a random enemy? 18 seconds (it's supposed to be 1 turn per description). Other than the whooping sound effect of a lightning strike, there is no other indication that the spell is currently in effect. While this sounds cool and adds an element of surprise, perhaps some would like to hear these unused sound effects in the background to simulate more "natural" phenomenon (Druids!)?

 

I've tested a little bit, and this works by simply applying some gain to these audio files (they're too quiet) and adding a set of delayed sound effect opcodes; you get to hear them seeping in the background between each lightning strike.

[Tash]

Hey Sam.,

 

Do you want to take a look at CADER09.wav (BG1)? It seems to be broken, too, but it's a WAVC this time. Just by inspecting the header in XVI32, everything looks fine... or does it?

Edited by Tash, 16 September 2015 - 02:58 PM.

[Sam.]

Hey Sam.,

 

Do you want to take a look at CADER09.wav (BG1)? It seems to be broken, too, but it's a WAVC this time. Just by inspecting the header in XVI32, everything looks fine... or does it?

I agree it is broken, good catch .  NumSamples in the ACM Header shouldn't be 0.  Mathematically I would have thought it should be 40144, but acmtool gives a warning about having to add filler_samples.  Using 35328 instead results in that warning not being given.  In either case, I think the decoded file is audibly the same.

[Tash]

NumSamples in the ACM Header shouldn't be 0.  Mathematically I would have thought it should be 40144, but acmtool gives a warning about having to add filler_samples.  Using 35328 instead results in that warning not being given.  In either case, I think the decoded file is audibly the same.

Ok, I didn't look at the ACM header. Yep, you've fixed it, all right! The value of 40144 works just fine and results in a nice and clean sound. 35328, however, crashes PSgui (it still decodes the file) and produces an audible pop at the end of the audio file.

 

Thanks!

[Sam.]

Glad I could help .  If you find anything else you'd like me to take a look at, just ask!