8-bit hiss

Let me get this straight:

You have a
16-bit, 44.1 kHz PCM
format audio file, and you want to convert this to a
8-bit, 22.0 kHz PCM
format in order to save space in a Flash game. You want to do this in such a way that you avoid the "hiss" that this conversion introduces.

Correct summary? If so...

Short answer: If I understand you correctly, then this conversion is a bad idea. If file size is your concern you'd be better off keeping a high sample rate and using MP3 compression for instance. I've studied signal processing but haven't done anything with Flash in many years; can you do this?

Long answer: The conversion you're doing introduces two kinds of error.
1. The sample-rate conversion (44.1 kHz to 22.0 kHz) either eliminates or aliases down high frequencies, depending on how it's implemented. The net result is essentially a lack of treble.
2. The sample size (16 bit to 8 bit) conversion introduces quantization noise; I expect this is the hiss you're talking about. You might be able to reduce it with filtering, but really this is inefficient from an information-theoretic point of view.

Thanks for your response.

Quote:

Original post by Emergent Let me get this straight: You have a 16-bit, 44.1 kHz PCM format audio file, and you want to convert this to a 8-bit, 22.0 kHz PCM format in order to save space in a Flash game. You want to do this in such a way that you avoid the "hiss" that this conversion introduces. Correct summary?

For the most part, yes. I did some recording from my hard synth and am using library sounds in combination.

I have about 2MB for all music and sound effects including main menu music, ambience, stage music and ending/credits. I think I have found a solution, however, in order to avoid the hiss. I'm going to bounce down to 16-bit depth with 22khz sampling rate but with lower quality conversion. I did lose quite a bit of treble and there's some unwanted compression, but it's FAR better than the prevalent hiss from 8-bit.

Additionally, I don't have the .dll installed to convert to mp3 from PTLE, so I'm doing even more compression via another program. The loss is problematic from a musical standpoint, but from an execution standpoint, it almost seems necessary. The benefits of space saving outweigh sonic loss. I was able to secure that sound effects take under 25% of total space in order to make this happen.

As you mentioned, I'm going to avoid filtering since I don't have an external filter (hardware or software plug-in).

Thanks for your help!

Wait, are you down-sampling the wave file, and then converting to MP3 with an external program? From what I understand of MP3s that is pointless and just damages your sound quality without saving any space. MP3 encoding breaks each tiny section of music down into the most important frequencies and saves them, and the higher the bitrate of the output file the more of those frequencies it preserves (thus giving better reproduction). Downsampling before this compression process only serves to remove upper frequencies and add audible artifacts into the mix, which is likely to yield barely any improvement in space but cause significant loss of quality.

What you should probably be doing is pushing the absolute best sound quality you have to your mp3 encoder, and adjusting the encoding parameters to suit the output size of mp3 that you want.

Kylotan,

This is great advice, thank you. I will experiment tonight with this approach and let you know my findings.

I just read - 1 min of 22khz/16-bit stereo wav = 5.87MB, 1 min 44khz/16-bit stereo wav w/ mp3 encoding = 1.87MB, but sounds better :) Boy I love the internet!

Here's a follow-up question. I have roughly 6-7 min of music that needs to be fit within 1.5-1.7MB of space. What would your approach be to save the most space while retaining quality?

Thanks for your insight!

George

That comes out to about 9.2 kbps, far too low for decent quality music even with the best compressors available today. Basically, it's not gonna fit, period. As I see it, you have a couple of options:

1. Much shorter, looping music clips. If you do a few tracks that can be layered on top of each other, and have a good composer to do them, this can get great results. Take a look at Auditorium for an example of music layering in Flash, though of course it doesn't need to be so explicitly game-driven.

2. Rethink your space requirements. You don't need six minutes of music downloaded to play the first minute of the game. Streaming can work great here.

Sneftel, thanks for your assistance. I actually am the composer and am showing my green status with these approaches, so I appreciate your candor with regard to options :)

Perhaps some more information would help as well:

