Category Archive

Ars Technica: Net radio “compromise” hinged on DRM adoption

The source also tells me that DRM is the only plausible “tool” at the disposal of webcasters to accomplish SoundExchange’s goal of working to stop music “streamripping.” It would appear that the more things change, the more they stay the same. The music industry is very worried about users recording Internet radio for the purposes of “disaggregating” music, and the message seems to be that if webcasters will scratch the industry’s back, then a better deal is possible. Too bad it’s a deal that could kill another potential avenue of fair use (recording radio), and limit users’ ability to enjoy radio by limiting playback to clients that support DRM.

Repeat after me, RIAA: “Streamripping librarians are not your customers.” DRM is way too high a barrier to prevent stream ripping. I disagree with the notion that stream ripping is commonly used to create libraries of music. More likely, it’s used to timeshift; that’s a fair use. The first hurdle to make it harder to stream rip would be to require HTTP authentication to connect to a stream.

The RIAA’s fight against internet radio will most likely succeed in driving the industry underground into the long tail, where it would be impossible to get station logs and collect royalties. Of course, at that point, they probably won’t care; they’ll refocus on traditional broadcasters.

I moved the main ICYG streamer over to FB2K 0.9.4/Oddcast 3.1.15 the other day. I’m shutting down the old website. The new player is populating both last.fm and foosic with playback info; they’re both neat services. Since the links on the old website weren’t generating sales, it seemed pointless to maintain the site. I’m generating unique-artist playlists every 4 hours now; I’ll probably increase the playlist duration as time goes on. This thing is pretty much vanity at this point, but I’ll continue to keep streaming. I like tuning in the mix and continuing to test the boundaries of the software.

Thanks to Oddsock for updating his excellent streaming DSP Oddcast to support foobar2000 0.9.x. I certainly wasn’t one of the ones bugging him about it, but now that it’s here I’m playing with it. This was a great time to do so, as FB2K 0.9.4 came out recently. And I’ve been thinking about changing around the ICYG back-end.

I’ve got a decent FB2K/Continuator/Oddcast chain going, with 44.1kHz Stereo Ogg Vorbis streams of Q0 and Q8 (in-home only) and a 32kHz Stereo 64kbps CBR MP3 stream. I’ve confirmed that FB2K 0.9.4 now supports FLAC streams; however, in my limited testing so far I’ve found that Icecast develops CPU usage problems when dealing out a FLAC stream. I’m eager to see if I can serve one out within the house stably, but for listening purposes the Q8 Vorbis stream is just fine.

I’ve got an instance of Winamp and Eric Milles’ Remote Speakers Output plugin that I’ve got going 24/7 listening to that Q8 stream and pumping it to the Airport Express attached to our stereo. Hi-def ICYG in the living room is a nice thing to have! And Ryan likes it when he hears the station IDs he recorded over 2 years ago come on…

My oddsock swag. The worthy will receive a bumper sticker. Thanks, Ed!

I’ve been using oddsock’s Oddcast for years now to stream music around the house and to friends. He (Ed Zaleski) is also the guy who’s maintained the Win32 port of Icecast for a number of years (and I believe he helps with the core programming as well). Soon I will be able to proudly promote Oddsock’s site and wares in convenient t-shirt format; I won a mail-in contest that Ed held recently.

Thanks to Ed for maintaining free, quality streaming tools for us audio nerds for all these years.

I’ve played with Rogue Amoeba’s Airfoil For Windows Beta on and off over the last few days and it’s just not reliable enough for me to consider purchasing a license for at this time. I’ve been able to get it to redirect my laptop’s WaveOut to the Airport Express, but moderate CPU/disk activity (such as firing up a browser to post this) causes stuttering and gaps in the playback that are definitely not caused by the source application or limitations in network bandwidth. Even in the absense of other active applications, the audio occasionally skips. iTunes streaming to the AE is rock solid on this system in all but the most stressful situations. Something about Airfoil’s hijacking technology isn’t fully baked, at least on this config (a Compaq Evo N610C 2.0GHz P4 running WinXP SP2 with a Wireless-G connection to the AE).

I’ve also found Eric Milles’ Remote Speakers plugin for Winamp to be highly stable, even though it’s certainly not as flexible as Airfoil. But I don’t want any arbitrary audio output to go to the AE, just the output from my media player of choice. Now if we can just get Eric or someone else to port his work to Foobar 2000…

