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!

Advertisement

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.

Odeo Cripples Functionality

Odeo LogoOdeo seem to be updating and improving their services every other day of late. However, it is not every day that you see such a great service actually remove a feature and make it harder for users to utilise their service. They have indeed done so and perhaps in doing so shooting themselves in the foot.

One of the great features that is available to Odeo users is to have an "inbox". If you were to place a button on your website, be it blog or some other site you have enabled your readers to leave you audio comments by clicking the link. They get taken to a page that has a recording interface, which is simple and easy to use and the result is great audio. You as the user of Odeo get that recorded audio in your inbox once it is sent to you. You are notified of this by an email.

Another great feature is that you can subscribe to an RSS feed of your own inbox! So this is a great way to receive feedback on anything. Including podcasts. Seb and I saw it as a great way to get feedback for Global Geek Podcast, so we set up an account. The advantage of getting audio as feedback is that you could go to your inbox once you were notified and click the new Odeo comment that was left for you. You can listen to it. But the biggest feature was that you could click a "download as MP3" button and download the audio comment and insert it into a podcast! The result was excellent and we loved it.

The ability to download the MP3 has been removed from the play window! So what the hell is Odeo thinking in removing this key functionality. It means that it is impossible to download the audio from the page to your local machine. Rather it makes it a pain in the butt to do it.

I found that there is a work-around but it is messy: Open Audacity, set the source to "stereo mix" get ready to hit record… Open the Odeo message that you want to record. Flip back to Audacity and hit record, nip over to the Odeo page and click play. Go back and hit stop on the recording when it has finished. As I said messy. In addition the audio that you end up with is less than ideal and requires a bit of editing.

I am utterly dismayed as to why Odeo have removed this from their site. The only thing that I can think of is that they want users to listen to audio, only from them and not from another source. Perhaps they were not aware that the service was being utilized in this way and they have done it ignorantly, I just don't know. Sebastian has suggested that perhaps they are beginning to think about implementing a pay service and this has something to do with it. But since when has any site reduced their services as opposed to offering more. We are not the only podcast doing this. I can honestly say that if this situation remains as it is; the blogging and podcasting community could deliver some negative press, big time.

Global Geek Podcast has mentioned Odeo on every show that we have done. Not only that there is a link on the Global Geek Podcast website to Odeo, there is a link to Odeo on Rooster's Rail, Seb's Random Thoughts and we have plugged them for their service and functionality since utilizing their service. It is not like we have not given back to Odeo. This I feel is the thanks that we get.

Global Geek Podcast have sent off an email to Odeo in regards to this issue and we await a response, I will let you know what we get back from them when and if we do.

Update: Please check out the Follow-up Story