[Imc-newsroom] mp3 upload problem solved (?)

[Paul Riismandel]

I think I figured out why some MP3s upload fine, while others don't.

It all has to do with the size and bitrate of the file.  I re-encoded the 
FTAA Documentary mp3s at about 1/10 the data rate and file size and they 
uploaded and work just fine.  I don't know what the upper threshold is for 
mp3 file size, but there are some basic guidelines you can follow that 
should make things work.

When you're encoding .wav files into .mp3 you want to specify a relatively 
low bitrate.  There's two reasons for this, the first is so the server 
won't balk, the second is so that the files are small enough for modem 
users to download in a reasonable amount of time.  When I looked at the 
FTAA Documentary mp3 files on Sergei they were 320kbps (kbps = kilobits per 
second)--more than 6 times the bandwidth of the fastest POTS modem!  While 
they sound great, they're too damn big (averaging 6 MB).  Over a 56kbps 
modem, expect this to take an hour or more (or at least 6x the real-time 
length of the program).

I re-encoded the files at 24kbps and now they average about 600k 
each.  Over a decent 56kbps connection these can even be played in 
real-time, without the user having to download the whole file before 
listening.  I also converted the files from stereo to mono before encoding, 
because at low bitrates stereo sounds like shit.

If you're on Sergei and using MusicMatch Jukebox to encode your mp3s, you 
can change your bitrates in the window where you select the files to 
encode.  On the bottom right of this window there's a little slider with a 
number to the right.  Move the slider to get the bitrate you want.  It 
seems to default to 96kbps, which is too big, so you'll always need to 
change it.

Now, at low bitrates you do sacrifice overall fidelity and audio 
quality.  16-24kbps mp3s sound like AM radio, but are quite intelligible 
for speech, which is primarily what our stuff is.  In mono 64 kbps is quite 
high-fidelity, but takes 3-4 times longer to download and listen.  In this 
case we're trading fidelity for accessibility.

So here are the guidelines for encoding and upload mp3s to the IMC website:

To make your files listenable for almost any modem user (as low as 28.8 kpbs):
* Make sure your file is mono.  If you're editing in Sound Forge and you 
have a stereo file, select Process, then Channel Converter, then in the 
Channel Converter window, select 'Stereo to Mono - Use both channels (50%)' 
from the Name: pull-down menu.
* Encode at a bitrate of 16kbps -- no higher.

To make your files listenable for users on a 56kbps modem or better:
* Make sure your file is mono.  If you're editing in Sound Forge and you 
have a stereo file, select Process, then Channel Converter, then in the 
Channel Converter window, select 'Stereo to Mono - Use both channels (50%)' 
from the Name: pull-down menu.
* Encode at a bitrate of 16 to 20kbps -- no higher.

To make files that are closer to CD or 'broadcast quality' that radio 
stations can download and use:
* Make sure your file is mono.  If you're editing in Sound Forge and you 
have a stereo file, select Process, then Channel Converter, then in the 
Channel Converter window, select 'Stereo to Mono - Use both channels (50%)' 
from the Name: pull-down menu.
* Encode at a bitrate of 48 to 64 kbps.  48kbps is the minimum level for 
decent quality, making it a reasonable download for users on modem 
connections (probably will take 2x real-time).  64 kbps is near-CD quality, 
but increases your file size (and download time) by 33%.

And now, a quick FAQ:
Q: Why encode in mono?
A:  As you might expect, decent quality stereo requires about twice as much 
data than mono.  At 24 kbps you essentially have  two 12kbps mono tracks, 
and 12kbps is too low to sound good at all.  The basic lower threshold for 
listenable quality in mp3 is 16kbps in mono, or 32kbps in stereo (which is 
difficult or impossible to listen to in real-time on a modem connection).

Q: Why are we sacrificing audio quality for low bitrates?
A: High-quality takes long download times, and we cannot expect that our 
viewers/listeners are on broadband connections like we have at the IMC (or 
at the University).  We are just limiting our audience if we ask a large 
portion of our listeners to spend hours to download a half-hour piece that 
we might otherwise make available for listening in real-time.

Q: What if a radio station wants to air our pieces from the website? Do we 
want to force them to use AM radio-quality files?
A: If we expect that a file may be popular, I'd try uploading two 
versions--one at low bitrate for modems, and one at high bitrates for 
broadcast.  I'd name the file with the bitrate appended to it (like: 
ftaa_documentary_16kbps.mp3), and make sure that you mention the quality 
level and bitrate in the summary when you publish.

I hope this is helpful, please post any questions.   Though I'd prefer not 
to argue the merits of mp3 quality, stereo vs. mono, etc., since what I've 
posted above are fairly accepted standards, unless there's a magic bullets 
that can give CD-quality at modem-accessible bitrates that I don't know about.

--Paul