Volume Issues

[OrbWeaver]

In the meantime I found the culprit in my s_mindistance 0 issue: It's as easy as that, when doom sees the property is set to 0 in the map file it treats it as if it wasn't set at all. As a consequence it falls back to what the shader says. If the shader has no info as well it defaults to minDistance 1/maxDistance 10. (Yes, I tried what happens when you set maxdistance to 0.)

 

Yep, I realised this this morning in fact. If you enter a 0 value in the editSounds GUI, it falls back to the default value in the sound shader, so I guessed this was probably happening in your tests as well.

[Noisycricket]

Make sure you don't have a map loaded or the sound shader file in the darkmod\sounds folder won't be updated. Instead, a new shader file will be placed in the map directory. That, at least, happened to me when lowering some volumes.

[OrbWeaver]

Yes, if you have an FM installed and you save out changes from editSounds, it will write them to the current FM directory (e.g. C:\Games\Doom3\somefm) rather than the main darkmod directory. You would then have to copy the changed file back into the main directory if you wanted it to apply to all FMs.

[plasticman]

... in the editSounds GUI, it falls back ...

editSounds is not available in Linux, right?

[OrbWeaver]

editSounds is not available in Linux, right?

 

No, it isn't.

[STiFU]

Nice to see the sound department tackled as well. Thanks plasticman!

 

I wonder whether a script could be setup to detect faulty sounds. I am having trouble locating sounds quite often and I think I didn't have such a hard time in this aspect while playing Thief. Maybe normalizing all sounds as above would help? I know only very little about the sound propagation in TDM, so this is just a blind guess.

[ungoliant]

I'm about 100% positive that there's a cvar that will pinpoint the source of all speakers and sounds (including individual footsteps) while in the game, whether they be faulty or working. don't remember what it is though, but it was in another thread regarding sounds and visportals.

Edited November 26, 2010 by ungoliant

[Noisycricket]

Nice to see the sound department tackled as well. Thanks plasticman!

 

I wonder whether a script could be setup to detect faulty sounds. I am having trouble locating sounds quite often and I think I didn't have such a hard time in this aspect while playing Thief. Maybe normalizing all sounds as above would help? I know only very little about the sound propagation in TDM, so this is just a blind guess.

 

The approach i planned to take with some new footstep sounds im working on was to use the greatest collection of sounds already having an equal volume to test against. In other words, having a bunch of a.i. guards talking near you and figuring out how much of the footsteps should be heard while they're talking. I never did this since i didn't know of any maps having a large quantity of guards around a variety of surfaces. But anyway, it will be nice once we get this all straight so that normally near silent sounds, like exterior lamps, don't pierce thine ears...

[OrbWeaver]

It's easy enough to do in Audacity, if that's all that's needed. I've already converted them all, and I'll run a few tests to compare the volume to our existing vocals.

 

How are you exporting the .ogg files? I noticed that the bitrate is very high for all of the pro voices, on the order of 256kbps, resulting in a rather large download.

 

For vocals you probably don't need more than quality level 3 (or perhaps 4 if you want to be really sure there are no artifacts). This will result in files about 1/4 of the size.

[Serpentine]

I wonder whether a script could be setup to detect faulty sounds. I am having trouble locating sounds quite often and I think I didn't have such a hard time in this aspect while playing Thief. Maybe normalizing all sounds as above would help? I know only very little about the sound propagation in TDM, so this is just a blind guess.

 

I have a script which examines sound files(ogg/wav) and pulls out various information and metadata, the problem is however finding what criteria are 'bad'. I guess the next step is to try and decode the oggs to make sure they are well formed too.

 

But knowing things which situations need to be mono (i.e footsteps) or bitrates which lead to performance loss etc, is quite tricky to figure out and assumptions are pretty risky. So any info I can get in regards to "what I should be looking for" would be great!

 

OT : In any case I'll dump this stuff in my contrib svn directory in a few days, along with my material and texture checkers as well as editor image generator, but they're all very much WIP. At the moment I'm thinking of a nice way to get the material info and texture check/gens to work together, checking for missing/unused and problematic, generating missing editor images and updating changed ones.

[Springheel]

How are you exporting the .ogg files? I noticed that the bitrate is very high for all of the pro voices, on the order of 256kbps, resulting in a rather large download.

 

 

Just using whatever the default export values are. I don't even know what a bitrate is.

[Tels]

Just using whatever the default export values are. I don't even know what a bitrate is.

 

http://en.wikipedia.org/wiki/Bit_rate

 

Esp: http://en.wikipedia.org/wiki/Bit_rate#Audio

[OrbWeaver]

Just using whatever the default export values are. I don't even know what a bitrate is.

 

It's basically a quality scale, low bitrates == small filesize and lower audio quality, high bitrates == large filesize and higher audio quality.

 

The Vorbis encoder uses an arbitrary scale of quality values between -1 and 10, where anything over 3 is going to be pretty difficult to distinguish from the original (although hi-fi enthusiasts may want to go to 5 or even 6).

 

I suspect the export options are defaulting to maximum quality (10) in this case, hence the very large filesizes. I don't have a copy of Audacity to hand so can't immediately say where these would be configured, but are there any widgets relating to "quality" or "bitrate" in the export dialog, or anything containing a number or slider between 0 (or -1) and 10?

[Aprilsister]