The programmer is having some implementation issues and when I asked him about the issue, he replied:

"its not just actionscript I am using you see, its a framework on top of that where the only compatible audio I have managed to get working so far are mp3s in those sample rates." (referring to only 44khz/22khz sample rates)

I was able to successfully compress the audio within those parameters (using 22khz sample rate), but the programmer ran into another issue:

"When ever i try to embed the sounds into the game the compiler freezes and wont let me do anything, I have to shut everything down. I have never come across anything like it before. I tried to just added them one a time but still a problem. It even happens when I am not trying to play them am just trying to load them into memory. Really have no idea what could be causing this."

Do any of my savvy programming colleagues know of any issues with implementing audio files with various bit rates or are there bit rates that aren't compatible?

Thanks again for all of your insight. This is much appreciated.

My first thought is that you need a programmer who takes responsibility for code rather than forcing his content creators to jump through hoops. But I guess you go to war with the army you have.

Flash's MP3 integration is pretty black-box: you hand it an MP3 file and it plays it for you. So the problem is certainly specific to whatever framework you're using, trying to be clever with preprocessing of assets. Using whatever forums or other support resources are available specifically for that framework would be the most productive avenue. And as I said, this is the sort of thing that the programmer should be taking responsibility for himself.

I discovered that the programmer is using a framework called Flixel, which, looking over the website, could not find any immediate information. I was informed by a fellow composer that it might be the mp3 encoding software that is causing problems, so I will give another program a shot.

Thanks for all your feedback. Troubleshooting is fun! :)

Not sure if you are going with mp3 or wav loop, but I recently did some gigs for flash games and discovered that mp3 encoding adds a short amount of silence (like 50-100ms i think) at the end of the track. This makes seemless looping a bit difficult.

I got it working from this article:

http://www.compuphase.com/mp3/mp3loops.htm

OGG doesn't have this problems, but flash doesn't support OGG.

Hey Jay,

Thanks for the cool resource. I'd like to share one with you, too. It's an mp3 trim program (free, yay!) that you trim the mp3 directly.

http://www.mptrim.com/index.html - I just started using this. Be careful, when you hit Save, it rewrites over the old mp3 file and you can't go back if you missed something. You can create a new file, however, by hitting "save as" just like any other program. Also, I found that you have to trim in "Samples" instead of "Seconds." "Seconds" does not allow you to remove sound in milliseconds. I discovered that 2 samples on the front end and 2/3 samples at the back end of the file gets rid of that padding just enough to make it unnoticeable.

Thanks for the tip!

George

Cool thanks I will check it out

The issue has been fixed! It turns out there was a problem with the mp3 encoding software. Here was my original process:

Bounce from PTLE 22khz/16-bit mono aiff -> Bounce to OGG from Audacity -> OGG to mp3 converter (with no control over bit-rate) -> mp3 quality reduction to save space

Already, I look back and laugh at my inefficiency. Here's the new process:

Bounce from PTLE 22khz/16-bit mono aiff -> Encode to mp3 via Switch (40kbs bit-rate)

PTLE lets you bounce to a lower-quality conversion rate for 22khz sampling, so I was able to save using half the amount of space from its 44khz counterpart.

Thanks to everyone for sharing their thoughts. Troubleshooting is always fun when you can share your grief with all those around :)

Take care,

George

Is the final MP3 actually twice as small when you start with a 22KHz file as compared to a 44KHz file? My guess is that it would be identical in size, given that you specify a 40Kbps output anyway.

*smacks head*

Oh Kylotan, if I only just read your previous post more carefully. You know, I work at a university where students are given advice of all stripes on how to be a successful student and, yet, they don't listen until it's too late. Sometimes you just have let the student fall flat until they learn.

I'm going to go back to the drawing board again and work on this conversion and see what happens. My suspicion is that you'll be right and I'll end up with higher quality files. Everybody wins!

Thanks for your patience and not sending your virtual insults my way. :)

Take care,

-George