Can I Change the Bit Rate of an Mp3?

I have seen this question come up a lot in the search terms that people use to get to Rooster’s Rail. So much so that I decided to answer the question here.

The short answer is no.

So I guess that deserves an explanation. Mp3 is an audio format that uses complicated compression formula that results in a much smaller file but retaining audio quality based upon what bit rate and sample rate was used to encode the file. Simply put:

Smaller file size = less quality

That is lower bit rate and sample rate.

Bigger file size = better quality

Higher bit rate and sample rate

Then there are mixes of the sample rate and bit rate that produces results that are in-between. There is also a file format called VBR or variable bit rate. I am not going to go into that here but that is basically where the bit rate varies according to the complexity of the music or audio file and results in a file size that can be smaller but retains a higher quality than an otherwise static bit-rate.

This bit rate and sample rate are dictated by the person that encodes the original file. The original file is often a .wav file wich is very large but of high quality. For example The Global Geek Podcast as a .wav file and goes for about one hour is over 500MB. Once encoded to an .mp3 file is between 20 and 25MB. I dictate the bit-rate and sample rate when I encode the file.

So lets say that you get that file which is encoded at 64bit and a sample rate of 44100khz. You want to lower the bit rate to make the file smaller. Sure you could using a program such as RazorLame, decode the file and then re-encode it at a lower bit rate such as 44bps (bit-rate). But the resultant quality would be lower than if I had used the original .wav file and encoded it at 44bps. This is because the best quality that you have is 64bps, that is as good as it gets. The quality can get no better than that. So in conjunction with the fact that .mp3 is a lossy file format and will get worse in quality every time it is opened and closed or encoded you end up with pretty much crap.

Same can be said if you wanted to go up in quality and therefore bit-rate. If you had a file that was encoded at 64bps there is no way on earth to make it better quality than what it is. If anything going up in bit-rate will make it worse because it will very successfully highlight the imperfections that are a result of encoding something as an .mp3 file. When a file is compressed in this way it decreases in quality regardless of the bit-rate. It all has to do with the fact that to make it a smaller file you have to ditch some of the data that the original file contains. That said it would take a very good ear to detect the imperfections in a high bit-rate encoded audio file, but it is there.

Moral of the story is that if you have an .mp3 file leave it as it is. Unless you can get the original source file there is no way to increase or decrease the quality and maintain any sort of standard about the quality of it. I hope this clears up a bit of confusion that there appears to be out there.
I tried to think of a good analogy to use for this post and could not, but this is the lame one that I did come up with:

Trying to change the bit rate of an .mp3 file is like baking a cake and then deciding that you want to know how to make it so it has less sugar in it than what you originally put in it and still have the cake!

Advertisement

Podcast Bitrate Problem Solved

As people that regularly read my blog I mentioned that I was having some major issues in regards to the encoding of the .mp3 file for the Global Geek Podcast. I was unable to encode the file at a bit-rate of 64 and then a sample rate of 44100khz. Audacity refused to allow this combination even though the “project” file was in a sample rate of 44100khz. Rather Audacity encoded the .mp3 at 64bps but then adjusted the sample rate to 24khz. This sample rate as you would be aware is not compatible with web based flash players. So not very useful.

It would appear that the problem that I was having was not an isolated one, other podcasters have come across this problem as well. It would appear that the problem lies not with Audacity but with LAME. LAME is the piece of software that actually does the encoding not Audacity. The limitation lies in that software. I have however sourced a solution with the help of my mate Adam – code monkey and general good guy.

RazorLame Screen Shot

The solution was not to ditch LAME as such. Rather we got hold of some software called RazorLame. RazorLame adds a powerful GUI (Graphical User Interface) to the LAME engine. I am fairly sure that it also includes some other software that meshes with LAME and the result is a top piece of software. It is open source as well which is great. As usual the interface is not that pretty but very functional and who cares about what it looks like as long as it does the job and this does more than that.

RazorLame will not only encode file but can decode files and then re-encode. Not recommended though, as I have said before .mp3 files are a lossy format and the quality deteriorates on repeated writing. But this remains a handy feature, it might get you out of a tight spot if you have lost the original file and you need to encode it again for some reason.

