Heidelcast Episode 3b: Follow Up to DGM (Part 2)

Heidelcast episode #3: A Gentle Rebuke to Brother John (pt 2)

Subscribe to the Heidelblog today!


25 comments

  1. Dr Clark,

    Its a good thing that you are confronting John Piper on this important issue. He is such a role model to so many young “reformed” people (YRR). So, there may be a tendency to take whatever he says as impeccable . This healthy confrontation will go a long way in helping people realize that we should not acclaim anyone uncritically.

    Venkatesh

  2. I would be interested to know whether listeners prefer the faster loading but lower quality (64 kpbs) version or the higher resolution version of the Heidelcast.

    I prefer faster loading/lower quality for a couple of reasons:

    1) Sometimes a lower bits-per-second recording actually makes purely oral recordings easier to listen to than higher bps recordings.

    2) The loss of quality is not distracting when no music is included in the recording.

    3) If you download them to a hard drive, an MP3 player, or save them to a CD-ROM to play in the car (f0r example), they take up less space and you can fit and listen to a lot more of them.

    • On the 64kpbs version I hear phasing and other weirdness that drives me crazy.

      Even at 128 jobs these are still very small files – a cd holds 700mb and this file is +- 15

      Sent from my iPhone

      • Dr. Clark,

        Thanks for the generosity in answering my drive-by questions. Not sure if this is just geeky or truly helpful, but that which is driving-one weirdness is even more precisely called aliasing (http://en.wikipedia.org/wiki/Aliasing). The skirts of the A/D filter being used at 64kpbs aren’t tight enough to prevent undersampling of the signal. By sampling at 128kpbs, the A/D filter in your system will better meet the anti-aliasing filter requirements of the signal involved (your recorded voice).

        Anyway, I’m in your debt. Thanks for the help.

        • This is very helpful.

          I think I understand the theory but why do some 64kpbs podcasts sound okay but when I compress the HC or Office Hours (http://www.wscal.edu/officehours ) to 64kpbs I get this effect? We checked several NPR podcasts and other podcasts and they’re all at 64. E.g. the Planet Money podcast is at 64, sample rate 44.100 etc. All seems standard except now I see that all the public radio podcasts are mono. That must be it. The two stereo podcasts to which I’m subscribed are both at 96 or 128.

          Originally we were going to use m4a files then we went to mp3s at 128kpbs and then to 64kpbs. I think I’m going back to 128.

          Many thanks.

          • Dr Clark, I think you will find that filters are used to tighten the audio spectrum in the NPR podcasts. Also have you given thought to encoding in variable bitrate with a higher quality setting? Last thing: My friend Tim Merki says he cannot listen to the broadcast on his 1st gen iPhone. He would like to be able to listen on his was to SEBTS for classes… something about you giving him hope the whole world has not gone insane or something.

            • Hi RK,

              I’m not sure what to do to make that possible. Can’t he download the audio and import it manually into iTunes? If he creates a playlist and drags the files into it, that should work.

          • 128kpbs is always going to allow for a much “richer” aural experience. There’s simply twice as much information per second (or any other unit of time).

            Still, somewhere around 8kpbs is or is becoming the standard for telephony calls, at least for internet and cell phones (see http://en.wikipedia.org/wiki/G.729 ).

            Mono 64 kpbs will have fewer aliasing and other audio artifacts than stereo 64 kpbs. Also the single channel will sound clearer because it doesn’t need to share bits with a second channel.

            The digitizing hardware (e.g., your computer’s sound card and its A/D converter) can play a big role in the final, converted, processed bit stream. Is there a chance that the Planet Money podcast’s are created with different hardware?

            A $5 and a $50 A/D could both produce bits that are good enough for a 128 kbps mp3, but the $5 A/D may not be clean enough for a 64 kbps application.

            At issue might also be settings such as the “depth” of the compression: some algorithms can produce higher quality compressions if they are allowed to operate in post-processing, non-real-time mode.

            Nor is all compression software is created equal. One software audio package will offer better options than others.

            • Two refinements:

              1) mono 64kpbs has 8 times more information than an internet telephony signal. So mono 64kpbs can in some sense, at least in theory, sound 8 times better.

              2) some algorithms can produce higher quality audio at the same compression ratio if they are allowed to operate in post-processing, non-real-time mode.

              These two points were kind of muddled in the original posting. Just wrote this to make them more obvious.

              • This is very helpful.

                My broadcast background was on the performing end, not in the technical/engineering end. I’m learning by doing. I record the podcasts using a MacBook and GarageBand. I’m open to switching software as I’m finding out the limits in GB but I’ve invested a lot of $ into the hardware (mics, boards, amps, monitors etc). The hardware is mid-range. Some of it is high-end. It’s a lot better than the stuff I used in most AM (and even FM) radio stations back in the day (c. 1977-1984). I don’t want to spend a ton on new software. I’ve used pro tools but it makes the computer seem like it’s about to crash all the time.

                  • This is helpful, though I think the podcasting pre-set in GB takes care of most of this. I’ll check. I think I can use the noise gate. I’ll think about going to mono. I’ve been doing that with the OH podcast because of the size of the file.

                    • Most likely, the equipment you have can acheive a sound quality at or near Planet-Money-podcast (NPR) levels.

                      There might something simple going on. Perhaps the audio level is too strong somewhere in your system, resulting in clipping ( http://en.wikipedia.org/wiki/Clipping_(audio) ). If so, just need to turn the volume down or insert an audio attenuator (Radio Shack, Fry’s, etc. carries these). Alternatively, if the audio level is too low somewhere in your system, then signal-to-noise ratio will be needlessly high because the full dynamic range available is being under utilized.

                      These are two simple, fixable-at-low-to-no-cost system-level issues that would cause noise artifacts. In final signal (i.e., the podcast), they might result in unwanted sounds somewhat similar to those of aliasing but aren’t.

  3. I appreciate these Heidelcasts as well. While I certainly have a lot of respect for John Piper, I was deeply hurt that he invited Doug Wilson to speak at this conference. As you say Dr. Clark, he is not your average run-of-the-mill Presbyterian. I hope Mr. Piper changes his mind on the nature of the Federal Vision.

  4. The Heidelcast is a great idea.

    Thanks for the book Office Hours! Received it today in the mail.

  5. I’m not up on the tech stuff… but why do it in stereo? If it loads and plays more easily in mono, I say that is better. If NPR does mono 64, go for it. Their quality is worth imitating.

  6. According to a posting by someone named Rasheed at the PCA (Pod Cast Alley) in 2007 ( http://www.podcastalley.com/forum/archive/index.php/t- 138572.html ), Garageband will “If you try to encode into 64 kbps 44,1 Khz mono, it uses 32 kbps 44,1 Khz mono. You have to use double the bitrate to encode the proper bitrate in mono.”

    If Rasheed was right and the version of Garageband that Heidelblog is using also has this issue, then encoding at 128kbps 44.1 khz mono is really creating a 64 kbps bit stream. If in Garageband encoding at 64kbps 44.1 khz mono is in reality creating a 32 kbps bitstream that would explain the unexpectedly poorer audio.

Comments are closed.