Updated: 11/14/04; 8:51:05 AM

 Tuesday, October 12, 2004

Bill R.: Some very good guidelines on use of MP3 encoders. Note also the 'consideration of others' angle.

Podcaster Tips And Thoughts 004 - MP3 Encoding.



What is 'encoding'? I could go very techie here but I won't. Instead, let's consider what encoding does rather than what it is.

Encoding lets you control 1) the audio quality of your MP3 and 2) the size of the MP3 file itself. When you save an MP3 file, the bitrate and frequency and number of channels (i.e. mono or stereo) you choose to save the file in will control how good (or bad) it sounds and how big it is. Be aware that the bitrate and frequencies you can save MP3s in depend completely on the software you are using to record and / or process your audio files. Some options I mention may not be available in your software. Adjust accordingly based on your understanding of the concepts explained here.

Remember this: Almost always the lower the bitrate or frequency or channels, the smaller the final MP3 file will be. Its overall audio quality will also be lower.



Who cares? - Podcasters and their podience care because obviously you want to sound as good as possible. But even more important, you need to consider your bandwidth and the bandwidth required for the listener to get your podcast.



What is the ideal bitrate and frequency to use? - This is totally subjective. Everyone has different opinions. But there are some general guidelines I've found in my work:

1) Frequency - You can usually choose between 44,100Hz, 22,050Hz and 11,025Hz. (Your software may allow other less frequently seen options like 32,000Hz or 24,000Hz.) Notice how each one is half of the higher one (i.e. 22,050 is half of 44,100). It generally works out that saving an MP3 at 22,050 will result in the file being 1/2 the size of one saved at 44,100. And one saved at 11,025 will be 1/2 the size of one saved at 22,050.

For spoken word podcasts 22,050Hz is the sweet spot. It does not sound as crisp and clear as the same file saved at 44,100 but the tradeoff is negligible considering the final file size. For musical podcasts where you feel it is imperative for the listener to hear the best sound quality possible, use 44,100.

2) Bitrate - This is really dependent on the software you're using, but common bitrates are 320Kbps, 256Kbps, 128Kbps, 96Kbps, 64Kbps, 56Kbps, 48Kbps, 32Kbps and 20Kbps. Again, the higher the bitrate the better the sound quality and the larger the final file. And it roughly works out that a 256Kbps file will be twice as large as a 128Kbps file. (I'm not going to touch on variable bitrate here because I want to keep it simple ... if you're into it enough to want to use variable rate, you probably don't need this tip anyway.)

For spoken word podcasts, 24Kbps is the lowest you want to use and 56Kbps is the highest. This statement is very much my personal opinion and other people may strongly and with good reason disagree. What you're after is the ideal balance between sounding like you're talking in a tin can and not overloading your listeners with huge downloads. I'm willing to sound a little more tin-canny (even though I promise you that our original broadcast is crystal clear and of high audio quality) because I figure more people are likely to download my podcasts if they are smaller in size.

3) Channels - This one is pretty easy. It means "mono" (a sing le channel so that the same sound is coming out both speakers) vs. "stereo" (a dual channel where each speaker is playing it's own, and potentially different, sound). Mono files are generally 1/2 the size of stereo files. (There are other grades of stereo like "joint stereo" but I'm not going to touch on them now. Google if you want more detail.)

For spoken word podcasts, mono is definitely what you want to use. Vocal work really doesn't require stereo unless you're doing something special. Although a mono podcast will lose a little of its 'lively' feel by being converted to mono, the tradeoff on filesize is definitely not worth it.

For a musical podcast where you really want to showcase the music, stereo is a better idea. Music loses a lot of its character when converted from stereo to mono. On the other hand, if it's a low-fi grungy feeling you're after, mono is great!



What bugs you about current podcasts you're seeing? What bugs me most is when I download a vocal-only podcast and find it is encoded at 128Kbps, 44Hz stereo - especially if it was recorded through a cheap mic and high-fidelity was obviously not what the podcaster was after. I've just wasted at least 6 times more bandwidth that I had to ... and so has the podcaster. The audio would have been just fine at 24Kbps, 22Hz mono. When I get podcasts like that I'm very unlikely to stay subscribed because I figure the podcaster either doesn't know what s/he is doing or they don't give a frig about the additional bandwidth cost I incur with my poddiction. Er, podcast addiction. :-)

Unless I know for a fact that a particular podcast is going to have something I want to hear, if I see a 30meg file for a 15-60 minute spoken word podcast I won't bother downloading it because I know it's over encoded - and I certainly won't subscribe to the feed with iPodder until it has a "Don't download anything more than X bytes" option.