Regarding my ogg123/Justeport recipe: it turns out that ogg123 starts introducing sharp bursts of attenuation after about an hour or so of use. Its status indicators don’t indicate anything’s wrong with the audio data it’s receiving from the stream. Since I know other clients can read the stream without these problems, I think ogg123 is introducing the artifacts. I’ll have to look around for another command-line Windows program that can tune into an MP3 or Vorbis HTTP stream and pipe to stdout.

I piqued Keith’s interest when I proposed that we combine his programming knowledge with my audio geekery (and very limited C++/C# knowledge) to attempt to write an AirTunes-compatible DSP plugin for Foobar2000 using the Justeport source code as a reference. We may be able to get started in a week or so, once we’ve both had a chance to look over the FB2K SDK and the source code in question. I don’t know of anyone else doing this, so if you find a reference, please let me know.

After a bit of research and some experimentation, I think I’ve found a reliable iTunes-less way to send ICYG (or potentially other audio streams) to the Airport Express. I encountered two problems finding a solution that involved a Windows command-line utility: almost none would read an MP3 or Vorbis HTTP stream, and the few I found that did didn’t support writing to stdout so that I could pipe them into Justeport.

I’d heard of mpg123 and the corresponding Vorbis utility ogg123, but I’d never used either. I found that the Cygwin utility set includes ogg123, so I started experimenting with its options to pipe out raw audio for Justeport to use. I hatched a Q8 Vorbis stream on ICYG and quickly got ogg123 to tune in. My first attempts to pipe to Justeport failed, but since I knew ogg123 was producing data, I figured it was probably a buffer overflow.

As I type this, I’ve had a successful ogg123/Justeport/Airport Express connection for about 45 minutes. Here’s the command line I’m using:


ogg123 -q -b 256 -d raw -f - http://<username>:<password>@<servername>:<port>/<streamname> | justeport - <AE IP address> 0


The ogg123 options:

• -q = quiet mode (no status messages)
• -b 256 = 256kB input buffer. Without this, Justeport would disconnect after a few seconds. I assume its buffer was overrun and it gave up.
• -d raw = output raw audio
• -f - = output to stdout
• The URL of the stream is normal HTTP syntax.

The Justeport options mean to grab input from stdin and talk to the Airport Express at the specified IP address with the volume set to unity gain (0 dB).

Thanks to DVD Jon for Justeport and the Cygwin team for including Ogg Vorbis tools in their distribution!

Right now I usually tune iTunes in to the in-house 320kbps MP3 ICYG feed if I want to feed it to my Airport Express. That means the music has gone through three encoding cycles before it reaches my ears:

1. Original encode to a file: MP3 or Ogg Vorbis (lossy), rarely FLAC (lossless)
2. Transcoded by Oddcast for transmission to Icecast: MP3
3. Transcoded by iTunes for transmission to Airport Express: ALAC (lossless)

I could mitigate the multiple-lossy-encoding problem by storing more of the source music losslessly, but I have a pretty large library of stuff that doesn’t sound that bad encoded the way it is. What I’d really like is a DSP plugin for Foobar2000 v0.9 that would shoot a copy of the audio out to a specified AIrport Express. I wonder if an enterprising FB2K plugin developer might be able to determine whether a plugin utilizing the Justeport code (or equivalent functionality) would be feasible. I’d probably pay $30 for a plugin that did that.

In the meantime, I was hoping to use Justeport or an equivalent (if there are any) to run a Windows command-line OGG or MP3 stream reader and pipe it to the AE. However, I haven’t found a command-line decoder for either format that can read the stream (most want to read just files) and pipe to stdout. If anyone reading this knows of one, could you please reply in a comment? I thought VLC might be a way, but I can’t figure out the options I’d need to use to get it to do this.

Just happened to browse over and see that the Icecast team released v2.3.1. What makes me the happiest:

Fixes for 2.3.1
[..]
An audio glitch was possible in playback of vorbis streams when a new logical stream started (eg metadata update).

I’ve noticed this from time to time over the course of listening to ICYG. I think I even posted about it to Oddsock’s forums, thinking it was a Oddcast problem. That reminds me, I have to upgrade to the recent Oddcast v3.1.6 release as well. Thanks to Oddsock for continuing to work on this stuff.

Update (12/1): Took advantage of an unexpected breaker trip (darn basement heater) to get Icecast and Oddcast upgraded. Things sound great. I’ll have to listen closely to the stream to see if the metadata skip is truly gone.

Every few months I go check out Oddsock’s site and leech the latest version of his fine Oddcast for Foobar 2000 and the Win32 build of Icecast. I went out checking this week and found and installed Oddcast 3.1.2 and Icecast 2.3.0. This combo supported AAC streaming a while ago, but the free AAC encoders available didn’t sound better than MP3 at 64kbps to me, so I didn’t implement AAC. Vorbis at 64kbps (quality 0) is quite formidable. When I read that Winamp 5.1 included a free AACplus encoder DLL that the new Oddcast could take advantage of, I was immediately intrigued and had to try out a 64kbps, 44.1kHz, stereo AACplus (which I found out is high efficiency advanced audio coding plus parametric stereo - HE-AAC+PS) stream.

Foobar 0.8.3 refused to play the stream. I don’t think it supports AACplus natively. However, the FB2K 0.9 betas do support it, but while it plays the audio beautifully, it doesn’t show the metadata. Winamp 5.1 supports the stream fully, and sounds almost as good as Vorbis Q0 to my ears. I hear just a little more high-end warbling with AACplus, but it’s very listenable.

One hope I had was that I’d finally be able to stream a 64kbps 44.1kHz stereo stream to my Mac ICYG brethren, but it turns out iTunes 5.0.1 doesn’t support AACplus. Ugh. Two steps forward, one step back.

I’m happy to welcome Ross to the ICYG music club. Sharing a fresh set of tunes with us, he challenged my scripts with iTunes-encoded AAC files, which I hadn’t taken the opportunity to play with previously. It turns out that while FB2K handles them fine, mmpython doesn’t parse their metadata. My playlist picker requires mmpython-provided metadata from all eligible songfiles, so this produced quite a gap.

In researching this, I’ve found that it appears that Apple hasn’t formally specified their metadata implementation. Since I couldn’t find any Python code to read the metadata, I took advantage of the fact that FB2K could add new tags to the AACs, as well as transfer all the tags over to transcoded Ogg Vorbis files created via its diskwriter. The resulting Oggs are well-behaved and we can now check out Ross’s stuff.

Slightly related topic: Amazon’s increased their thumbnail image size to 75×75 pixels for the CDs they carry.

I’ve just upgraded ICYG’s Oddcast instance to v.3.0.7 (thanks, Oddsock!) and reinstated Captain Footure’s Continuator plugin, version 0.2.4. Things are going good so far. I can deal with no crossfades, but the stream sounds more “pro” with them. Here’s hoping everything stays stable!

I’ve just upgraded ICYG’s Oddcast instance to v.3.0.7 (thanks, Oddsock!) and reinstated Captain Footure’s Continuator plugin, version 0.2.4. Things are going good so far. I can deal with no crossfades, but the stream sounds more “pro” with them. Here’s hoping everything stays stable!

I set up a virgin FB2K v0.8.3/Oddcast v3.0.3 instance on my server a few days ago and let it run randomly through the ICYG song library, adding in various processing and features to the point where it was just “production-ready” yesterday evening. After going live last night, it’s been healthy! The only feature I’ve taken away for now is the detailed ICYG block here. It had been generated by a periodic query of the HTTP Writer FB2K plugin. I think I’m going to rejigger that process to query a specially-crafted current-song RSS feed generated by the ICYG website as opposed to by the FB2K instance itself. I don’t necessarily think that that component caused the Oddcast instability; I had a lot of plugins in the old FB2K instance.

This means Jonathan can check out the ICYG MP3 stream again…

Update: It started crashing again, after I had started fiddling with settings on the “Continuator” DSP that provides the pleasant crossfading. I tried setting Continuator back to its default settings, but FB2K still ended up crashing a few hours later. I’ve removed it for now to verify whether or not it is indeed conflicting with Oddcast. The FB2K crash reports cite Oddcast as the source of the crash, although that’s probably because it’s the last DSP in the chain or it’s trying to handle a song-changing scenario that’s complicated by Continuator.

Not being very up on AAC encoding, I didn’t realize that at low bitrates (like the 64kbps target I have for ICYG streams), FAAC doesn’t appear to perform much better than LAME MP3. While HE-AAC/AACplus would perform better and compare favorably with Vorbis, there’s currently no free implementation of it available. Since Oddsock has stated that he won’t link Oddcast to non-free DLL’s (which I agree with), I don’t see much purpose in implementing it at this point on ICYG and have removed the experimental AAC stream.

This leaves us with the ~64kbps stereo 44.1KHz Vorbis stream and the new 64kbps stereo 22KHz MP3 stream. If you’re using the MP3 stream and have comments, please post them.

I hadn’t been visiting HydrogenAudio lately, so imagine my surprise when I read that new versions of both Icecast and Oddcast are out. Oddcast v3 has me absolutely salivating; it now supports multiple simultaneous encoders from a single source. If it works for me, this will allow me to support both Vorbis and MP3 (or possibly AAC) ICYG streams, which I’ve been wanting to do since Jonathan told me he hadn’t been able to listen to the current Vorbis stream on OS X with iTunes. Many thanks in advance to Oddsock for his continued work.

MNF tonight is a snoozer, so I should have some time to test and possibly complete both upgrades on ICYG tonight. If/when I have an MP3 and/or AAC stream live, I will post appropriate info to the “official” ICYG forum over at Nitevilla.

Update: I now have Vorbis, MP3, and (experimental) AAC streams going thanks to an upgrade to Oddcast v3, and my Icecast server was successfully upgraded from 2.1.0 to 2.2.0 without any problems once I massaged the config file. The efficiency of the FB2K/Oddcast combo when encoding all three streams is quite remarkable (averaging under 10% on my P4 2.4GHz server). I had to cut the sample rate of the MP3 and AAC streams to 22050Hz to get them to sound reasonable at my target 64kbps bitrate. The AAC support at this point seems a bit rough in Oddcast; I’ll play around with it and see how others are making out as well.

I’m starting to gather the songs to play during a two-day ICYG Christmas Special. If you’re a member and have appropriate material to include, please tag and upload it ASAP and let me know what/where it is. I’ll finalize the playlist sometime Thursday and it will go live the morning of Christmas Eve. We’re hosting my parents this coming weekend and it will be a great opportunity for them to hear my hobby.

As always, I’m going for a rock theme and I’m drawing on some good stuff: the two Merry Axemas CD’s, the new Brian Setzer Orchestra Xmas CD, the aforementioned Central-PA Christmas Compilation CD, and various seasonal tracks from some of my favorite bands. Certainly not the catalog of a “real” station but decent enough for our purposes.

I’ll probably start working on tweaking the ICYG playlist generation code/methodology soon. I think I’m going to go to an hourly playlist generation scheme that takes into account several factors:

• Every hour of programming is defined as either full rotation or things like specific genre hours, indie-only, or specialty shows; I plan on having at least two variables to choose from for each hour (ex: an auto-generated “Scott’s Metal Hour”)
• Target playlist length: 60-61 minutes
• Other things I haven’t thought of yet.

I also want to take this opportunity to do two things I haven’t done yet: create actual object-oriented Python code and integrate this process more with Zope.

I’m also going to actively try to find more independent music (remember, Magnatune’s catalog is fair game for non-commercial streaming and podcasting) and also try to get together enough time and stuff for a weekly or biweekly “Nuclear Rock” show that would be available both through ICYG and as a podcast from this site.

Doug Kaye is stimulating some good discussion about making money off of podcasting.

I think a one-size-fits-all MP3 file per interview/podcast with one or more randomly-placed ads or requests for donations is appropriate for free download. Paying subscribers could possibly have access to more detailed, ad-free content, perhaps in “enhanced packaging” like the chapterized Ogg Vorbis files that I’ve blogged about before. Doug’s previous idea of allowing custom RSS feeds per user is also a good pay-for-play feature.

I had a goal of figuring out a method of directly querying MP3 and Vorbis metadata from the Python scripts that power ICYG over this vacation. I think I’ve met it.

I finally found mmpython, a comprehensive Python library dedicated to querying media metadata. This was the first time I’ve installed a library into a Python instance, as opposed to dumping a single module into the lib directory, so it was a good learning experience for me. After installing it and looking at its invocation method in the supplied script, I quickly figured out how to use it to query a particular songfile for metadata info.

Currently, I ask ICYG members to sort their music directories by artist so that my song-picking script can parse those names to make sure it’s spreading picks out between available artists. With this enhancement, I’ll have the script query each eligible songfile for the artist information. I’ll also be free to pick using other base metadata info if I want.

I say base metadata because apparently the free-form non-default tags we use for artist and purchase links aren’t available through mmpython. That’s OK though, since I extract that info out from the play log, not via a direct query of the associated songfile or its path.

It’s alive! And it’s valid!

I like learning things when scratching itches. This was truly fun to figure out how to do.

Update: Looks like I have to deal with some unicode issues. I think allowing unescaped ampersands in the description data is making the feed invalid at times.

Update (11/15): The Python recipe mentioned in the comments seems to have done the trick. I’ve also added GUIDs and taken out the redundant date info from the item contents. If you’re using the feed and would like to see something implemented, please leave a comment.

The first 100 times I’d checked out Oddsock’s Stream Transcoder, I don’t think I fully appreciated what it did. Turns out, it’s the perfect tool to solve this problem. After a quick configuration, I fired it up and it’s taking a “master ICYG” Vorbis Q10 stream, transcoding it down to ICYG’s normal Quality 0, and directing it to the public ICYG mountpoint. Too cool. Thanks to Oddsock for the tool.

Update (11/12 8:20a): ST wet the bed overnight and was running in a non-working state when I went to check it. It wasn’t sending output to the Icecast server at all. I killed it, cranked the master ICYG stream down to Q8, and restarted ST.

Update (11/13 8:27a): ST stopped working again. I’m removing it from the mix for now. I’ll have to look for some testimonials to see how others are using it. Perhaps the Unix version is better? I don’t want to compromise the quality of the public Q0 stream by two recompression cycles that are too harsh.

I put Icecast 2.1.0 in place last night and it was working great for Scotbuff and me. Besides the HTTP authentication working properly, the burst-on-connect feature seems to help the stream start playing more quickly. I’ll probably play with the burst buffer size a little at home to see what works best.

The admin web interface of Icecast has been improved as well. With the required authentication, I can now see what user each active session belongs to, instead of guessing a club member by the IP address displayed in the interface.

I’m enjoying the Bills game right now (thank the scheduling gods) and while surfing I just found word of a new Icecast release on their site. What interests me most is the “listener authentication” feature, which I’ve wanted for ICYG since I launched it. Other new features include “multi-level fallback” (which I assume is server-based stream substitution, as opposed to pointing several streaming clients at the same Icecast mountpoint and letting them butt heads) and “burst-on-connect”. Can’t wait to check it out. Thanks to the Icecast team for their continuing development.

I came up with a way to have a single-sourced ICYG available at high and low qualities without using multiple instances of Foobar2000. I changed the main FB2K instance’s streaming to Vorbis Quality 10 (as good as it gets), and I have a Winamp/Oddcast instance tuned into that and streaming it out at Quality 0 at the normal ICYG URL (which is still for club members only). The only potential downside (besides being once again at the mercy of Winamp’s stability) is that the extra decode/encode cycle may affect the quality of the Q0 stream. I’ll take a listen to it and see what I think. You ICYG members: please let me know if you hear a difference.

Via ipodder-dev mailing list: This is a letter that Adam Curry recently received:

Just wanted to touch base with another way that iPodder can (and is) being used. I can selectively subscribe to podcast feeds here at Whole Wheat Radio (www.wholewheatradio.org) and let iPodder pick up them up on a timed schedule. I’ve adapted my software that runs the station to look in the Downloads directory of iPodder and when it sees a new MP3, it can queue it up and play it immediately on the webcast. It’s pretty neat to have short clips play between songs. (I filter out any audio that is longer than 10 minutes…)

So not only can an iPod pick up and play audio, but webcasts can do the same thing. Cool!

Jim Kloss
Talkeetna, Alaska

Great idea. When I blogged about the possibilities of streaming podcasts, I was thinking of it a bit more statically than Jim. Perhaps a daily schedule update. One of the things that’s great about a dynamic playlist is that you can get content online at its freshest.

I’m considering investing time into creating a stream that would encompass the following:

• Subscribe to a list of podcast feeds (published on the stream’s website) that would be polled on a relatively agressive schedule. New content would be downloaded immediately.
• Parse as much metadata about each podcast as possible for display on the stream website. This would include the tags on the audio file, as well as information in the associated RSS entry.
• Run a scheduling algorithm that favors new content and schedules it to be streamed ASAP. As content ages, it is queued up less often.
• The stream website would inform readers of queued content, estimated play times, and would display metadata and hyperlinks associated with each podcast.

My hobby programming projects are born out of a desire to scratch a personal itch, but if you guys have any feedback, please share it. I think creating this would be a fun exercise.

For a while now I’ve been wanting to be able to run multiple instances of Foobar2000 on the desktop that powers ICYG. The extra instances could be used for a number of things: a parallel instance of ICYG streaming at a higher bitrate (the version I’d listen to over my home LAN), streaming different stuff like podcasts, or simply doing song/playlist management without interfering with the “production” ICYG player instance.

One of the neat features of FB2K that I’ve leveraged when scripting ICYG is invoking the .exe while it’s already running allows one to send controls to the running player instance. It’s how I change and load playlists on the fly. However, that feature (along with other dependencies, I’m sure), prevents you from launching another FB2K process with the same executable file instance.

This has been a nagging issue, but one that never bugged me enough to research. I’d turned on the per-user profiles toggle in FB2K that tracks preferences for each user, so that when I run it on my server as my normal user account, it doesn’t load up all the DSPs I use to stream ICYG. And for song/playlist management, I just do all of that in a session separate of the session running the production ICYG.

Well, all of that will change now. After a little digging, I found this nugget on HydrogenAudio when doing a search on “multiple instances”. Hmm… install different instances of FB2K in separate directories… What am I missing here? I assumed that FB2K was one of those apps that would let you install only one instance on a particular OS instance. Well, that’s not the case. You can install separate instances of FB2K anywhere you like on the system and run them independently of each other at the same time. They can even map to the same output device. COOL!

If the command-line control functionality continues to work flawlessly with the other instances I plan to install on my server, I’ll be a happy guy.

This will make some work for me, but it’s for the better. I need to document all the current settings I have in place to run ICYG (which are tied to a service account) and then uninstall the current FB2K instance and reinstall fresh in the default location (C:\Program Files\Foobar2000\), selecting not to use per-user profiles. I’ll accept the default associations for the supported music file types, and it’ll only be used for non-streaming (i.e. interactive) activities. Then I’ll install a second instance that’s local to the directory hive I’ve got all my other ICYG stuff in and change my scripts to point to it. However, I’ll make sure not to associate this instance with any file types or make any program groups or icons; I don’t want to accidentally trigger it outside of the ICYG role. Then I’ve got to customize that instance with all the DSPs and settings I documented before. After I’ve done that I can hatch additional FB2K instances in the same manner for each stream I want to serve.

It’s amazing how sometimes the simplest solutions don’t immediately present themselves.

Update: I believe I’ve verified that simply copying a working FB2K installation to a new location successfully creates a separate, working instance with all of its own settings. Also, to turn off per-user FB2K profiles, you can go to Preferences/Core/Startup and uncheck “Enable user profile support”.

Over lunch I was listening to the 10/2 Gillmor Gang recording from Gnomedex 4.0 (via IT Conversations). Podcasting, RSS, enclosures and the like were discussed; it got me thinking that another way to consume podcasted content is via streaming. Based on my ICYG back-end, combined with a downloading tool like iPodder, one could automate the download, preparation, and streaming of podcasted content. Code would have to be added to manage the content subject to be streamed at any one time, but that wouldn’t take much time at all.

There would certainly be downsides to consuming podcasts via streaming. If there is no way for the user to select what they want to listen to, they may have to wait for content they are interested in. If the streaming platform transcodes the content (in either the audio quality or codec domains), there may be a loss of information (stereo/mono) or quality. However, the upside of not having to manage the podcasted content on a portable device might make it worth it for some.

I may take the initiative to hitch something like this up just to prove the concept. One of the challenges will be parsing and presenting the podcasts’ metadata on the stream’s website.

It seems to me that a grey area here is whether or not podcasted content is inherently free to redistribute (before or after mangling). I suppose any podcasted content that you can download without agreeing to a license implies that you’re free to use it as you please. One innovation in this area might be the introduction and standardization of Creative Commons licenses metadata to communicate a podcast content creator’s intent.

I’m working on coding some more around the current data model of ICYG. I added an albums page that works similarly to the existing artists page.

I’m thinking of creating private XML feed(s) for members that would include recently played songs (similar to the ICYG front page, but in a format like RSS/Atom), and perhaps detailed info about the currently playing song. If it’s possible, I might also code a “coming up” feed that would list the next five or ten songs in the playlist. However, with my current implementation, that would be inaccurate around the time of a change in playlist (the daily 4AM load or a show start).

That’s part of the fun of a project like this: thinking of things you’d like to implement and learning how to do so. Again, your ideas are welcome.

I’ve meant to write an entry about the architecture of ICYG for a while. The “audiotech” and “webtech” buttons should give you an idea of the major components I’m using. Basically, I’m running a Foobar 2000 instance that has compression/limiting DSPs on, feeding the Oddcast DSP, which pipes the audio to an Icecast server instance running on the same server. Clients (currently ICYG club members only) connect to the Icecast server over HTTP to listen to the stream. I have Python scripts that create playlists based on certain parameters, and various FB2K components schedule playlist change events and log information about content that’s been played. The ICYG website runs on a Zope instance on the same server; the “played content” log file is read and parsed dynamically upon page requests by WWW clients.

I’ve cobbled together ICYG, but it works pretty well. But I’d like it to be so much more:

• I’d like it if I could run FB2K in “headless” mode, as a service, and control it through an HTTP interface (perhaps enabled by this component. Control via Telnet is possible, but it’s limited. I haven’t yet tried brute forcing this with something like FireDaemon, though.
• I’d like it if Oddcast had support for multiple output formats and/or resolutions. I would love to be able to output ICYG’s normal 64kbps Vorbis feed along with a higher-resolution Vorbis or MP3 feed for listening on another computer inside my house (or possibly a Squeezebox). Shoutcast does this; but there’s no Shoutcast component for FB2K. And I like running Icecast as my server.
• I’d like it if I could buckle down and figure out a good, consistent way of recording and retrieving feedback about individual tracks that have been played on the station. I’m really not much of a database guy.

More “all-in-one” PC-based media server solutions are coming around, doing things similar to what I’ve implemented with ICYG; however, without features such as intelligent crossfading and extensive playlist management, they’re not of much interest to me.

Anyone else have ideas or more feedback about ICYG?

I was always interested in the SliMP3, but it always seemed too expensive for my uses. However, the new Squeezebox by Slim Devices is very interesting. It’s still a pretty penny, but its breadth of capabilities may be worth it. Being able to stick it (the wireless Ethernet version) anywhere in the house and stream uncompressed audio to it is quite compelling to me.

I’m going to check out the SlimServer software to see how flexible it is. It looks like it supports non-proprietary MP3 HTTP streaming.

Via HydrogenAudio: I’ve always admired Roberto Amorim’s listening tests that compare the quality of various audio codecs. I’ve neglected to submit results in many of his previous tests, but I’m going to try to participate in his current 32kbps test.

Over the years I’ve tried streaming MP3 and Vorbis at low bitrates, sometimes reducing the samplerate of the source to make it more more compressible. I’ve always been sensitive to that; currently I stream ICYG at 44.1KHz stereo Vorbis Quality 0, which is quite efficient (averaging 64kbps or less) and sounds OK to me for what it is. I want to participate in the listening test to see how development is going in the low-bitrate world, and to see how Vorbis compares to the other players. I probably won’t change my streaming specs as a result, though. We’ll see.

I encourage any of you reading this to participate, as more opinions will increase the validity of the test.

Update: Darn. With all the holiday activity I must have missed the original announcement. The testing period is scheduled to end today. I may not have time to take it.

Update 2: I took the entire test (kind of quickly, but I took it) and submitted my results. Boy, 32kbps can make a lot of stuff sound like crap.

I’m glad Scott’s excited about the upcoming hour-long member-created shows that I’ve planned to start “real soon now” on ICYG. That’s part of the reason I thought it would be a neat project: the ability to change things as we go along and add new features.

Read the rest of this entry »

The ICYG Artists page is officially out of beta.

After I get some CSS tweaks done on the site, I’m going to comb through the whole thing to see if I can optimize it further.

I’m about to throw the switch on a few changes on ICYG. To this point, most of the content has been mine, with member submissions every few songs. Over the last few months, I’ve more frequently tapped into the submissions pool. Well, there’s so many member submissions that I’m about to “memberize” myself and start picking from each of our submissions more equally. It’s getting to be a great mix of artists. If I have time this weekend, it will be done. Here’s the highlights:

• The concept of “anchor” artists (who get play every rotation) will be removed.
• The artist history will be increased from 17 to at least 25. This means a particular artist will be played less often.
• All songs will be picked from member submissions.
• I’ll program the picker to iterate though the member list as it grabs each song. Members who have a larger number of submissions will probably get more play, subject to artist history. This will probably need to be tweaked.

I’m also looking to parse ID3 tags and Vorbis metadata in lieu of file pathname info when doing the picking. I’m looking at a few solutions now; it’ll probably require using a library external to Python.

I’ve been having fun creating the ICYG Website over the last few days. I’m using it as an opportunity to get down-and-dirty with CSS, Zope, and Python scripting. There’s not much there now, but it will continue to get tweaked and fleshed out as the weeks go on.

One thing I noted in an email to Don was that I don’t know of any streaming audio providers that appear to be generating per-song URL information through tag infomation. The stuff I’ve seen (like SomaFM’s “recently played” pages) appears to use database-lookup URLs based on text substitution. Am I onto something here?

From Kicking Ass: Air America Radio is going live today at noon and says it will be streaming over the Internet for those who don’t live in one of their radio markets or have XM. This should be interesting. I’ll probably try to check out the stream tonight.

My idea was well-received; five of us are about to start seeding the revamped ICYG. I’ve been working through FTP server issues, but I believe they’re now licked. Scott was nice enough to launch an ICYG members-only forum for us on his website, so the communications hub is online. I need to start working on a dedicated ICYG website, but for now the block here will have to do.

Once the new ICYG goes online, you’ll see member info displayed along with the current track, corresponding to who contributed the track.

I’m still in the midst of getting all my thoughts together regarding my tutorial on cheap streaming audio, but I wanted to get an idea out and see what some of you thought of it.

First, note the new category on this post. I don’t think there are a lot of people blogging about streaming audio, so I plan to do more of that. Probably more specifics than generalities.

Lately I’ve been thinking more about community building around streaming audio. There are drawbacks to trying to create a publicly available stream; the two largest are bandwidth and licensing. Keeping the stream private (whether through security or obscurity) limits the audience but holds legal issues in check. However, one person’s programming (music and/or talk) probably won’t appeal to everyone.

This is where my current idea comes in. Back in college I was exposed to a ton of new music by borrowing and listening to (and many times, taping) my friend’s CDs. The melting pot is still bubbling today (at a low simmer); the medium is now digital music files. Applying this paradigm to streaming audio, I came up with this idea for an online “music club”: (which enterprising college students with music, computers, software, and on-campus bandwidth have probably done, but perhaps I’m not giving myself enough credit):

• Launch a private streaming server, using an unpublished URL or a server that authenticates. (Since Icecast and free streaming clients don’t support authentication yet, obscurity is the method I’m using.) Only club members will be provided the stream URL.
• Allow friends to participate in the club by uploading tracks they’d like to share with everyone else to their private home directory on the streaming server. Cap it to a relatively low number of tracks (say, 100 tracks or 500MB, whichever comes first) to encourage them to cycle their music every once in a while. The music files should be tagged with accurate info, and can also include items like artist web links and purchase links that could possibly credit the club member with a sale.
• A periodic process will populate a playlist using equal amounts of tracks from each member. A “recently played” artist/song history will be enforced to maximize variety.
• The playlist will be used as the stream source, pleasantly crossfaded and available 24/7. Members tune into the stream whenever they want, and can also check out a website that provides info about the most recently played songs (including artist & purchase links if available, and perhaps other metadata). The participant who shared the track would also be noted.
• A forum or mailing list could be used to discuss things related to the club.
• Future features could include things like allowing members to vote for tracks they like, with the feedback influencing playlist frequency for highly-rated tracks.

If this interests any of you, please post. I’m willing to host such a service, since I’ve got about 90% of the required infrastructure done. I have bandwidth limitations, but on a small scale (10 participants or less) this would probably work fine. Going forward would certainly require more specification (acceptable codecs/bitrates/tags/clients) but it can all be done with free software.