The big feature for me was the fact that you can mix and match bit rates and sample rates however you wish to. Makes for some interesting possibilities. But the feature that I was wanting to take advantage of was that I can now encode a file at a bit-rate of 64kbps, and a sample rate of 44100khz (or 44khz – for short). This is great because this means that we can keep the quality of the show but make the file size a bit smaller. As an estimate this means that our show will average 20MB to 22MB for 45 minutes to 55 minutes in length.

RazorLame Screen Shot 02

To take advantage of RazorLame you have to export the file from your audio editing software of choice as a .wav, it is this file that you select in RazorLame to encode to an .mp3. Remember to make sure you have enough disk space for this file as an hour show the file will be over 500MB. You can ten select the bit rate and the sample rate and other features that you may want to utilize. Then hit encode, that simple.

This is just another step in your editing process and one that should not be that hard to do. With the big payoff, a small price to pay.

I hope that this helps out all those podcasters out there who have had the same problem. For some reason the answer was hard to find. I dropped the problem here and in The Global Geek Podcast Blog and no-one responded with an answer. When I Googled the problem, I got my own blog entry stating the problem! So I decided to give the answer here as well!

Global Geek Podcast is Posted

Global Geek Podcast CoverArtVery pleased with this show. I just finished editing and writing up the show notes last night. It really is a great show and I enjoyed editing it and putting it up there. Every show is not without problems though!

So the part of the show that is usually hard, the editing, was a breeze. The hard part was the encoding of the file as an MP3! I wanted to drop the bit rate down to 64kbps, which I did. It was great, I had a show that was about 22MB, went for 50 minutes and still sounded great! But for some reason Audacity decided to change the sample rate to 24khz. The “project” was a 44khz project. So it should not have changed on the encode. So I ended up chatting to a few people and I got some advice and I tried it.

I exported the project as a wav file. So then the whole audio was mixed down in one continuous track at 44khz. This was done because it was speculated that perhaps some of the tracks that were added were influencing the output on the encode (for some reason). Anyway, I have this giganormous file and I open it up in Audacity and check all the bit and sample rates and I have everything set to encode the MP3 at 64kbps and the sample rate of 44khz. I encode the MP3 and the same bloody thing happens. On the encode the sample rate gets changed from 44 to 24khz. This can be a real problem for some web based flash players, they don’t like it and it speeds up the audio making it sound like chipmunks. Think of it like changing the RPM on the old vinyl.

So I do battle with Audacity for over two hours and get nowhere. I read forums and web pages to try to find out what was going on. Most web pages were an explanation of the difference between bit rates and sample rates, which is a difficult concept. But that was not my problem! So I gave up and decided that I was thinking about getting some commercial software anyway.

So if anyone out there uses Audacity and encodes their podcast at 64kbps could they please let me know what I am doing wrong? Thanks in advance.

But that did not ruin the show, the show was great and we had heaps of fun with it. If you have not listened to the show before then head on over to the homepage at The Podcast Network and check it out. You can even listen to the show off the web-page on the embeded player. I would prefer it if you were to subscribe though.

We have some great guests coming up as well, so stay tuned for that; it should be good. We have left it a bit before we got guests and interviews going for the show. We wanted to get comfortable with the show and getting it right as far as the audio and the editing.

So go get some geek over at The Global Geek Podcast. Remember to send us some feedback and let us know how we are doing with the show, but be nice. We do not mind honest but just saying it is shit because you think it is; is not nice.

This is supposed to be fun after all, thanks to our friends and supporters your positive comments have made the world of difference.

What Bit Rate for Podcasts?

I really, honestly do not know the answer to this question. What is the best bit rate to encode a podcast at? Also does that answer depend upon the fact that you are a listener or a podcaster or hosting service?

I do the post production work for the Global Geek Podcast. Before moving to TPN I always encoded the podcast at 44khz and 96kbps. That works out at about 35 – 40MB per show (depending on length between 40 minutes to an hour). We have what I think is great audio quality, but am I spoiling ourselves and our listeners and potentially excluding others?

We have never had a complaint about the file size of the show. No-one has ever said it was too big. People have commented on the quality and said it is great and we have worked hard to get it that way. But I now question if that is over kill. So I tried to figure out what bit rate is the most common. I did a very small survey of the podcasts I have on the computer. I only have nine on it at the moment – most of them are on the MP3 Player (where they should be).

Anyway I got the following breakdown:

