Audio encoding tests for Freedom Feens – listener feedback wanted

Check out these three samples. It’s all the same 75-second chunk of a recent Freedom Feens episode. It’s a part with both Neema and myself talking, and some music, and DJ talking. Test with headphones if you can. Give us your thoughts, especially if the 96k and 64K ones sound good enough for weekly listening. The file size is smaller, we may be moving in that direction if people are cool with it.

128K-stereo.mp3 (NORMAL Feens encoding. File size: 1.2 megs.)
96K-stereo.mp3 (File size: 920 K, 2/3 of NORMAL Feens encoding.)
64K-stereo.mp3 (File size: 615 K, 1/2 of NORMAL Feens encoding.)

I tried mono encoding, but for some reason, in both
programs I tried, it was the same size of stereo
encoding at the same sample rate.

We’ve been thinking about a change for a while, but got this note today from Jimmald : “Michael & Neema: Your podcasts are great, but if I may offer some unbidden advice: stop worrying so much about ultra-high sound quality. Anybody who listens to FreedomFeens listens for the content, not for high-bandwidth sound. As long as I can hear what you’re saying, that’s great. Huge files take longer to download, are more pain to copy & store etc. It’s about the ideas, as well as the entertainment value, but c’mon, your voices are not such beautiful music that we need mega-fat bandwidth high quality audio.”
-=-=-=-
I wrote Neema,

I’ve been thinking about this. Our file sizes ARE huge. NO other podcasts use 128 k stereo files (except Garrett because I trained him.) I found our archived Sunday live show VERY listenable, and it was 128 k mono.

I’m thinking with all the care we use with mikeing and recording, maybe we don’t need to put out 100 meg files, and maybe we’d have even more listeners if the files were smaller. Also, if we started doing that now, if our audience doubled, we wouldn’t have to spend more on bandwidth. We’re spending like 70 bucks a month now.

I think I’d rather put up 128 k mono files than 64 k stereo files, which would both be the same size, half the size we’re doing now. Or maybe 96 k stereo files, which would be 2/3 the file size we’re using now.

What are your thoughts? I’ll feen source it too.
Maybe I’ll do some encoding and listening tests on my end.
MWD

11 Comments

Filed under Michael's stuff

11 Responses to Audio encoding tests for Freedom Feens – listener feedback wanted

  1. admin

    Steve,

    It’s mainly in what we do before we record:
    http://www.freedomfeens.com/how-we-record/
    (especially see section on Ribbon mics), and just our general skill and experience.

    And possibly encoding with LameDrop instead of Xing (a change we only made on the last few episodes, and also we used LameDrop on these samples.)

    Cheers!
    MWD

  2. 96 K Is a nice Happy Medium but just a question, how did you get the 64 k and the 96 k to sound so good. When I encode to 64 or 96 I get the bothersome compression artifacting that makes S’s sounds whistle like etc. Any ideas?

  3. admin

    Michigan Escapee, Thank you! Very thorough!

    MWD

  4. Michigan Escapee

    GXLame is supposed to be the current best at low bitrate encoding, by today’s
    standards at least.
    In the dusty back corners of my mind I remember playing around with compression
    schemes in the 90s. The smallest you could go was to use a dialogic codec
    engineered pretty much just for voice. Next up from that, you had realaudio 2 and 3.
    RA 2 was based on G.728 aka LD-CELP
    RA 3 was based around AC-3 which didn’t sound too hot at the lowest bitrate setting.
    We’re talking 8-16kbps rates when I say the lowest settings. Absolute basement
    rate with today’s tech would be to create voice profiles in CereProc for each voice
    artist, and feed text streams to each robovoice profile.

    From the user end, all of these things would have to be stuffed into a java app, the producer would get to handle the details like licensing fees, etc, etc.

    Anyway, more dust bunnies of the old days to sift through. The problem with encoding
    is that the math doesn’t care what we consider to be significant. Run your audio through
    a spectrum analyzer app, and find the peeks, then user your audio edit program to mute those peeks not in voice range. Sometimes called u-law or mu-law filters if you really want to hammer it down to voice only spectrum. More on that here. In general, it was the scheme used by the phone company so they could multiplex more signal onto copper wire, yet keep voice clearish. http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a00801149b3.shtml

    With less useless spectrum to encode, more is allocated to what you want encoded.
    You also have less digital hash, crackle, quantization noise, or artifacting, whatever you
    want to call it.

    Old versions of soundforge4-5 had filter packs for this, your low bitrate prefilter,
    some for regular encodes, others for streaming encodes. They didn’t pound your
    raw audio down as much, so music would still sound like music.

    This guy has some ideas on the subject and writes a bit more general audience than I do. http://www.blogarithms.com/index.php/mp3secrets/

    Anyway, have fun. I’m now going to light a match and set fire to the dust bunnies and whatever is under them. :D

  5. admin

    Jimmald,

    I set my desktop to look like Windows 95, and I still love the look of craigslist. My ears have different priorities. lol.

    MWD

  6. Jimmald

    Well, you’ve probably already guessed this, but I may as well admit it: I’m the kind of person who sets his Windows Desktop to look like Windows 3.1 and thinks Craigslist has the best design of any site on the Web.
    - Jimmald

  7. Tony Lekas

    I found the 64K version perfectly acceptable. I could tell the difference between it and the 128k but I had not trouble understanding the 64K one and in fact I really had to pay attention to notice the difference. The podcasts i have trouble understanding are those that have poor sound quality apart from the encoding. I have 30Mbit down on my fiber to the home connection and plenty of space on my mp3 player so I don’t care but I think 64k is OK.

    I am 55 and have minor hearing loss, age and time on the range.

  8. admin

    I’m 47 now, and I’m finally noticing a slight decline in my hearing quality. One thing I’ve noticed is that most podcasts, which are usually encoded at 64 k, make my ears hurt.

  9. admin

    Also, my thought is this: DSL is everywhere and it’s only getting faster and cheaper. If people wanna have a scaled-down version, like for mobile, our streaming feed is 64 k already.

  10. admin

    Derek Behm, yup. I listened to all a few times each with headphones. I can’t stand anything but the 128 k.

    (For some reason when I tried doing them mono, they were the same file size as when I did them stereo. What’s up with that??? But I don’t wanna use mono, because we have so much music bits, and I don’t like music in mono. I also like the “you’re in the room with us” feel of having you and I panned a little left and right.)

    I think I don’t want to go with a lower encode unless it becomes a financial necessity at some point.

    I suppose we could do a weekly second feed with a lower encode rate for people who want it, but that’s a lot of extra work and I’m tapped out now as it is.

    Thanks.
    MWD