The other thing that bugs me (but not as much as wasting bandwidth) is when a podcast is encoded at 32Kbps, 11Hz mono. This sound quality is horrible. If I didn't care for the podcast then it's okay because I didn't use a lot of bandwidth to get it, but if I like the podcast then I really wish it was of higher quality. If you have regular listeners and you intend to keep podcasting, please consider increasing your quality if you can afford the bandwidth. Otherwise, you might want to let your podience know why you are encoding so low and maybe they'll donate to your bandwidth fund.

One more thing ... a podcast encoded at 32Kbps, 11Hz STEREO indicates to me the podcaster isn't too swift. Stereo is comletely meaningless at such low audio quality. They could have doubled their bitrate and gone mono for approximately the same file size and I'd be listening to something that sounded twice as good.

Personally, I would like to see the bitrate, frequency and channels included in the text portion of blog entries that include podcasts since they are so easily extracted from the MP3 file itself, but I realize I'm stretching the possibilities of a brand new technology so I'll wait patiently until a version of RSS comes out where the enclosure tag supports including this information.



How does the time length of my podcast play into this? - It's always best to try and figure out the best tradeoff for audio quality vs. filesize no matter how long your podcasts are. But it is absolutely critical if you're doi ng a podcast 15 minutes or more.



Examples - Here are some quick examples I've recorded so you can hear the difference between various encoding options. Please note that the sound quality and filesizes you hear are totally dependent on software and codecs I'm using on my end. Your experience may differ.

If you really want to get a good handle on what audio quality you want to use and resulting file sizes, record a minute long test podcast with your typical mix of voice and music as a .WAV file. Then bring up your audio software and save the clip in different files all at different bitrates, frequencies and channels. Label the files accordingly as

frequency_bitrate_channels.mp3

For example,

44_128_stereo.mp3
44_64_mono.mp3
22_64_mono.mp3
11_24_mono.mp3

When you're done, queue them all up in your MP3 player and listen to the difference. Pick the one that has the lowest sound-quality you're willing to accept and see how big the file is in comparison with the others. Ask yourself "Would I be willing to use the bandwidth to download this file based on the audio content in it? Will others? Will potential new podience members who may not have a lot of available bandwidth be willing to? How many new listeners am I willing to sacrifice because the file is either too big or the audio quality is either too low or too high?" Then toss a coin and go with your best judgement!

Please note that in my experiment here, the filesizes are meaningless! I used different clips for each sample so that I could say what they were saved at within the audio itself. You will want to save the EXACT SAME CLIP using different formats so that the ending filesizes are all relative to the same clip. I included the filesizes here just to give a general idea of how lower bitrates and frequencies make smaller files ... but you'll note that my 22Hz_56Kbps is actually bigger than my 44Hz_56Kbps when it should be approximately half the size. This is partly because they're not the same clip and maybe because my software encodes that sample rate more efficiently at 44Hz. See? You can learn all sorts of good stuff by doing this little experiment! :-)

44_128_stereo.mp3 - 125,388 bytes - way overkill for spoken word
44_128_mono.mp3 - 118,700 bytes
44_96_mono.mp3 - 99,056 bytes
44_56_mono.mp3 - 57,783 bytes - still overkill for spoken word
44_48_mono.mp3 - 43,259 bytes
22_56_mono.mp3 - 62,354 bytes
22_48_mono.mp3 - 49,685 bytes
22_32_mono.mp3 - 31,556 bytes - probably what I would choose if I wanted to sound pretty good
22_24_mono.mp3 - 23,667 bytes - what I would choose if I didn't care if I sounded good
11_24_mono.mp3 - 24,451 bytes - very hard to listen to
11_18_mono.mp3 - 16,085 bytes - causes quick and extreme audio fatigue ( your ears get tired and you want to quit listening no matter how good the content is)



Title=Podcasting Thoughts And Tips 004 - Encoding MP3s
Artist=Jimbob
Album=Whole Wheat Radio Archives
Genre=Education
Comments=Encoding MP3s For Your Podcast - http://www.wholewheatradio.org/jbb/weblog.php

Length=6:35
Channels=mono
Frequency=22050kHz
Bitrate=48kbps

Filename=Podcasting_Tips_004.mp3 (Please right mouse click and do a SAVE-AS to save this file directly on your computer)
Filesize=2,373,482 bytes
Filedate=Monday October 11th, 2004 5:29 pm (Alaska Time)
[Blogdigger MP3 Media - Latest links for .mp3 files]
- Posted by William A. Riski - 5:38:13 PM - comment []

Who Links Here