Some .wavs wrongly converted to .oggs

[Springheel]

Tels, you converted some .wav impact sounds to oggs in revision 12506. I don't know about the rest, but the stone impact sounds you changed were specifically supposed to be .wav files. Any impact sounds use the "shake" keyword in their sound shader need to be in WAV format.

 

Also, I notice that you changed a number of vocals from .wav to .ogg. That's fine, but did you also change the soundshader? I've been seeing a number of "can't find random_bark01.wav" warnings in the console recently and I wonder if that's why.

[Tels]

Tels, you converted some .wav impact sounds to oggs in revision 12506. I don't know about the rest, but the stone impact sounds you changed were specifically supposed to be .wav files. Any impact sounds use the "shake" keyword in their sound shader need to be in WAV format.

 

Ah, ok, I can reverse them.

 

How can we make sure that this doesn't happen again? Maybe we can fix the engine so it can also shake with .oggs? Because we only have about 12 or so sounds in .wav, which means none of the others could be used as a "shake" sound shader.

 

Also, some of these stone sounds have a very long silent portion at the end - is this nec? (they are huge files for very little content)

 

Also, I notice that you changed a number of vocals from .wav to .ogg. That's fine, but did you also change the soundshader? I've been seeing a number of "can't find random_bark01.wav" warnings in the console recently and I wonder if that's why.

 

Ah, no, I was under the impression that the engine loads .ogg over .wav if it cannot find it (just as with .dds and .tga). If the engine does not do this, I think that should be added - it will be easier than to always fix sound shaders and make life easier for everyone.

 

I'll look into this tonight (approx. 12h from now) and fix it.

 

My apologies.

[Springheel]

I was under the impression that the engine loads .ogg over .wav if it cannot find it (just as with .dds and .tga).

 

I think it's pickier about sound files, but someone else might be able to correct me.

[OrbWeaver]

I think it's pickier about sound files, but someone else might be able to correct me.

 

That is my impression too. The DDS files are intended to be simply a cache to speed up loading, with Doom 3 otherwise creating DDS dynamically from the TGA source files (which are assumed to be there, hence the various "black texture" problems in the DDS-only released mod if image settings aren't correct), whereas OGG and WAV are two different options for the source format, without any attempt by Doom 3 to convert from one to the other.

 

On the subject of converting to OGG, some of the updated footstep sounds I deliberately left in WAV format because they were created by modifying the existing OGG sound (since a lot of sounds don't have source WAVs available), and I didn't want to introduce re-compression artifacts.

[Serpentine]

The reason is that shakes manipulates the channels directly, as such an ogg would need to be decoded and then held in memory waiting for use, using the wav skips the decoding process which decreases spikes in cpu use (back in the day, tho it's still quite intensive).

[Springheel]

One note about footsteps...I noticed that a number of Gold's footsteps were in stereo format. I wonder if that contributed to them not sounding right.

[Tels]

That is my impression too. The DDS files are intended to be simply a cache to speed up loading, with Doom 3 otherwise creating DDS dynamically from the TGA source files (which are assumed to be there, hence the various "black texture" problems in the DDS-only released mod if image settings aren't correct), whereas OGG and WAV are two different options for the source format, without any attempt by Doom 3 to convert from one to the other.

 

I don't see why D3 can't fallback on loading the .wav if it can't find the .ogg, tho. Since the engine loads and plays both formats, anyway, that should work.

 

On the subject of converting to OGG, some of the updated footstep sounds I deliberately left in WAV format because they were created by modifying the existing OGG sound (since a lot of sounds don't have source WAVs available), and I didn't want to introduce re-compression artifacts.

 

I don't think anyone could determine the difference when listening to them on PC speakers in a clean environment, and even less in-game, tho

 

Anyway, I have fixed the sound shaders using a script to detect missing files. The stone sounds will be restored to WAV in a minute. (Edit: Huh, it seems someone already did. I am getting SVN artefacts restoring them)

 

One thing I see is that we are still using lots of D3 sounds for spider footsteps etc. Guess we have some work todo in this department (But Springheels massive change is very very welcome! )

[OrbWeaver]

I don't see why D3 can't fallback on loading the .wav if it can't find the .ogg, tho. Since the engine loads and plays both formats, anyway, that should work.

 

Well it could, of course, but the intention is that you supply either a WAV or an OGG, but not both (unlike with the DDS files which mirror the existing TGA tree). So I don't think this behaviour would be useful even if implemented.

 

I don't think anyone could determine the difference when listening to them on PC speakers in a clean environment, and even less in-game, tho

 

True, but besides "feeling icky" about serial compression, there is also the possibility that if converted to OGG the sounds might in the future be un-compressed, edited and re-compressed yet again by somebody else who hasn't seen this discussion or checked the SVN history.

 

In any case, I'm not insisting that they be left as WAV, just providing the rationale for why I didn't compress them in the first place.

[Tels]

Well it could, of course, but the intention is that you supply either a WAV or an OGG, but not both (unlike with the DDS files which mirror the existing TGA tree). So I don't think this behaviour would be useful even if implemented.

 

Er, I think it would be a bit more useful than the current "I cannot find foo.wav" (while foo.ogg exists and is unused). That would certainly make things less error-prone, which would help humans (no longer do you need edit shaders just because you convert from one format to the other!)

 

Of course, I am not going to code it in if the first and only response is "I don't think it will be useful" -I have way too many things on my list

 

True, but besides "feeling icky" about serial compression, there is also the possibility that if converted to OGG the sounds might in the future be un-compressed, edited and re-compressed yet again by somebody else who hasn't seen this discussion or checked the SVN history.

 

In any case, I'm not insisting that they be left as WAV, just providing the rationale for why I didn't compress them in the first place.

 

Yeah, I got this impression from your post, my response was more the rationale why thy can stay in .ogg (and 0.4 mb vs. 3.400 mb of sounds or so was for me reason enough to convert the handful of sounds I did convert

[Mortem Desino]

Shakes just takes a random float * the shake volume. Do that 3x and it becomes an angle. Use that angle to jiggle idPlayerView. Do that every frame.

 

I took a look at the WAV vs OGGs "shakes" issue in the engine code. There's a hint in idGameLocal::DumpOggSounds

// don't OGG sounds that cause a shake because that would
// cause continuous seeking on the OGG file which is expensive

Although I don't know why volume queries are expensive for shakes but not for, say, flickering lights. It could be expensive for idEarthQuake::think because it has to also query the player's position and modify the amplitude of the shakes.

[Tels]

Shakes just takes a random float * the shake volume. Do that 3x and it becomes an angle. Use that angle to jiggle idPlayerView. Do that every frame.

 

I took a look at the WAV vs OGGs "shakes" issue in the engine code. There's a hint in idGameLocal::DumpOggSounds

// don't OGG sounds that cause a shake because that would
// cause continuous seeking on the OGG file which is expensive

Although I don't know why volume queries are expensive for shakes but not for, say, flickering lights. It could be expensive for idEarthQuake::think because it has to also query the player's position and modify the amplitude of the shakes.

 

Maybe we should just try it with a big sound file?

 

I haven't used "idEarthQuake", but why would the player position play a role? Also, wouldn't the ogg just play in one go, and so the volume also gets extracte in one go (e.g. the playing never seeks backwards?)