The Problem with Transcontinental Podcasting

I am not sure if anyone else has to manage audio files that have been .mp3 encoded prior to editing but for the podcast it has been causing some issues. This week however, I made a few changes to the encoding and it appears to have made a significant difference. Here is what I have done and if anyone has any further suggestions I would appreciate it.

The background of this whole saga is that I used to record the podcast using Hot Recorder. Since the release of Skype 3.0+ this has failed to record anything but silence. Although he website claims it does work with 3.0. So we had to look to an alternative. Knightwise has a Mac so that made it a lot easier for us to decide what to do but our decision then presented a few things we had to work around.

For some reason recording Skype on a Mac is relatively easy compared to a Windows based machine. Not sure why. It might be the way that Mac handles audio or that there has been more development on the Mac in this regard. So we decided to record the show on Knightwise’s Mac. He uses Call Recorder to record Skype, which by the way has excellent results. Far superior to what I was getting with Hot Recorder. But now we had a great recording of the show in .wav which is generally about 1GB in size… +2.4GB but it was on the other side of the world! We needed to get it to Oz in one piece and in good enough quality to work with.

A great supporter of the podcast donated a server which has excellent speed and storage in addition to as many FTP accounts as we needed. However sending a 1GB file across the world is out of the question, even zipped up it would be huge! The only answer that we could see was to encode the .wav as an .mp3 in as high a quality as possible. So Knightwise encodes the file raw as a 192 kbps, CD quality. The result is about 100MB, which is very manageable. He then sends the file to me via FTP.

I download the file and convert it to a .wav and edit the show as per usual. When finished the file would be encoded as an .mp3 at 64 kbps at 44100 khz. We dropped the bps a while back to give us a smaller file size, which we thought would be appreciated. However since we swapped to Knightwise recording the show the 64 bit quality has been giving us poor results. I have tried to optimize for quality in the encode but it has made no difference.

The problem is that .wav files loose certain frequencies when they are encoded to .mp3. You can’t get them back they are gone forever. Sure I do everything that I can to get the best results. But the 64 bit rate was stripping more of those frequencies out of the final file than I would like. This resulted in some rather strange sounding ambient sounds and hissing when there was talking in addition to making the music tracks terrible. There was only one thing for it.

This week I increased the bit rate. Although in the beginning the show was encoded at 96 kpbs; I thought I would take the intermediate step of 80 kpbs. The result was a file that was only about 4-5 MB larger but the pay off in quality I think was worth it.

The conclusion is that when we changed the way the show is recorded and then encoded before transfer, we should have decided to increase the bit rate. The 16 bit increase in quality has compensated for the lost frequencies the first time it was encoded as an .mp3 making the file resilient to being decoded to .wav and then back to a .mp3. A few further tweaks at the recording end will give us some further head room as far as quality.

I would remind all podcasters out there of one of the golden rules of editing, never edit a .mp3, always convert it to a .wav. I hope this hack helps anyone else faced with the same problem of transcontinental podcasting and file transfer. Check out this weeks show and compare the difference.

UPDATE: Hot Recorder has been updated to version 2.14, which I am told does work with Skype 3.0+. I am yet to test it but I will let you know the results. Thanks to mswiczar for the tip in the comments.

Advertisement

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!

The Hardest Edit Yet

You guys are going to think I rabbit on about the podcast a lot. Well simple truth is that I do. Reason? Well I (we) have a lot invested in it. It is a labour of love admittedly, but when you spend so much time on it; it makes it matter more. This week that is especially true.

This week we did our first interview for the show. It was with Dick Hardt of Sxip Identity, the CEO. Skype was a complete bastard, for what reasons we do not know. In addition to that the audio was less than perfect. As well as that I was learning my way around some new software. All up this meant for me a huge job. It took hours and hours of editing, and re-editing. I had to correct the audio levels and make sense of garbled Skype noise to extract the content. That is an added step that I don’t normally have to worry about.

