ZDNet’s Ed Bott has some very pointed words about what he says is Apple’s manipulation of the efforts to establish an open standard for electronic book media by first seemingly unconditionally supporting the EPUB format — and then, with their introduction of iBook 2.0, locking EPUB out of their platforms.
Apple has built its iBooks platform on the back of an open standard. With last week’s introduction of iBooks 2.0 and the free iBooks Author software for Mac OS X, Apple is deliberately locking out that popular open standard.
Apple’s behavior is a modern, sophisticated version of the “embrace, extend, and extinguish”behavior that got Microsoft in so much trouble in the 1990s: Enter a product category supporting a widely used standard, extend that standard with proprietary capabilities, and then use those differences to disadvantage competitors. (The strategy is even more effective if you have a dominant market position in another, related category that you can use for leverage. Think Windows in the 1990s, iPad in 2012.)
If you read, write, or publish digital books, you should be concerned.
Bott is not alone in his dark view. Well-known career Apple-watcher John Gruber has called the iBooks 2.0 EULA “Apple at its worst,” although he moderated his comments later. (We can only speculate on the motivation for his retrenchment. But it certainly wouldn’t do for a professional Apple-watcher to be shut out from that world.)
Bott points out that Apple’s support for EPUB — or ePub as they dubbed it — was, according to Apple’s own pronuncements, solid and unwavering.
In the original version of the FAQ published in April 2010, when iBooks was launched, Apple was even more definitive about the format: “iBooks only uses books published in the ePub format.” An Inside iTunes page written by Apple at the same time is still available online. It states in no undertain terms that ”the iBooks app uses ePub, the most popular open book format in the world.”
Apple is quite proud of this fact, even bragging in the current version of the iBooks FAQ about its support for “the industry-leading ePub digital book file type.”
Yet, now, Apple has changed the rules…
[F]or nearly two years, Apple has wooed digital book publishers and authors with its unconditional support of an open, industry-leading standard. (The EPUB standard is managed by the International Digital Publishing Forum [IDPF], of which Apple Inc. is a member.)
With last week’s changes, Apple is deliberately sabotaging this format. The new iBooks 2.0 format adds CSS extensions that are not documented as part of the W3C standard. It uses a closed, proprietary Apple XML namespace. The experts I’ve consulted think it deliberately breaks the open standard.
Read the whole article: How Apple is sabotaging an open standard for digital books
Related stories:
| Amazon: “Primed” to disrupt Apple’s textbook plans? |
| The poor get poorer and the rich get richer with Apple’s iPad-based textbooks |
Audio and video on the web: where we stand now
A working musician and recording studio owner wondered elsewhere how he could get the highest quality audio samples of his work onto his website. He wanted, if possible, to use a minimum of 24 bit/44.1 kHz audio files…
44.1 24 bit uncompressed audio has a bandwidth of ~2117 kbps (~2.1 Mbps). With a rockin’ server and a very good downstream, that might work much of the time with optimal ‘net circumstances depending on server traffic. But it’s probably not a practical solution.
That means using a perceptual encoding algorithm like mp3, AAC, WMA, or Vorbis. With greatly reduced bandwidth comes potential loss of perceived quality, but, happily, the upper levels of those formats are indistinguishable from the ‘real thing’ by most people, even among trained listeners.
The latter three formats are generally accepted as offering marginally higher quality at a given bitrate — but the problem is that near-universal support only exists for mp3. AAC probably comes closest, but many Windows users would have to install the AAC codec in order to not have the browser throw a WTF? error.
So far, then, the most practical advice is to use a high resolution mp3.
Now we come to the player.
We are, interestingly (as in the ancient Chinese curse form of interesting), in an era of transition.
For most of the www’s history, streaming media has been accomplished via browser plugins like Macromedia’s (now Adobe’s) Flash, MS’s Silverlight (which is the system under Netflix Streaming) — or, far less successfully and gracefully, the Quicktime plugin. Such plugins provided both a software mechanism for receiving the streamed media but, in the case of Flash, allowed developers to create sophisticated user interfaces with a number of advanced features. Unfortunately, those third party developed plugins did not always run with great efficiency (many Flash developers came from the visual design world and did not necessarily have an understanding of programming efficiency). And, of course, you don’t get all that potential sophistication for nothing… the sophisticated Flash system inevitably had some overhead built in.
But with the advent of increased demand for mobile web appliances wiht long battery life, as well as increased strategic rivalries between Apple and Adobe, Apple elected to ‘banish’ Flash from the iOS operating system that runs their Touch, iPhone, and iPad, saying that developers should use native HTML5 support for streaming audio and video.
Great.
Except for one thing. HTML5 was not then and is not now a standard. It will not be a finalized standard for the better part of a decade, as plans now exist.
Support for HTML5′s vague ‘standards’ is spotty and inconsistently implemented across browsers. Web developers are now faced with a situation that — sadly — parallels the troubled times of the late 90s when every browser implemented the (often vaguely stated) CSS standard in frequently fundamentally inconsistent ways.
The number of people who do have browsers that properly support HTML5 is around half to 2/3 (depending on whose statistics you buy). That leaves, what, around a billion people who don’t?
And that means that a prudent web developer will likely need to make sure his streaming audio and video media has both Flash and HTML5 support. Some systems use HTML5 if it’s available, but ‘fall back’ to Flash if it’s not. Others, weighing the sophistication and maturity of Flash players, go the other way around, using a full featured Flash player where that’s supported, but falling ‘forward’ to the much cruder, limited HTML5 native players in HTML5-ready browsers.
Here’s a report on the state of HTML5 video from Long Tail Video, the people who make the popular (but no longer strictly free) JW Player.
The State Of HTML5 Video