Contents tagged with Ideas

  • [feature request] Podcasting Client Audio Post-Processing

    I'm mildly interested in Podcasting. I've been test-driving it for a week and will probably post my obligatory YAPO (Yet Another Podcasting Opinion) writeup soon.

    I think it's safe to say that Podcasting is a kind of useful application of RSS to simplify the repetitive task of downloading periodic audio programs. With that in mind, Podcasting clients like iPodder could really add some utility with audio post-processing. Here are some things I'm thinking of:

    1. Split large MP3's into smaller files for players that don't bookmark or fast-forward slowly. I previously posted some information on how to split DotNet Rocks MP3's with mp3splt). I'd like Podcasting client to automate this. It should be configurable, but at a minimum should let me say "split into 2 minute chunks" or "split into "10 minute chunks", etc.

    2. Time Compression - a lot of people have rejected Podcasts because it takes too long to listen through them to compared to the amount of information you receive. In WMP I usually turn the speed tup to about 2x and still get bored sometimes, but most MP3 portables probably don't allow speeding up the play speed. Podcast clients run in the background on powerful modern computers, though, so they should have no problem re-encoding the audio a higher speed I get to pick.

    3. Add background music - during my commute, I regularly flip between music and spoken word (books on tape, NPR, talk radio, or Podcastable content like DotNet Rocks). There's no reason the two couldn't be mixed together. I could pick a folder or list of music MP3's that would make good background music, and my Podcasting client could mix them together. Then I'd get to hear my music and get my content.

    4. Recommend similar feeds[1] - It's hard to find good content now. iPodder.org has a Podcast directory, but it's not very useful. Assuming the content selection continues to grow (and it had better or this whole thing is going down like Boba Fett), they need a webservice that recommends feeds based on the ones I've subscribed to (yes, the aluminum foil hat crowd would need an option to shut this off).

    [1] The astute reader will note that this has nothing to do with audio post-processing. Yeah, well it was one other random feature idea and I thought I could slip it by here.

  • [feature request] URL's with offsets - www.sample.com/interview.mp3#time=32:05

    Adobe's PDF Viewer, as much as it bugs me, does have one really cool feature I'd like to see spread - it allows you to link directly to a page within a PDF:

    <a href="http://www.sample.com/document.pdf#page=42">see page 42</a>
    Scott Hanselman posted about it recently, although I first learned about it while working with a website search product (iPhrase) that spiders PDF's and jumps to the page with the text you searched for.

    What a great idea. So let's take it a step further...
    <a href="www.sample.com/interview.mp3#time=32:05">hear Jon Stewart make fun of bowties</a>
    Most audio / video players can skip ahead in a file they're streaming, so why not let me link to a starting point? I've been thinking about this while forming an opinion on Podcasting. One of the main features that's made weblogs and rss successful is that they're so easy to reference and interlink. Podcasts aren't, but if I could link to an interesting part halfway through a DotNet Rocks show, for example, they might be more useful as an information and discussion resource.

    Any media player (WMP, Winamp, iTunes, Real Player, Quicktime, etc...) could add this support in today, just as Adobe did with their PDF Viewer.

    It needn't stop there, either. I think being able to reference a portion of a file resource could open some new doors. Sure, it's not as dirt simple in most cases as asking for a specific byte range in a file (which is natively supported in HTTP). But the HTTP Content-Range supports multiple range types and could be extended quite a bit. I could, for example, request a pixel range on a GIF and the server could handle this for me. Not appropriate in some cases, but helpful in others. It's a trade-off: the server does a bit more processing, but now I'm able to link to a face within a group photo: <img src=www.sample.com/images/group.gif#pixels:180,200,580,600> Servers always have the option not to support this HTTP Content Encoding / Range Type (it's built into the spec), but there's a lot more flexibility if we make it possible.

    This gets more important as we move beyond HTML and images to a technology infrastructure that runs over HTTP (SOA, RSS, etc.). Being able to request a specific segment of a resource opens some new possibilities.

    To come back to reality a bit (assuming they're not going to extend HTTP at my blog request), there are still some cool applications in addition to media time references. What about linking to a section of a web page that didn't happen to put an anchor right where I'd like to link. What about http://www.sample.com/page.html##byte:3580 or http://www.sample.com/page.html##vertical-position:1500px, etc.? The browser would load the whole page and scroll to the proper position. Sure, I might link to a byte range in the middle of a javascript function, so either scroll to the nearest HTML or refuse the anchor as invalid don't scroll. I'd be no worse off than I am now.

    I think linking to a time offest in a media file just makes sense. The other ideas are intended to spark further thought, but seem to be semi-viable to me. What do you think?