As it was noted in #1142, the sound files need to be normalized (level balanced).
As long as the audio files are being edited and saved again, they should be saved in a more highly compressed file format with a better balance between quality and bandwidth. Given that our music and sounds are essentially "8-bit" I think we can potentially save a fair amount of space this way.
@bucketh3ad I'd love to know how to do this. boobatron was working on converting some of our audio into a much more compact .xm format, but I think we gave up (which isn't a surprise, it's not a fun task). I'm not sure how we would compress the audio more without losing audio quality. Remember the terrible sounding Pocket Full of Hawkthornes from a while back?
Yeah, I don't think we are going to go ahead with the .xm format.
I messaged boobatron about the music and got a little more info. While there is a definite size advantage, the main advantage of using the .xm format for the musicians is that it is much more conducive to musical collaboration, since the files contain the music data rather than audio and can be easily modified by others. The downside, as campadrenalin pointed out, is that it's more of a pain to work with in the software since it's not a typical audio file like .mp3 or .ogg.
For now, I think we should keep the existing music in .ogg, but I think it would be beneficial to use .xm for all new music as well. It's easy enough to make an .ogg version from the .xm and we still get the benefits.
As for converting the audio to a more compressed format, I converted everything in the music folder to VBR ogg/vorbis as a test. I couldn't hear an audible difference in any of the songs (though, admittedly, I didn't listen to all of them all the way through) and it took the folder size down from ~35MB to ~25MB
The downside is that ogg/vorbis, like mp3, is a lossy format, and any conversion between lossy formats will only cause further degradation. The optimal solution is for these files to be saved from a lossless master (like WAV) into the higher compression ogg/vorbis.
@bucketh3ad Every single thing you just said makes perfect sense. XM master for new songs, WAV or FLAC master for songs that are already "rendered".
Coming from an audio-noob:
If the sounds/music are supposed to be 8-bit 'tracks', isn't it safe to assume that you'll be able to compress it a lot before it really becomes apparent that it has been compressed?
Depends on the algorithm. It's basically the audio equivalent of pixel art, only none of the popular compression codecs are designed for "pixel art." Vorbis is a good codec in general though, so we get a lot of mileage out of that.
XM is more analogous to MIDI or SVG - it's the "vector representation" of the music, essentially containing a few recordings and sheet music. This is by far the most compressible format, it's already small by its nature for songs like ours. The drawback to counter this low memory footprint is that it's not very well supported. The music wouldn't play on every computer (or any browser, when we consider the HTML5 port I'm working on). So directly using XM in the game is a no-go. We'd have to render the songs out into more "normal" formats like OGG or MP3.
Rendering .xm files into .ogg files as a build step in some deployment pipeline wouldn't be too difficult. SoundConverter does just that. The real question is, how difficult would it be to recreate all our music in .xm? I know nothing about the format. My guess is that it would be pretty hard.
That's what boobatron was attempting to do, but I think he gave up because it was so hard. We'd have to ask him about it.
I have normalized and leveled all the sounds here
@napen123 Fantastic job! These all sound great
@napen123 Any way that I can download all of the sounds as a zip file?
here you go
was this automated? Because some of the sounds are clipping.
Yeah, I'm going to say that instead, we can call out specific sounds that are too loud. I just made the torch quieter. I think that is a simpler approach that trying to apply normalization to all the sounds.