This is Part B to a two-part series on how iRiver's H320 can serve as a multi-purpose device for people who need to listen to as well as record digital audio (Part A mostly covers the listening side of the equation). Although I'm still testing the device, I was motivated to release some of my findings ahead of time because of how podcasting co-inventor Dave Winer reached out to the blogosphere for advice on what his next digital audio player (DAP) should be. His iPod is on the fritz and since none of Apple's existing iPods come close to satisfying his needs as a podcaster on the go, he's looking for a different sort of "system." I've been testing the H320 as both a podcast consumption device as well as a device that could live at the heart of my mobile podcasting studio.
The incredibly ironic thing about the term podcasting is that the iPod pretty much stinks as a device that you'd "cast" your audio from. In no way does it come ready to record audio. For that, you need to add third party products to it and even after you do that at some reasonable cost, you'll end up with limitations in the quality of audio you can record. For example, something that records at a bit rate of 16 kbps with a sampling rate of 8 KHz. Though I plan to cover these technicalities in my Podcasting 101 series (which I just started writing in parts), take my word for it that this is insufficient quality.
In fact, even though CD quality music is created at rates of 16 kbps (data) and 44.1 KHz (sampling), you have to remember that those CDs and music files are mastered when the systems that are creating them have the time and/or the power to neatly tuck all that audio into a nice little 16/44 envelope. In my own tests of a couple of devices that are capable of digital audio recording, even though the spoken word theoretically doesn't require nearly the horsepower that music does, asking a sub-$1000 device to neatly tuck live speech into a 16/44 envelope is asking too much many record-capable devices, particularly if compression is involved as it is with the H3x0s which only record in the MP3 format (invariably used for compression) But if those devices are capable of casting a wider net, say at data rates that are better than 16 kbps, things start to look up.
With the ability to set its built-in recording capabilities (yes, I said built-in) to 320 kbps, the iRiver H320 is one such device. If you compare podcasts that were created at various bit/sampling rate combinations, then chances are you'll find what I found. First, that for the final product, podcasts that were recorded at a bit rate that's lower than 64 kbps and a sampling rate of 22.050 KHz will often suffer in terms of audio quality. Take either to the next notch down (eg: a bit rate of 48 kbps), and the difference in the audio quality that's produced by a consumer device may be detectable by the human ear. Second, that beyond the 64/22 combo, the difference in quality is likely to be unappreciable to the human ear. As it turns out, 64/22 is a great combination. Many podcasts are also done in a monaural format (as opposed to stereo) which, for "talk radio," provides the added benefit of saving space. With music, monaural may not be an option. But, even though a decent audio editor like the open source Audacity is capable of producing great sounding 64/22 audio, those podcasts are only going to sound as good as the worst of the raw materials that went into them. Thus, "casting the wider net." When creating the raw material, if there's no significant penalty for doing so, you might as well overdo it a bit. For example, unless hard drive based devices such as the H320 or its 40 GB bigger sister are already packed with audio, there's no harm whatsoever (in terms of a storage penalty) in recording live audio at 112 or 128 kbps vs. 64 kbps.
Of the four input sources that the H3x0 can record audio from (internal microphone, external microphone, line-in, and the FM tuner), all but the internal microphone can be pushed to a bit rate of 320 kbps. The internal microphone (a condenser mic) can only be pushed to 128 kbps (which is hardly a sin).
Just the fact that the H3x0 has four recording sources where most other digital audio players have none is remarkable. Of particular note are the H3x0's jack configurations. On the top of the devices are three audio jacks that are labeled from left to right as follows: headphone, line-in, and line-out (see photo below, ignore the port with the gold contacts)....
....So, of particular interest to anyone hoping to record with an H3x0 is the line-in port. Compared to the line-in jacks on most recording equipment, the H3x0's line-in jack is unique because, unlike most implementations that involve two separate jacks, one for line-in and the other for mic-in, the jack on the H3x0s that's labled "line-in" can serve as either. If your intention is to use the line-in jack to record audio from a microphone or other audio devices, the user must select through the user interface which of the two modes (line-in or mic-in) the jack should work in.
While the difference between line-in and mic-in is a detailed discussion that I'm saving for a Podcasting 101 segment, one note of interest about the H3x0's line-in capability is that, much like the mic-in mode for which such a feature is expected, the line-in mode has a provision for adjusting the inbound audio level. With line-in, a level of audio that doesn't require any adjustments to sensitivity or audio leve -- otherwise known as line-level -- is usually assumed. For this reason, whereas some dedicated audio mixers have provisions for adjusting line-in levels, many consumer-oriented audio recording products do not. The presence of a level adjustment when an H3x0 is set to record via line-in indicates that the designers weren't just trying to build a consumer device that records, but one that caters to more of an audio prosumer that may want to really fine tune their recording settings.
Although I haven't tested it yet, the H3x0s also have a feature referred to as AGC which stands for automatic gain control. My first hope for AGC was that it would make whatever adjustments are necessary to bring any inbound audio to line-level (the maximum level of audio before it becomes distorted). One of the reasons I was hoping for this draws attention to one of the biggest drawbacks of the H3x0s: the inability to visualize recording levels. I'm not sure what it would have taken to incorporate that capability. But, given that the H3x0s provide audio level visualization when in playback mode, I was really hoping they could do it in the record mode as well. What this means is that in order to do a "sound check" to make sure that your inbound audio will get recorded at a decent level, you have to set your inbound audio levels, record some audio, and then play it back to see how high your levels are. If they're not high enough, then you can repeat the process trial-and-error style until they are. This, as you can imagine, can be a bit of a drag. While one of the other great things about the H3x0s is that you can monitor the recording through the headphone jack (or the line-out jack), the human ear is a really bad judge of true recording levels.
So, when I first saw the automatic gain control feature on the H320, I thought I wouldn't have to worry about going through a laborious trial and error process. Just maybe, I thought, the AGC feature would raise the audio to line-level automatically. But such was not the case. AGC is a feature that applies to the internal condenser microphone only. This makes a lot of sense since the idea of "gain" (the G) is about adjusting a microphone's sensitivity.
So far, I have't given the internal condenser microphone much of a test from a podcasting perspective since my podcasts often involve interviews of people that are in the same room as me and, if you've ever tried to record with the condenser mic that's on a notebook computer (the condenser mic on the H320 is basically the same thing), then you'd know that they're great at two jobs: one of turning a room into an echo chamber, and two, of picking up every sound in the room. Presumably, with adjustable gain, you can cut down the sensitivity of the mic, but that still doesn't get rid of the echo that could have otherwise been avoided. To avoid it, you could lower the gain to near rock bottom and then sway the device back and forth between the mouths of you and your interviewee(s), but the results won't be nearly as good as if you use an external microphone that's more suited to the task (even so, I'm going to test this method with the H320 when I get the chance just to see what it sounds like and will make the audio available for download).
When going the external microphone route with an H3x0, you'll of course want to set the line-in jack to the mic-in mode. Unfortunately, even after discussing the H3x0's mic-in capabilities with an iRiver spokesperson, I'm still not absolutely certain I know what the full capabilities of the H3x0's mic-in feature are and hereâ€™s why. For example, it, like many mic-in jacks, has a microphone preamplifier to provide some initial amplification of microphone-collected audio. However, depending on the microphone your using and other recording conditions, to get the microphone audio up to the ideal (aforementioned) line-level may require more amplification than the H320's microphone preamplifier can offer. At the same time, you don't want to over do it or you'll get distortion. Unfortunately, like many notebook computers, the specifications for the The H320's built in mic pre-amp do not specify how strong (in decibels) it is. For me, this turns the decision about what sort of other pre-amp to match with the H320, if the situation call for it, into guesswork.
My tests with various audio sources are incomplete. My goal is to run a more comprehensive round of tests of the H320's mic-in mode with both powered and unpowered microphones and to report on what some good working combinations might be. I'll be working with mini-plug based microphones (including the one that comes with the H320) as well as higher-end XLR-based microphones (powered and unpowered) whose XLR connectors can be adapted to the H320's 3.5mm mini-plug.
One preliminary result in my tests with the mini-plug-based microphone that required power is that a minor electrical hum could be detected while monitoring a recording (as it took place) as well as when that audio was played back after being transferred to a PC (eliminating any chance that the headphones were picking up the hum from some other electrical source or field). Mini-plug wires are about as low-end as you can go when it comes to audio cables and the audio experts I've spoken to tell me that the sort of hum that I'm hearing wouldn't be unusual for such consumer grade audio cables, particularly when there's a portable, ungrounded, power source in play. This is where, at least for now, we're bumping into the limits of my understanding of audio and electricity so I apologize if any of these conclusions seem grossly off the mark. But one telling sign of how a recording environment becomes less predictable when all the cabling is consumer grade and the power is coming from nothing but batteries is how, when I piped audio into the line-in jack from a real audio mixer â€“ one that ran off of AC power -- there was no hum whatsoever.
The bottom line is that there was a hum when using a microphone that draws power from a battery. I don't think the hum is enough to seriously degrade the production value of your podcasts. My preference is to not have it at all since the hum is more easily detected in interviews where there's no music to drown it out. On the other hand, depending on where, when, and with what speakers or headphones people listen to a podcast with a bit of hum in it, there may be enough background noise to drown the hum out anyway. For example, using the H320 and a set of iPod earphones, I just gave the recordings another listen while sitting on cross-country flight and I couldn't hear the hum at all.
I'll report on my findings once I've completed the testing.
Another noteworthy aspect of the way the line-in jack's mode can be switched between mic-in and line-in is where the audio goes and how the files are labeled. The H320's hard drive comes preloaded with a directory named RECORD and it has two subdirectories named AUDIO and VOICE. In my tests, when recording in the mic-in mode, the resulting files were saved in the VOICE directory and, as you might have guessed by now, when recording in the line-in mode the files are saved in the AUDIO directory. The files are named VOICE000.MP3, VOICE001.MP3, and so on (or AUDIO000.MP3, etc.).
These aspects of the H3x0's fairly sophisticated recording setup also draw attention to two major problem that almost all MP3 player have: there's no way to delete files through their user interface and bi-directional synchronization (where new files on the device are auto-synched back to a PC) is not supported. These are inconveniences from both a recording point of view as well as a podcast consumption point of view.
From the recording point of view, recordings are in many ways like digital photos. You have this device that you can use to make recordings of the world around you. Like with digital photos, the chances that you'll want to delete some of them within moments of recording them is pretty good. There's no way to do this on the H320. More of minor nit is that in order to get the files back onto the PC where a podcaster might edit them and eventually move the final MP3s onto a public-facing Web server, you can't use the H320's media mode (discussed in Part A) as a way to have them transferred whenever the H320 gets synchronized with Windows Media Player. Synchronization with WMP only goes in one direction (from PC to the MP3 player).
While the user can connect their PC to the H320 through its data port (putting into USB hard drive mode) and physically copy the files from the H320 to some directory on the PC (the workaround), the lack of bidirectional synchronization, along with the inability to delete files on the device draws even more attention to one reason that most MP3 players including iPods make for really lousy podcast consumption devices. The reason is that, unlike with music, podcasts are the sort of thing that most people will only listen to once (they might save a few). When they're done listening to podcasts, people will probably want to delete them. If podcasts could be deleted from an MP3 player and synchronization was bidirectional, then theoretically, in the same way that the deletion of an audio file on the PC results in the deletion of the same file from the MP3 player, the same would be true in reverse. In the programming world, this sort of tidiness is often called garbage collection. So, when discussing the issue in the future, I'll call it podcast garbage collection.
The garbage collection problem is one reason that PDAs such as the PocketPC might be more ideal for podcast consumption. With podcatching clients like Spookum (formerly iPodderSP and iPodderPIP) for Microsoft-based handsets, the PC is taken out of the equation altogether which means you won't end up with "expired" podcasts hanging around your PC's hard drive. When you delete them from the PocketPC, they're gone for good. Even if you do use the PC to go the podcatching and then route the resulting MP3s to a PocketPC, the PocketPC (unlike MP3 players) depends on Microsoft's ActiveSync which is bidirectional. But going the ActiveSync route has its own set of issues. For example, easily routing the podcasts from Windows Media Player, into the PC's ActiveSync auto-sync directory, and onto the PocketPC's Secure Digital or Compact Flash memory expansion card as opposed to its main memory which often has limited capacity (boy, I can't wait for the first PocketPC SmartPhone with a built-in hard drive).
here's the question of whether the PocketPC can double as a good recording device the way that something like the H320 can. The answer may like in the testing of Core's CF-based, PocketPC-compatible sound card and the accompanying software (see , neither of which I've laid my hands on yet.
Apologies in advance: I'm about to head out on vacation for a week and will be incommunicado. But I really wanted to get this piece out before I left. So, apologies for any typos and I hope to add more pictures and links to examples of audio (to make some points) when I get back.