I'm creating an HTML5 game. We have high fidelity composed music, in the format of wavs and mp3s— some ogg. Game engine we are using is melon JS.

The wav files are generally 3x time size of mp3s, but even loading the mp3s is by far the slowest asset to load on the web game.

I've tried compressing file mp3s at http://www.mp3smaller.com/, @ mp3 Bitrate 32Kbps which resulted in 89% reduction in file size. This significantly improves load time of the game, but it's as though we lost 89% of the quality.

Any recommendations for lossless (or close to) compression services/techniques with significant file downsize but little quality loss?

In images, I know we can take a .png and save as .jpg at lower fidelity, saving about 70-80% in space...but to the eye, it's impossible to tell.

  • 2
    \$\begingroup\$ Have you looked into potential streaming solutions, so your audio doesn't need to be fully downloaded all at once? \$\endgroup\$
    – DMGregory
    Commented Nov 14, 2018 at 14:30
  • \$\begingroup\$ The game engine, melonJs, handles asset loading. Not sure where in the docs it specifies streaming for audio...if at all. What I can control is when the assets are loaded and the size of the actual asset \$\endgroup\$
    – user3871
    Commented Nov 15, 2018 at 4:39
  • 1
    \$\begingroup\$ Searching at melonJs source found it uses howler for audio, which supports audio streaming, and melonJs initialized correctly to support audio streaming by default - as far as I can tell. Now, how about your server? The client can start playing before the download finishes (so, do not wait)... however it would still have to wait for the server to send data, the server should not wait to load the whole file in memory before sending. Better if the server support partial (range) requests, the browser handles that on the client side. That reminds me: Http/2? Http/2 preload could help you too. \$\endgroup\$
    – Theraot
    Commented Nov 15, 2018 at 5:18

4 Answers 4


When you take an audio clip which is already encoded in a lossy compression format and then re-encode it again with a different lossy compression, then any compression artifacts will accumulate and the quality will get a lot worse than it should be. This is as if you take a picture with a camera, print it, and then take another picture of the printout.

If you want to experiment with encoding your audio files in different formats and with different compression settings, then always do so by creating an MP3/OGG from the original WAV file. You will get much better results that way.

Also, different encoders might give you different results with the same bitrate. They might also provide you with further encoding parameters to experiment with. So investing some time into finding the best encoder and settings for your particular target bitrate and style of music can be worth it.

If the filesize-to-quality rating is still too bad for your purposes and you are willing to invest a lot of work into your audio system in order to minimize filesize, then you could use a trick from the demo scene: Program a system to generate your music procedurally. The HTML5 Web Audio API has become quite powerful and can be used to build digital synthesizers, sequencers and effect filters.

But if you go this route, then you can't just take any pre-made music track and drop it into the game. You will have to work directly with your composer and have them compose specifically for your system. Also, as of writing this answer, the Web Audio API doesn't work in Internet Explorer (but it does work on Edge and all other mainstream web browsers).


I will assume that you have exhausted all that may come from encoding and compression.

First off, load only what you need next, use a load scene when appropriate.

Now, what you probably want is to stream the audio, and not simply serve audio files, so that the server does not wait to load the whole file in memory to start sending data, and the client can start playing before finishing downloading. How to do it depends on the server side technology you are using. However you might not be in control of the server and working in a server that does not allow that. Addendum: streaming can still be slow.

Also, you might want to cache your audio files between sessions (ideally with the help of a service worker), so that the game can work with audio from local cache instead of asking the server every time.

Aside from that:

  1. Split your music in smaller chunks.
  2. Encode each chunk in multiple qualities.
  3. Have a measure how good the download is*, and decide what audio quality it is worth to download such that it can be downloaded fast enough.
  4. Start downloading the selected quality chunks, and switch to play those as soon as possible.
  5. If the audio happens to download too slow to be ready in time, go back to 3.

*: Measuring the download time on some asset, any asset. You might aswell download the lower quality in order to measure the download speed, which also has the bonus that the lower quality would be available to play if there was no time to download a better one. Also keep updating this measure using the time to download the chunks.

This will also allow you to provide the user with a setting to change to a lower audio quality. Users that are playing from a cellular network will appreciate it. Ah, and do not forget to provide the "no audio" option.

Addendum: People playing on a network that charges by the amount of transferred data will prefer it if your game transfers less data. Furthermore, unless the user is using headphones, the audio quality from the speakers of the mobile device is not the best anyway. Also, smaller files means less data to crunch, and less data to crunch means more battery life. I am not saying this is the case for everybody... in fact, some could be playing on WiFi, on a decent device and with headphones... but not everybody, some will prefer your poor audio quality version and appreciate you give them the option.


One option, given with reservations, is to try MIDI. Unlike MP3, OGG or WAV files, a MIDI file is not an audio recording. Instead, it is a set of instructions used to recreate audio on demand. It's sort of like having the sheet music indicating the notes, pitch, tempo, etc, rather than the music itself. Because the format, it typically uses a fraction of the space space required for the equivalent recorded audio. Before the advent of CDs, most game audio was either MIDI or some in house equivalent. For web development spcifically, there's Web MIDI

That being said, it does come with some possible drawbacks:

  • First, composing music in MIDI is its own somewhat niche skill set. As such, there's fewer pre-made off the shelf assets to choose from & finding the talent to make custom assets may be harder.
  • Second, to my knowledge there's not a particularly great way to automatically convert recorded audio into MIDI.
  • Third, again, to the best of my knowledge, it doesn't support lyrics. It can handle vocals, things like a choir singing "ahhhs", "laaaas", etc. It is my understanding that if you need actual words, they need to be layered in separately.
  • Forth, browser support may be a problem. Presently, Web MIDI isn't directly adopted outside of Chrome & Opera. Some casual searching suggests most developers work around this using the Web MIDI API Shim.
  • Lazy loading. Even if you have 100 levels with unique soundtracks, you probably don't need them all at the start of the game. You can improve user experience by having a loading screen with minimal assets, or sneakily load the first level assets in the background while the player is occupied with the game menu. Here's an example of Phaser displaying a loading animation.
  • Compression. Both high fidelity music and 32Kbps MP3 are overkill, but in opposite ways. Game audio, especially for web games, don't need to be high quality. See this answer for good ways to compress audio for games: https://gamedev.stackexchange.com/a/99121/26250

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .