Jump to content
The Dark Mod Forums
Sign in to follow this  
Springheel

Changing rate to cut filesize?

Recommended Posts

That had nothing to do with one single voice actress - all the german voice sounds in this games are f*cked up because someone comprimated them in the end at a very low bitrate.

 

Another question: How does it conserve ressources if you encode the audio files? Doesn't it take more ressources because the game has to decode them everytime they are played? So it should use less ressources if we use uncompressed sounds, shouldn't it?


"Einen giftigen Trank aus Kräutern und Wurzeln für die närrischen Städter wollen wir brauen." - Text aus einem verlassenen Heidenlager

Share this post


Link to post
Share on other sites

I think D3 can handle .ogg natively, so it wouldn't have to decode or decompress them. In terms of resources, we're talking memory footprint here...so smaller file sizes would be beneficial. Plus, we set those standards for a reason. They were higher than D3 to provide better quality, but still small enough not to create a lot of bloat. Things should be consistent.

Share this post


Link to post
Share on other sites

Actually, I think Serpentine was saying, D3 decodes OGG to PCM (uncompressed) before playing them, so we only save on filesize and loading time, but memory used remains the same, anyway.

 

Technically, there is no reason to decode OGG (unless you use one of the shaking sound shaders, in which case D3 strangely only can handle WAV,even tho it decompresses OGG, anyway) because the audio API might just accept compressed OGG, but I'm note sure it really does. It is certainly easier to feed decompressed audio to the software/hardware.

 

Decompressing it on the fly can be tricky (if you want to rewind etc), but for just playing, I think there are libraries handling this already.

 

Serpentine might know more which method D3 uses:

 

* play compressed files as they are

* uncompress only the audio that should be played right now

* uncompress all audio files at load time (e.g. everything that is pre-cached)

 

And if it decompresses everything at load time, if we can change that. (If that is the case, recompressing the audio files would be unnec., it would be much better to teach the engine to keep files compressed in memory).


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites
so we only save on filesize and loading time,

 

Even if that's the case, shorter loading time is still a big gain IMO.

Share this post


Link to post
Share on other sites

It would be a good idea to limit sound effect quality to q6. (it is roughly 192 for stereo music and automatically lower for monoral vocals). This would decrease file size a bit due to the huge sounds I pointed out above, yet it would prevent TDM soundlike like crap, which is something none of us want.

 

For reference: tdm_sound_ambient03.pk4 and tdm_sound_vocals01.pk4

 

However, on any remotely modern system this is a non-issue. I was just pointing this out in the other topic as a way to skim off the top and free up more memory on low end systems.

Edited by lost_soul

--- War does not decide who is right, war decides who is left.

Share this post


Link to post
Share on other sites

Even if that's the case, shorter loading time is still a big gain IMO.

 

Only if the effect is measurable. You'd need to save at least a dozend Mbytes or more for it to make more than a second difference. So it depends.


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

Actually, I think Serpentine was saying, D3 decodes OGG to PCM (uncompressed) before playing them, so we only save on filesize and loading time, but memory used remains the same, anyway.

 

Technically, there is no reason to decode OGG (unless you use one of the shaking sound shaders, in which case D3 strangely only can handle WAV,even tho it decompresses OGG, anyway) because the audio API might just accept compressed OGG, but I'm note sure it really does. It is certainly easier to feed decompressed audio to the software/hardware.

 

Basically, yeah - SOME audio hardware will deal with OGG, but these days its very uncommon, the majority (which is still fairly small) will just decode it in software at the driver level, a tiny percent will really be done on hardware. So pretty much it's going to be done in software, the engine already has a very fast and simple decoder which is rather up to date in regards to libs. OpenAL-soft can deal with OGG, but this is just done in software too - and since it's a compile time option and you cant tell if your distro package maintainer has selected that - good luck! (This doesn't even go into the way that the game manipulates the PCM for effects like shake etc)

 

Don't get me wrong, if there's stuff which has been encoded at insane values, by all means that should be fixed - However for the sake of load time its pointless. The load time is all about textures and texture compression - about 90% of it. I have allowed s_nosound 1 to completely disable the sound system in my branch. Testing with it, I can't really see a difference in load times.

 

Speaking of that - just after you left I got everything working, still a few script functions seem a bit crashy, but otherwise it's happily running on amd64.

Share this post


Link to post
Share on other sites
if there's stuff which has been encoded at insane values, by all means that should be fixed -

 

If you can only tell the bitrate when exporting, how can I tell which files have bitrates that are too high?

Share this post


Link to post
Share on other sites

If you can only tell the bitrate when exporting, how can I tell which files have bitrates that are too high?

 

I wrote a little tool to dump all of our audio info a while back. Should still work, want me to make a table of it for you?

Share this post


Link to post
Share on other sites

Ah - forgot to give some feedback

 

Rewrote the script a few nights ago, it's outputting a lot of nice info now. I just want to remove some of the excess and make it highlight possible issues more clearly. I'll put up a basic version of the output(one big ass html table) a little bit later tonight.

Share this post


Link to post
Share on other sites

Oh, I forgot to post the link :

TDM Sound files

 

The headers should be sortable, the sorting is dumb - but good enough. The table is huge, so if it lags - don't spam click on the headers. The col 'ExtraInfo' contains any other metadata found in the file.

 

There are a few oggs with strange sample rates (these should be fixed to 44.1), a lot of really high bitrate stuff. In future I'd recommend finding a more reasonable level for saving out release ready oggs, but yeah. Not a huge problem or worth transcoding everything.

Share this post


Link to post
Share on other sites

Since the thread started out discussing file size, shouldn't this table include file size data?

Share this post


Link to post
Share on other sites

I think recompressing the voice sets that are currently 239.9 Kbit/sec down to 96 (128 if audio quality is a concern) will shrink the size, regardless of file size. Looks like entire sets were exported with quite a high bitrate.

 

Edit: The tdm_ai_commander set, OTOH, was exported with 22 Khz and 50 Kbit/sec, that should really be 44 Khz and 96 Kbit/sec to be consistent.


"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Share this post


Link to post
Share on other sites

Since the thread started out discussing file size, shouldn't this table include file size data?

Meh, I can add it - but it's not very handy for audio. It's also what people will look at rather than the bit- and sample rates - which are important and correlate closely with size (there is slight compression).

 

I'd need to be hacked into the parser anyway, so maybe another time. Would be useful for other asset types.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...