The Turk was a famous hoax which purported to be a chess-playing automaton first constructed and unveiled in 1769 by Wolfgang von Kempelen (1734-1804)

In other words, the mechanical Turk is about putting a human intelligence inside the machine.

New web services are now implementing this very simple principle for applications where humans are much better than computers. In fact, amazon.com is offering a new open platform for the development of third party web services. It’s called… guess what? The “amazon mechanical turk” on the theme “Artificial Artificial Intelligence”.

More interesting to you, dear readers of Broadcasting 2.0, is that some people have built a podcasting transcription service called castingwords.com and it is actually based on amazon’s Turk system. In fact, for 42 cents a minute, castingwords.com will transcribe almost any podcast (in English) within 24 hours with the help of amazon’s “tested” transcription Turks.

And why would prodcast transcripts be useful? I think that they would mainly help increase the overall “granularity” of the “podcastsphere”. This, in turn, would drive much better finding, remixing and sharing capabilities.

Most of the time right now, search results lead to full podcast files with variable durations ranging from some minutes up to over an hour. These searches normally operate on podcast names or short descriptions. As a consequence, a search for interviews with a specific politician (for example) would result in many hours of listening because there is no good mechanism to locate specific content inside a podcast itself.

With good podcasts, “chapters” are very handy here but if you’re like me, your favorite podcast has no chapters. In my case, it’s a 2.5 hours French speaking CBC daily podcast called “Indicatif Présent“. Can you imagine? 12.5 listening hours per week. Do I have time to listen to all this? No. Would I like to be able to locate stuff more precisely here? Absolutely. Why? Because I NEED to be able to skip what’s not interesting to me.

Along with podcast tagging and content “markers”, transcripts would also support very important functions like remixing and sharing.

To me, remixing is the capability that I need to aggregate my personal podcast stream based on podcast segments that I get from different sources. Remixing here is the ability to collate 10 minutes from one show here with 2 minutes from another one there with 15 minutes of music with…, and so on. Again, I can’t do that easily with my favorite CBC show right now. Podcast users, and probably most of us in the future, will want that flexibility. There is too much good content out there.

Finally, transcripts alone may not be the solution but we need mechanisms to annotate (or tag) media content like we do for photos (Flickr.com) or bookmarks (del.icio.us.com). Good annotation allows for better retrieving as well as sharing possibilities. Very often, I find myself having to write down podcasts timing information in order to retrieve specific segments or share them with friends. That’s not convenient at all.

Coming back to our mechanical Turk and my favorite CBC podcast. With castingwords.com, the whole transcript of a single show would amount to roughly 75$ (46cents/min. x 150 min.). So is there a reason why CBC can’t do it right away (they could do it themselves if they wished). What is 75$ in a 2.5 hours public radio show budget?

Observations of my own behavior make me think that it all comes down to this: either they do it or they won’t get my attention!

Technorati Tags : mechanical+turk, podcast+transcripts, cbc, podcasting, podcast+chapters, podcast+segments

If you have concepts that push the boundaries for Interactive mobile content and formats, creative solutions for user-generated content, ideas that will help web users navigate the ‘long tail’ of a broadcaster’s rich archives, innovative content or applications for DMB Mobile TV, then you should enter Content 360 – Digital Pitching Competition at MIPTV featuring MILIA 2006.

Tony Ageh, BBC Controller, Internet says: “We really want to understand the benefits that iMP can bring to our audiences.

We know that there is likely to be a ‘honeymoon’ period of a few weeks, when our participants are likely to use iMP more often than normal. The data from the extra two months should really help us to comprehend what users want from the service and how they are using it.

“This will be invaluable for us in making our case to the BBC Board of Governors for a full roll out of iMP.”

Link

The inherent content and binary encoding structure makes it inappropriate for the mobile. Instead of compromising on the technology performances, MPEG reached the conclusion that an optimum between feature richness/compression efficiency and device constraints needed to be found and decided to create a new standard for Rich Media for constrained devices.

…Because it’s not streaming that’s most affected by a combination of on demand and ‘deliver it to me’ subscribable podcast-like functionality. The main potential victim here is broadcast itself. Those of us who have Tivos or PVR functionality are already used to the idea that we don’t have to sit in front of the television when something’s being broadcast to watch our shows. And as a consequence, I very infrequently do.