Microsoft PM confirms Zune works as advertised only part of the time

One of the big selling points of Microsoft’s rebranded Toshiba Gigabeat, called “Zune” by the Microsoft marketing wunderkinds, is its ability to create “community” by allowing Zune users to share their music wirelessly between each other.

Not so fast, Tex. There’s bumps in that there road to digital nirvana.

Microsoft Zune project manager Matt Jubelirer confirms in the video below that not all the music you buy from the Zune Marketplace can be shared. Hmmm. That begs the almost instantaneous question ‘well, what songs can’t be shared’. Jubelirer dances around the question: “We’re not getting specific on any of those.” Okay this needs to be clarified a bit, says I. Luckily, the interviewer agrees. So, when you purchase a song from the Zune store, will it tell you whether the song can be shared or not? “No, it won’t”, admits Jubelirer.

So, let’s get this straight. A capability touted as one of the main strengths of the device only works part of the time, and Microsoft isn’t going to tell you “what” part of the time that is? That’s nuts, yet strangely, mirrors the Microsoft Windows experience.

Jubelirer goes on to explain that most of the content, particularly that from your own library, will be sharable (the shared copy can be played three times by the recipient, and cannot be reshared by the sharee [sharee?]).

So, what labels will allow their songs to be shared? “We don’t talk about the specifics of our business deals.”

He then goes on to reveal, perhaps, a portion of the pitch Microsoft has made to the labels in order to get them on board: “You can share most of those files and really promote those bands.”

Promote those bands?

Seriously, tell me record execs don’t really believe they’re going to get viral traction from the Zune Army for their bands using a model that is limited by 1) geographic distance (in order to share, Zune users must be within a very short range); and 2) the inability to reshare the shared track. Why not simply adopt a modified model of distributed sharing that provides for limited-count playback? The notion of viral marketing is the viral part, folks. Quarantining the outbreak after one generation is exactly how you prevent its uncontrolled spread. Psst. Hey man. Here’s a cool song. Don’t pass it on.

Better plan: Allow users to share their songs, and limit non-purchasers to three plays. But every time the song is shared, provide the sharee more plays. That’s how you build buzz. Reward the Army, expose the masses.

“It’s in community [the ability to share music and pictures with other Zune users]. I want to squirt you a picture of my kids. You want to squirt me back a video of your vacation. That’s a software experience.” — Microsoft CEO Steve Balmer

But, like all Microsoft products (due, IMHO, to their intrinsically Borg-like not-invented-here ethos), the actual product is not what’s promoted. In other words, you’re only going to be able to “squirt” your content when labels and their Microsoft lackey say it’s okay to squirt.

Quick and Easy Workflow for Photo Resizing

Here’s a quick way to resize a large number of photos using a built-in feature of Mac OS X, that also generates a web page while it’s at it for an easy photo album.

In Finder, click the “Go” menu, and select ” (shift-command-G), then copy in this path: /System/Library/Image Capture/Automatic Tasks/. Alternatively, you could open your hard drive and navigate to it.

Build Slide Show iconOnce there, you will notice ten automated tasks. The one we’re interested in is “Build Slide Show”. Double click on it to launch it. Notice that it’s icon is now in the Dock.

We’re going to use photos stored in our iPhoto library. Alternatively, you could use photos stored anywhere. Open iPhoto, select the photos you wish to process, and drag them to the “Build Web Page” icon in the dock. Presto. The script processes the images, and builds a web page for you, opening it in Safari (or your default browser).

You can derive the location of your resized photos and the HTML by looking at the URL, beginning with the word “Photos”.

Incorporating iSight into Design

This is a technique whereby a QuickTime movie, stored on and delivered by my web server uses your Mac’s iSight camera and microphone to create a movie with a reflective interface containing the local video stream and a logo that is resized by the user’s voice (all in real time). This demonstration makes use of Apple’s Quartz technology.

First, you should note that if you don’t have a Mac, you won’t see anything in this article. Now, if you’re using a Mac without an iSight camera, or if your iSight camera is in use by another application or browser window), this will not work properly.

The image being reflected in the background is me (erm, well, you), taken directly off my (your) iSight camera.

When you say “Wow, that’s cool” or “Man, that’s dumb”, or whatever expletive you utter, notice the Zavoodi logo grows and spins. This movie is also using you microphone, calculating peak voltage (the electrical equivalent of amplitude), and resizing and rotating the logo based upon that.

Notice that the time and date is being updated using your local computer clock. This capability is contained in the .MOV file, and is not a Javascript layer hack.

Pretty groovy stuff, in 512×384 resolution, for 114.2 Kb!

See what all the fuss is about

Please note: This idea was first documented on bbum’s blog-o-mat and revived recently here.

USB 2.0 Demystified

All to often I hear people tossing about performance specs they’ve read off peripheral packaging, as if it were gospel. In particular, in my professional role dealing with media creation, I continually run into people claiming USB 2.0 is “faster” because the marketing-speak from Intel claims theoretical throughput greater than that of Firewire. Well, tune in and I’ll demonstrate why that just isn’t true and why Firewire is the choice of professional video editors.

Contrary to widely held beliefs, propped up by the theoretical numbers marketers like to bandy about, USB 2.0 is far inferior in terms of the kind of performance required for external disk storage, not just for digital video use, but for general use as well.

While marketers like to tout USB 2.0 throughput as 480 Mbps versus FireWire’s 400 Mbps, what they don’t discuss is the built-in inefficiency of the USB 2.0 architecture, which substantially reduces actual sustained throughput (the kind you want for disk storage and video editing).

Technically speaking, Firewire uses an architecture in which the peripherals negotiate bus conflicts to determine which device can best control data transfer. This peer-to-peer arrangement works well because the devices are independently intelligent. USB 2.0, on the other hand, uses a master-slave architecture, wherein the host computer handles all arbitration functions and dictates data flow between the attached peripherals (adding additional system overhead and resulting in slower data flow control). It is this flow-control that is a critical determinant in the actual performance of the device.

A great example, presented by PC Magazine, reveals USB 2.0 is not 40 times faster than USB 1.1 (as promised by comparing the “rated” throughput), but merely 2 to 13 times as fast1. Not only is that a wide discrepancy in the rated throughput, but also in actual performance. This is due, fundamentally, to the flow-control architecture.

Want real world numbers? Here they are (courtesy of qimaging.com):

Chart comparing throughput in various scenarios of firewire versus USB 2.0

Read and write tests to the same IDE hard drive connected using FireWire and then Hi-Speed USB 2.0 show:

Read Test:
5000 files (300 MB total) FireWire was 33% faster than USB 2.0
160 files (650MB total) FireWire was 70% faster than USB 2.0

Write Test:
5000 files (300 MB total) FireWire was 16% faster than USB 2.0
160 files (650MB total) FireWire was 48% faster than USB 2.0

As you can see, the performance gap substantially widens as you move from large numbers of small files to small numbers of large files. Because video editing generally consists of utilizing large files, you can see why Firewire 400 is the substantially better interface. Then, consider Firewire 800 and you should be sold on the choice of Firewire for video editing.