Total of 9 Podcasts:

  • 2 encoded at 96kbps
  • 4 encoded at 64kbps
  • 3 encoded at 48kbps

A conclusive survey that does not make. But maybe I am aiming too high. What quality do listeners expect of a podcast? Do they want a small file and lower quality so that they get the content without the bandwidth. Or do they want great quality and a larger file size? With the size of MP3 players now the storage is not an issue I don’t think. But I know in Australia the cost of bandwidth might be. The cost of faster connections is expensive and so many users are on a maximum of 256/64 or 512/128. So does a larger file size deter them from listening to our show? Could we have a bigger audience if we made it smaller and if that is the case what size is acceptable?

With the uptake of broadband technology there is a step towards encoding at a larger bit rate but what should it be? Perhaps 64kbps is a good place. I listen to quite a few podcasts that are recorded at 64kbps and they sound good. A one hour podcast encoded at 64kbps is about 28MB (voice only). Is this a big difference to 96kbps? Well it is between 10 and 15 MB. Will that mean the difference between more listeners and a balance between keeping your existing ones because of what they expect? Will you loose listeners by lowering the bit rate dramatically and will it matter because of the number you pick up. To me it does anyway, I care that we keep the listeners we have.

The other big consideration here is the hosting cost. I know that I had to go to the plan one up from the basic plan in order to have the podcast encoded at such a high bit rate. So that privilege cost me $10US/month instead of $5US/month. That was a cost that I thought was worth it. Also what if your podcast is being hosted by a network, what file size is reasonable for them to host? Is it acceptable that you have a higher bit rate than the other shows that are hosted there and is it necessary? Personally, I would like to find a happy medium between file size, bit rate and quality. I want the best quality at a reasonable file size. I don’t want my hosting provider to get pissed off that the show is too large. In addition to that fact; the network wants as many people to listen to as many shows as possible. If it is possible that people are “turned off” by a large file size, then that is not for the benefit of the network and I would not do it. In that instance the file size should be smaller at the sacrifice of quality for the benefit of the network and I need to accept that.

As a listener I do not care what size a file is. I have a fast Internet connection and it really does not bother me. I like high quality podcasts but I listen to some that are not of a high quality as far as bit rate because the content is good. So is good quality a cover for shit content? If it is; it is not sustainable long term. So as a listener of podcasts I don’t search for podcasts based on audio quality or file size, and maybe I have just answered my question in part.

Having made these points I will say that some basic editing will improve quality out of sight. I have turned off podcasts because they have not bothered to do this basic editing. They were unlistenable and total shit and they should have thought the same! I wonder if some podcasters even listen to it after they have recorded it. So what do I mean by “basic editing?”

Basic editing in my opinion is:

  • Setting levels before you start, especially if you are recording Skype using a software application. This means setting your levels with enough “headroom” to get loud during a podcast so that you don’t “clip” the recording. And not so soft that you have to amplify it dramatically to get something to work with.
  • Don’t edit the podcast as an MP3, MP3 is a “lossy” format and gets worse and worse in quality every time you re-encode it or open it and save it.
  • Run a compressor on the audio to “smooth” the audio. That is take out the high’s and bring up the lows.
  • Run the compressor a few more times.
  • Normalise” the audio, basically set the zero level. Makes the podcast the same volume and means that the listener isn’t constantly turning their volume up and down.
  • You may need to “amplify” the whole audio after using the compressor and normalising the audio. You don’t want the listener running out of volume because it is too soft!
  • Any added or imported audio needs the above steps.

Believe it or not the above takes the least amount of time in my editing but makes the biggest difference. I do go a step further and edit the actual audio and take out the umms and errs and we always stuff things up and say well we will edit that out. The time is also in the transitions and the mixing of the imported audio, making it all work together (the best that I can). So maybe you can see why as a podcaster I want it to sound as good as I can, I put a lot of effort into both the pre and post production. But is that at the neglect of other issues? Is this basic and advanced editing enough to make it a “quality” podcast?

Please leave a comment and tell me what you think. Tell me if you are a listener or a podcaster. Podcasters, tell me what you encode your podcast at and why. Listeners please answer my questions for me. As I said at the start of this post I really do not know what the right answer is, that’s why I have posed lots of questions. It would be great to get some answers, although I am not sure there is one.