Game size and audio quality

[fabio]

Audio files (.ogg) currently take 63MB of 143MB in public.zip. Since game size is a concern (see ticket 671) they could be optimized a bit.

Some sound or ambient files like:

audio/attack/weapon/arrowflymulti_21.ogg
audio/ambient/weather/rain_12.ogg
audio/ambient/weather/windstorm_11.ogg

are using a lot of space for no reason since these files are all 2 minutes length and just repeat themselves all the time. These could be truncated to a lesser length to save many MBs.

Also the ogg files all appear to be encoded with many different bitrates (from 45kb/s to 320kb/s), settings (i.e. without the recommended quality (q) setting) and vorbis codecs (some also with the old and lower quality libvorbis 1.0). EDIT: you can use ogginfo on the ogg files to view all this settings.

Ideally they should all be encoded with the current best vorbis encoder. Actually this appears to be latest aoTuV (see Vorbis Encoders wiki page on xiph.org and Recommended Vorbis Encoders wiki page at hydrogenaudio.org and Vorbis on Wikipedia).

Also the bitrate should be standardized, a q0 (64kb/s) should give a good quality, but I suspect that with q-1 (48kb/s) no one will notice any difference unless you concentrate on the music (rather than on gameplay) and you have expensive headphone. Also lower bitrate files should use less CPU.

Obliviously the re-encoding must be done using the original uncompressed file. Eventually these file should be stored in FLAC format in the SVN and new ogg files could be encoded when a better encoder is released, something like what's currently done with the texture files.

What do you think?

Edited May 19, 2012 by fabio

[Ykkrosh]

Makes sense to me - it'd probably be technically very similar to how we handle textures. Rather than adding a dependency on FLAC we could probably just put very high quality (e.g. 320kbps 48000Hz) Vorbis files in SVN, since I expect that shouldn't cause any noticeable degradation after re-encoding (does anyone have reliable facts about this?). Then we can easily experiment with different bitrates (maybe higher for music than for speech, etc) and re-encode everything automatically for distribution.

Apart from the minor downsides of increased SVN download size and some more code to write, I can't think of any real problems this would cause, and it would give us much more consistency and control over release size vs quality, which would be good.

Probably the best approach to getting this done is to start by telling people to put very-high-quality Vorbis files in SVN, and see if we can find higher-quality versions of the existing music tracks. The game will continue to load them as normal, and when we've got enough to make it worthwhile we can add some code to re-encode for distribution.

[fabio]

Rather than adding a dependency on FLAC we could probably just put very high quality (e.g. 320kbps 48000Hz) Vorbis files in SVN, since I expect that shouldn't cause any noticeable degradation after re-encoding (does anyone have reliable facts about this?).

Many have found that reencoding from an already lossy-compressed file degrades noticeably the quality, no matter what the initial format/bitrate was. It has been discussed many time at the hydrogenaudio forum.

EDIT: Some (outdated) information about transcoding:

https://secure.wikimedia.org/wikipedia/en/wiki/Transcoding

http://wiki.hydrogenaudio.org/index.php?title=Transcoding

Then we can easily experiment with different bitrates (maybe higher for music than for speech, etc) and re-encode everything automatically for distribution.

Apart from the minor downsides of increased SVN download size and some more code to write, I can't think of any real problems this would cause

There should be no need to write any code. A media svn tree could be set up outside the development trunk containing FLAC (and eventually video) files (alternatively it could be a standard HTTP served directory rather than an SVN tree). Music audio composers generate a FLAC file that is put into this tree. Then a simple script is used to convert the FLACs to oggs that can then be moved to the development svn as usual. Edited November 18, 2010 by fabio

[kinetik]

64kb bitrate for music is too low. ok for speech and some sound effects maybe but not music.

I usually encode oggs at 48kHz at quality level 7 vbr. Which gives an average of 230-240kb/s and a filesize of just under 2mb for a 60 second clip.

Flac at 50% compression turns a 50 second clip into a 9.3 mb file with a bitrate of 1563kb/s from a 23,5 mb .wav at 3072 kb/s

In ogg that same file ends up being a 1.4 mb file with a 224 nominal bitrate at, for most people, no noticable loss of quality.

Edited November 23, 2010 by kinetik

[fabio]

64kb bitrate for music is too low. ok for speech and some sound effects maybe but not music.

I usually encode oggs at 48kHz at quality level 7 vbr. Which gives an average of 230-240kb/s and a filesize of just under 2mb for a 60 second clip.

