Jump to content

fabio

WFG Programming Team
  • Posts

    1.055
  • Joined

  • Last visited

  • Days Won

    12

Posts posted by fabio

  1. It's generally wiser to use the queries ( http://trac.wildfiregames.com/query ) as they're more flexible. That said there might be more queries we could create links for and post in different places, like the one searching for simple linked from here: http://trac.wildfiregames.com/wiki/StarterTasks

    OK, however the keyword are not standardized (as milestones, components, ...) and thus visible on the trac, so one should know what are the keywords available (review, simple) to use them.

    It was superseded by the later page yeah.

    I added a note about that.

  2. 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)

  3. 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.
  4. 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?

  5. There is a new package in the PPA today but it seems it doesn't fix the problems:

    • it's still built from the svn (i.e., providing the uncompressed textures rather than public.zip);
    • for some reason the 0ad source package is over 410MB in size (adding to the 166MB of 0ad-data) when it should be about 5MB, sice it includes all of this:
      348M	binaries
      3,7M build
      36K debian
      344K docs
      466M export-unix
      101M libraries
      12K license_dbghelp.txt
      20K license_gpl-2.0.txt
      28K license_lgpl-2.1.txt
      4,0K LICENSE.txt
      4,0K OpenLogsFolder.bat
      4,0K README.txt
      14M source


    • the Depends of the 0ad package should be updated to:
      0ad-data (>= 0.0.0+r08413~), 0ad-data (<< 0.0.0+r08414~)

      to avoid mixing 0ad/0ad-data with different versions;

    • Also the binutils-dev Build-Depends is no longer needed.

×
×
  • Create New...