I edited the interview once and on a listen I thought I could do better. I originally edited the raw data in Audacity then on the second I tried out Sound Forge by Sony. The wave patterns are easier to read in Sound Forge I think. That meant the second edit did not take as long. But a lot of the crackles and peaks were taken out. The software is very, very powerful and that meant that I had to learn a lot of new techniques for doing things. The help files are great and that helped. There are a few things that I could not help or eliminate, like the alternating volumes that can be heard. That was a result of the fact that no compressor on earth could have made up for the level differences between us and Dick. But overall the result is great compared to what I had to work with.

Then came the task of throwing it all together. Sebastian and I recorded our bit last night. That went so well it was smooth as silk. We knew our stuff and Seb was a great asset (as always). At one point my web page would not load. It was my story and once Seb knew I was having trouble he just stepped in and took over, magic. It just worked. Then after we finished I started to edit our bit and exported it as a .wav file. I put all the components together in Acid Music Studio, again Sony. It kicks butt and a serious time saver.

Audacity does multi-track badly. So this was a nice change. Again a powerful program and I was pulling my hair out with some things. Like if you change a track from a one-shot as opposed to a loop it changes the way the audio sounds. If it is supposed to be a one-shot, it sounds like crap as a loop. What I did not know was that it automatically loads some sounds as loops. So I spent about an hour trying to find out what the go was with Sebastian sounding like a Darleck! The other thing that this label of loop or one-shot does is changes the tempo of a track. So I was adding audio and it was either too fast or too slow! Again, pulling my hair out but got the two problems sorted when I realised the difference between a loop and a one-shot. Over all though I would say that software is very intuitive and easy to use. Despite my issues, which were minor. Organising and arranging your work is a snap and the ability to zoom and scale is priceless. I can now fit over ten tracks on the one view, much easier.

In addition to this the two programs work seamlessly with each other. Need to edit a track while working in Acid? No problem just open it with a right click on the file name, edit it and close and keep working on the project in Acid, awesome! The only thing that it won’t do is encode the .mp3, for that I am now using RazorLame.

RazorLame worked wonderfully. The file was encoded at 64kbps with a 44100khz sample rate. Another first for the podcast. I figure that it is a toss up between file size and quality and marketing. I think a smaller file size might mean more listeners. My only criticism of the file was that some kooky shit happened in that there is a bit of an echo in the first half of the podcast but then the rest is fine. Not sure what that was about but I think it might have something to do with modulation. So I have decided that for the next podcast record we will under level the audio, this will give the final product some headroom and take out some of the fluctuating echo. I say this because the audio of the interview which was under-modulated is fine.

And that’s a wrap. It was indeed the trickiest podcast to edit and toped with that was the new software and methods. I am proud of what has been produced. This is why we have a vested interest and maybe you can see why we are passionate about what we are doing. It represents a huge investment of time and energy. The reward is for people to listen to it.

Head on over to The Global Geek Podcast to check out the show!

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.

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.

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!

Podcast Titles: Get Catchy!

I just finished listening to From The Directors Chair number 17. Sebastian Interviewed Dave Jackson of The School of Podcasting. I really enjoyed the show and the interview was great.

Dave had some great hints and tips for new Podcasters and I am going to try to implement at least one of them, not that there were not others but I actually do the other ones he mentioned. The main thing that he mentioned was to choose the titles of your podcasts carefully. That is the title that will appear in iTunes, or in peoples RSS readers. The reason is that you need to grab peoples’ attention to in order for them want to take the time to listen to your podcast. Or for that matter the titles to your blog entries as well.

The other thing that was mentioned that I may as well mention here is the error of editing a podcast in mp3 format. As you may or may not know mp3 is a lossy format. Or in other words every time you open and save it it “looses” some of the quality. By the time you get round to publishing your podcast it has been edited and re-saved about twenty times and the quality is significantly reduced. This is especially evident if you publish in low bit rates. This is one error I did not make. I record and edit the whole vocal audio as a .wav file and add the songs last as they are downloaded as mp3’s and I can not change that as they come from the Pod Safe Music. So the addition of them last means minimal quality loss.

So it was a top show and there was heaps more than I have mentioned here so go and download it and listen for yourself.