Audacity has an options button right by the save button when you go to export it will ask you only what quailty you want between 1-10 defaulting to 5. Whatever happens and has already been said here keep the original wavs in the archives at the very least if not just putting them in the mod. Always keep the wavs. You can and probably should flac them up at 8 compression factor to losslessly compress but do not throw away the fidelity.

[Springheel]

I suspect the export options are defaulting to maximum quality (10) in this case, hence the very large filesizes.

 

There was no option during the export window, but I found it in preferences, and it does in fact default to 10. This will have affected all of the vocals that I have been responsible for (which is the majority, I believe). I can change the pro vocals easily enough.

 

edit: Setting it a quality of 5 reduces the vocal set from 48.6 MB to 34 MB.

[Aprilsister]

Oh sorry I was looking at my Audacity beta 1.3.11 not using my old 1.2.4. Don't know where Audacity is officially right now but have been using the beta for a good long while and its been stable by the way.

 

Anyway one thing to consider during all of this is that when you use compressed audio lossless or lossy the result is smaller files yes but the playback is not magic and each time the decompression must take place. So since d3 can use wavs it might be best to use them period. The mod will be bigger but faster as well.

Edited November 27, 2010 by Aprilsister

[OrbWeaver]

Anyway one thing to consider during all of this is that when you use compressed audio lossless or lossy the result is smaller files yes but the playback is not magic and each time the decompression must take place. So since d3 can use wavs it might be best to use them period. The mod will be bigger but faster as well.

 

Not really. The download would be massively larger, and there is no (or negligible) performance impact to decompressing Vorbis on the fly because it is limited to the playback rate of the file. The mod is big enough as it is, and if there was a performance advantage in using WAVs then Doom 3 (which is shipped on CD/DVD media) would have used them instead of Vorbis.

[Tels]

There was no option during the export window, but I found it in preferences, and it does in fact default to 10. This will have affected all of the vocals that I have been responsible for (which is the majority, I believe). I can change the pro vocals easily enough.

 

edit: Setting it a quality of 5 reduces the vocal set from 48.6 MB to 34 MB.

 

Orbweaver said that Quality 3 is almost indistinguishly from the original, so could you please run a test and see how big it gets with quality 3?

 

We don't have to save a few Mbytes, but if it drops another 10% and still sounds the same, that would be worth it. After all, the game has to load and store all that audio before you can play a map. And if we can drop a dozend Mbytes from each audio set, that would be insanely cool.

[OrbWeaver]

We don't have to save a few Mbytes, but if it drops another 10% and still sounds the same, that would be worth it.

 

According to the quality/bitrate table in the Wikipedia page (http://en.wikipedia.org/wiki/Vorbis#Technical_details), for a mono file you should get about 56 kbps with -q3 and 80 kbps with -q5 (and about 250 kbps for -q10, which is consistent with our experience). So going from 5 to 3 ought to be able to save around 40%.

[Tels]

According to the quality/bitrate table in the Wikipedia page (http://en.wikipedia.org/wiki/Vorbis#Technical_details), for a mono file you should get about 56 kbps with -q3 and 80 kbps with -q5 (and about 250 kbps for -q10, which is consistent with our experience). So going from 5 to 3 ought to be able to save around 40%.

 

Going from 10 to 5 also saved 40%. However, 56 Kbits sounds quite low to me. Maybe it is because Ogg can compress better while still sounding the same?

 

Guess we need to make a test: how big does 4 and 3 end up with and how do the sound?

[OrbWeaver]

However, 56 Kbits sounds quite low to me. Maybe it is because Ogg can compress better while still sounding the same?

 

Yes, Vorbis is more efficient than MP3. Also the sounds are in mono, so you get half the bitrate for the given quality level (a 112-kbps stereo Vorbis would be perfectly listenable in most cases).

[Tels]

Yes, Vorbis is more efficient than MP3. Also the sounds are in mono, so you get half the bitrate for the given quality level (a 112-kbps stereo Vorbis would be perfectly listenable in most cases).

 

Ah, ok, that makes sense. So, Springheel, if you ever are adventurous, please test quality 3 and report us your findings

[Aprilsister]

Fair enough Orb Weaver just wanted to make sure the point that decompression is not magic was considered. Sound is such a crucial thing and I'm glad to see it is getting a lot of attention lately because to be honest it is the one area (HEY! AN ELEPHANT!) that I think maybe TDM could be unfavorably compared to Thief.

[plasticman]

Thief is hard to beat in that field.

 

Technically TDM can do it I think. It is just a matter of fixing, tweaking and adding assets while maintaining a certain level of quality. (Tweaking being the hard part.)

 

One thing TDM can not influence is what mappers make of it, or (and there's a problem) don't make of it. I think we haven't heard half of the stuff that's already available.

 

About these compression ratios: randomly picking vocals from the 1.02 release I see a bitrate of approx. 240 kbps. Encoding one of my own vocal recordings with -q3 results in 80 kbps, -q4 in 86 kbps. In direct comparison I can make out there is a bigger difference between the .wav and q3 than between the .wav and q4. While it may not be audible for most people (depends on your hearing and your audio setup), I'd be happy if vocals were kept on a high standard.

[demagogue]

Well I got the wiki entry for the location_settings updated and cross-linked to take into account the volume issues, which if you didn't already know were also the same volume issues it was having previously that I fixed (didn't realize it was a more general issue with a lot of other things too). Now the wiki entry will let the mappers know so they don't blunder into the same problems over-maxing the volume for location ambients on their own.