What bitrate are the imported audio Webm files?

0 favourites
  • 15 posts
From the Asset Store
Source File, music and art pack for Android Negotiator
  • I want to make sure the sound is high quality.

  • the doc doesn't say, but I've never had any problems with hearing any artifacts or any degradation. Judging by the file sizes I would say it's 160kbps

    of course it's really hard to tell by listening on average computer speakers. Even if you are listening on a pair of $300 studio headphones you would need the to do an A/B comparison to notice a difference.

    I had a song that I imported and here are the file sizes...

    wav = 13MB

    m4a 192kbps = 1.8MB (converted this one myself)

    webm = 1.0MB

  • Nepeo might know (he wrote the encoder), but it looks like we use the FFmpeg defaults. You can also check the codec of the resulting files with tools like MPC-HC, which after encoding a test track shows an overall bitrate if 119 kb/s. So presumably it's aiming for around 128kbps with VBR. Opus is a modern high-quality codec and sounds better at low bitrates, so I'd guess that's equivalent to 160-192kbps AAC.

  • It's encoded with a variable bit rate and a target of 96Kbps. Compression level of 10, with 10 being the highest quality and slowest to encode. These are the default encoding settings for libopus with ffmpeg ( which is what the audio encoder uses internally ). There are various tools for checking the quality of an audio file, such as ffmpeg, which you could use to find out more about a particular file.

    Opus is generally considered one of the higher quality audio codecs. You can see a table comparing relative performance of Opus at different bitrates on this page.

    We certainly haven't had any complaints about the quality of the audio encoding or the size of audio files that I'm aware of. If we wanted to provide users with the option of reduced size or increased quality we probably could. Although we would have to modify how the audio encoder dialog worked, and likely make it more complicated. Create a feature request if this is something you'd like to see.

  • Thanks for the info, I suppose I can just encode them in the right format at the bitrate I need, I think they should pass through C3 without being filtered again.

    Yeah might be a good idea to have a setting for how compressed you want the audio.

  • Out of interest, can you actually hear a difference? I'd expect that unless you play the game audio through a good hifi/studio headphones, it would be hard to tell any difference.

  • Ashley

    like I said above if you are listening on a pair of $300 studio headphones you would need the to do an A/B comparison maybe then you'd notice a difference. (A/B means, listen to the uncompressed one, then listen to the compressed one, side-by-side)

    but a player that never heard the audio before will NOT have a clue.

    However that being said I would recommend giving the developer the option to change bitrates. The graphical equivalent would be like forcing the developer to save all their art as JPEG with moderate compression.

    But the difference is: people's hearing is usually way more forgiving than their sight - hence how some people commonly play with the sound OFF. You don't hear of too many people playing games with their monitor off!

    Giving the dev the option to choose their own bitrate would really just be a "quality of life" issue for a developer.

    Here's a good article: lifehacker.com/does-bitrate-really-make-a-difference-in-my-music-5810575

  • Well I decided to give it a whirl, some of the test tracks we have for the encoder/decoder are uncompressed studio recordings from a musician friend of mine. They are going to be about as clean as you can get in terms of a recording. My headphones aren't monitors(studio grade) but are more than good enough for this.

    Comparing the raw audio vs the compressed they seem nearly identical, after several listens the only thing I noted was that the guitar and brass wasn't quite as bright. Increasing the target bitrate to 128Kbps removed any noticeable difference, and increased the track size by 1MB ( 3.3MB to 4.3MB ) original track was 45MB. Testing at 512Mbps gave no noticeable difference between it and 128Kbps and increased the size to 15MB.

  • Nepeo - if it's easy to add an option for this (i.e. just a dropdown that forwards a bitrate parameter to ffmpeg) it might be worth including, both because you could increase the bitrate for better quality, but also so you can actually reduce it further and save on the download size. In particular if a game is played on mobile speakers or earbuds a game could probably get away with pretty low bitrates. Maybe the range 48-160 would be reasonable.

  • It's quite easy to pass the value into the encoder, the dialog is already capable of encoding files to given bitrate but lacks the UI components for the values to be changed. Allowing different bitrates does require some rethinking of how the dialog works though. I'm tempted to say we just give users all the settings and add some advisory labels. Might be that people want to include low quality voice clips, in which case 6-8 Kbps is fine.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Nepeo

    My headphones aren't monitors(studio grade) but are more than good enough for this.

    Increasing the target bitrate to 128Kbps removed any noticeable difference

    you can't say it doesn't make any noticeable difference with subpar headphones. The frequencies are not being properly represented. Also the audio itself matters since not all audio uses the same exact frequencies, so in testing you should use a wide range of audio; sound effects and music.

    Is this whole process splitting hairs? well sort of yes, as I said it's incredibly hard to hear to the untrained ear. But if you are going to do it, might as well do it right...

  • I think in the specific case of the gaming market, it's unlikely that most players will be audiophiles with studio-quality audio equipment. However I suppose it's nice to have the option for music-focused games.

  • I have Sennheiser HD 650 headphones and am not much of an audiophile, I do occasionally notice differences that music sounds a lot worse on things like youtube and spotify though.

    Can't notice a difference at the moment with my game, I was surprised given how small the files were.

    It's great to have the option though, especially since I'm not doing mobile development, thanks everyone!

  • jobel

    you can't say it doesn't make any noticeable difference with subpar headphones

    It was purely anecdotal, at no point did I claim I was performing a definitive test. Your right that me spending 30 minutes listening to short sections of 1 track isn't a completely representative test of an audio format. But I think perhaps any higher level of testing is probably overkill for what we were trying to decide. As a recreational guitarist I like to think my ear is fairly passable and I used a fairly nice pair of sennheiser on ear headphones. So I was probably able to discern more of a difference than the average person would. If you would like to look into it more xiph publish very detailed reports on their work with opus.

    All this is by the by though, as I was arguing for adding the option to the dialog. I think 96Kbps is likely fine as a default value, but we can allow users to choose higher or lower as they like.

  • Nepeo

    It was purely anecdotal, at no point did I claim I was performing a definitive test.

    I didn't think you were.

    As a recreational guitarist I like to think my ear is fairly passable and I used a fairly nice pair of sennheiser on ear headphones. So I was probably able to discern more of a difference than the average person would.

    no offense, but a recreational guitarist is not the same as someone who has done extensive audio ear training. I was merely suggesting that it's difficult to hear what you don't know is there. Meaning that yes, equipment has its definite limitations AS WELL AS there is a certain training that goes into critical listening. So it seemed like you were running a quick test as an example, and since you are the one that would be working on it I was trying make a point of: you don't know what you don't know -- but I wasn't trying to make a big deal about it. (Please don't read anything overly negative into my posts! ;-)

    As far as it being "overkill". I somewhat disagree. Again to compare it to graphics, I think it would be completely unacceptable to force a compressed JPG format on all images where 99% of people would not see any artifacts.

    I think you do it for the developer - not for the players. I think it's important that the developers feel like their work is being represented properly. A game engine like Construct you have devs doing it all: art, animation, sound, music, game design and coding. When the devs produce assets, they are creating the uncompressed version, so when it goes into Construct, they might see/hear the difference. And if you subscribe to the notion that games are art, then you have to give full control to the developer and not hinder any of their creative work. It's impossible to predict what someone may someday make that might expose this limitation.

    tl;dr - on principal I think we should let devs set their own audio bitrates.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)