What are the technical reasons behind not supporting MP3 files?

The file size is an order of magnitude smaller, and the loss in quality is negligible if noticeable at all. With the smaller size, you could fit 10x as many sounds in memory which would give sound designers much more power.

What are the differences between MP3 and WAV formats that prevent MP3 from being supported? What work would need to be done to support MP3?

The MP3 patent was only recently released so it’s never been a core part of the compression tech.

Instead, we use Ogg and Opus and a variety of other formats depending on platform and what kind of hardware decoding support is available.

We don’t currently support cooking uncompressed wav files (as you mentioned, compressed formats are much smaller). The ratios vary from codec to codec and depending on how you set your quality settings (which is a SoundWave parameter).

I don’t see huge savings with mp3 over Ogg, to be honest, so I don’t see it as a big priority right now. But I can see maybe in the future supporting mp3 for iOS hardware decode support.

Regardless of what new compression formats we may end up supporting in the future, it’s important to understand that best practice is to import the file into your project uncompressed and then decide on your compression quality from there. During cook, all audio is compressed.

3 Likes

Help me understand how this is so. Do you mean as it sits on your hard drive, during development or your packaged game size?

Because as I mentioned above, audio is compressed on cook into formats that are either comparable or superior to mp3 (usually Ogg Vorbis or Opus). So when you package your game, audio assets are compressed.

Do you mean during run-time? If you’re having memory issues during run-time, then you might want to look at trading in CPU for memory by making more of your sounds real-time decode. That way they don’t completely decompress the whole sound on load.

I appreciate that there are a lot of free sound libraries or open sound libraries that archive their sounds in lossy formats like mp3, and I think that’s a good reason to eventually support a wider variety of formats on import. But I don’t quite understand the memory bloat complaint.

2 Likes

That’s an interesting problem and I appreciate it deeply since some of our projects here at Epic can mean 200+GB perforce sync’s.

Ogg Vorbis (and other compression formats) are employed during the cook process.

This is relevant to packaging, but in the Editor, during development, an uncompressed version is stored in the SoundWave asset. This allows users to set Compression Quality levels for their game and then to change their minds later.

For example, if you leave the Compression Quality setting for your birds at 40/100 which is default and then later on, you realize that your birds should be less compressed because you’re getting some lossy artifacting in the high frequency range, then you want to be able to change your mind about that quality setting.

If you imported and stored the file in its compressed state and treated that as your original file, then you would never be able to back-track. You would only be able to lower the compression quality, never raise it.

This is why the best practice is to keep uncompressed versions of your sounds in your project until you’re ready to cook.

Our long-term road map includes expanding the formats supported for import, and along these lines, we’ve already licensed libsndfile. These will likely be the first ones we support before we get to mp3.

I think mp3 could be interesting for a project that uses user music, like a game that plays the user’s music library or something, but as a designer, I cannot advise someone to store their original sound source files in a compressed lossy format.

2 Likes

+1 mp3 and loading at runtime.
The fact that mp3 is way more popular for existing content, and there are many scenarios where you would want to load an audio file dynamically and or at runtime with ios and android. I am in that boat now actually.

I’m trying to get MP3 working and just came across this thread… The media player does in fact support MP3 and it’s possible to open a file on the users HD by using the open URL node. This makes it possible to load an mp3 at runtime, however the sound quality is horrible.

I’m getting clicks and pops, random stutters, lower volume overall and missing bass frequencies. Overall it sounds much thinner than the same file played through any other media player, even if I compensate for the lower volume by turning up my speakers.

Am I doing something wrong here or is mp3 support broken?

BTW: mp3 is not seamlessly loopable, so audio loops are not that easy to set up.

I’ll just add that A: 2020 sucks and B: when importing OGG vs WAV, regardless of how the cook compresses things, there seems to be a proportionate decrease in memory usage by using the compressed audio format in the cooked package size and amount of memory each target device used. So source audio format seems to be making a difference.

Hi,
I have recently created a plugin to import the audio files with mp3, wav, flac in runtime.
https://www.fab.com/listings/66e0d72e-982f-4d9e-aaaf-13a1d22efad1

2 Likes

If this works well (also for packaged games on all platforms) it is huge!

1 Like