Flac at 50% compression turns a 50 second clip into a 9.3 mb file with a bitrate of 1563kb/s from a 23,5 mb .wav at 3072 kb/s

In ogg that same file ends up being a 1.4 mb file with a 224 nominal bitrate at, for most people, no noticable loss of quality.

Hi, what vorbis encoder are you using? Did you do a blind ABX to justify that bitrate? As noticed at hydrogenaudio wiki page:

Most users agree -q 5 (160 kb/s) achieves transparency, if the source is the original or lossless.

Note that that wiki page is a bit outdated, with newer vorbis encoder many found that improved, and transparency means indistinguishable from the original (see wiki page). Also check the threads at hydrogenaudio forum.

If you don't compare closely against the original you shouldn't notice any artifacts also at a lot lower bitrates. I really can't tell the difference with my headphone at 48kb/s. Also consider that when gaming you concentrate on the game and not on sound quality. Also I found that at the same low bitrate (32 kb/s) musics sound much better (still can't notice any obviuos distortion) than sound effects (noticeable distortion). That doesn't surprise me since codecs are usually designed for music rather than sound effects.

If you really need q7 maybe you are using an old vorbis encoder (eventually also a not AoTuV one) or you encoded the file from already compressed ones. Or maybe you just have expensive headphones and very good hears .

EDIT: I checked with ogginfo the file you posted at http://www.wildfiregames.com/forum/index.p...ndpost&p=213837 and yes, you are indeed using an old and not AoTuV encoder:

Vendor: Xiph.Org libVorbis I 20040629 (1.1.0)

Edited November 24, 2010 by fabio

[kinetik]

I didnt look at the version to be honest. This one came with Adobe Audition which i use to convert wav files to mp3, ogg, or whatever.

The quality 7 is a default value, i never really bothered lowering it . When i'm home again (at work now) i'll have a look and try some more settings.

And yes, i do have good headphones (Sony MDR-7506

[fabio]

Is there any news about this? Should I open a trac ticket for it?

[Ykkrosh]

Given the suggestion in post #3, there's a new SVN tree for lossless files (currently the only ones are in music/), with a directory structure mirroring the main SVN one. I think the rough plan is that new audio files should be added there as well as manually putting .oggs in the main SVN, and that's about all for now, but it means in the future we can re-encode as necessary to improve quality/size.

[2Ray]

May or may not fit the topic.

But at least for the linux users it will help to split the 0ad-data package. So you don't need to download 139 MB everytime an new revision is packaged ;-)

Maybe in 0ad-data, 0ad-sounds, and 0ad-maps. But that won't work with that single puplic.zip file, right?

[Ykkrosh]

Do you mean it's a problem with each new alpha release, or with the frequently-updated 0ad.dev Ubuntu packages? Alpha releases will probably change files in every area so you'd have to download everything anyway. Maybe it could help with 0ad.dev, though I imagine it'd be hard to keep all the split packages in sync (without being able to bump all their versions to a consistent number, since that would force a re-download), and if you want to keep up with frequent changes then maybe using SVN is better

public.zip shouldn't be a problem - the engine will load every .zip file it finds in that directory, so we could just split it up into multiple ones.

[2Ray]

Oh well I was talking about the 0ad.dev ppa. Every two months one hundred-and-so-what MBs for the new Alpha won't be that problem. But the same every couple of days... projected to one month I'm waiting certainly over an hour just to install all the updates. Far to long to seeing all the new cool things you come up with :-)

[fabio]

Given the suggestion in post #3, there's a new SVN tree for lossless files (currently the only ones are in music/), with a directory structure mirroring the main SVN one. I think the rough plan is that new audio files should be added there as well as manually putting .oggs in the main SVN, and that's about all for now, but it means in the future we can re-encode as necessary to improve quality/size.

Nice! I suppose that:

• celts_peace_1.ogg
• hellenes_peace_1.ogg
• iberians_peace_1.ogg
  

are the ogg versions of the .wav available in the audio svn. They are using about 9,3MB and are encoded with libVorbis I 20050304 (1.1.1) and a nominal bitrate of 160Kb/s.

It would be interesting to recode them from the .wav (supposed that the .wav are not transcoded from the .ogg) with latest aoTuV Beta6.03 using q-1 quality (48Kb/s nominal), it should save about 6,5MB, and see if someone is able to notice any difference.