Booting porn from the app store seems self defeating for Apple. Porn isn’t going away. Moving it out of the app store will create a thriving market that Apple doesn’t control. It will be web apps, not native apps, and third parties will dominate the payment infrastructure.
MP3 files can contain text, of course, and I’ve occasionally found lyrics stored inside TEXT and USLT frames. But there’s no consistency at all, probably never will be – more likely to find spam inside a TEXT frame.
Your idea for linking to time points is a cool notion, Lucas. Related to this, Real’s servers provide for a “start” parameter on a/v URIs, allowing one to jump to a time point, e.g.
Some of the various SMIL specs provide begin and end params for the same purpose (http://is.gd/5I3jL). Aside from that and Real’s faded format, my hunch is that most a/v is not very content-addressable, partly due to the fact that a given song can be found in the wild with many encoding variations. If I make in/out time points for lyrics on my rip of a CD track, your rip might not sync with it. Also, radio vs. album versions of a song may vary in duration and content.
Event-based synchronization, i.e. the beat-counting idea Piers brings up, might be worth looking into-
<a href=”example.mp3#t=1017b,1683b” class=”chorus”>chorus</a>
This would need a filter to recognize beats and count them. Possible, just not as simple as time. Might be more consistent than seconds-based.
Perhaps there’s another type of common event found in audio streams that could provide consistency, but I like drum beats because they’re less likely to get corrupted or folded than high frequencies, and less common than human voice-range freqs.
The karaoke industry seems to have cracked this nut, but I’m gonna hazard a guess that it’s all proprietary.
These guys sell player sw that syncs lyrics for 1 million songs, they claim:
http://is.gd/5I48w. They appear to target music teachers in their marketing.
When you think about it, a technological component in a media player can auto-magically beat-sync two tracks by comparing basic structure and determining BPM. Word documents used to be the bane of the structured data movement, because they trapped content in a non-structured format, but ODF and OOXML have changed that game completely, creating a new class of semi-structured data; so why not music or video?
It’s fascinating to consider that if more artists released works under CC-NC by attribution, remix artists could provide additional value by micro-tagging individual samples within the deeper structure of their compositions – particularly if this functionality were baked into the software used to assemble the composition.
It seems to me that the magic is to find a way to refer to semantic elements of a song, both of which are abstract things that only loosely map to specific bytes in a specific file.
I’m happy to say that I’m working at MOG now.
The place has a scrappy startup style but is stable and well managed. They bring their hearts to the product. They’ve survived remarkably long in the brutal internet music business.
My title is product manager. I’ll keep what I’m working on confidential in the short term, but not for long.
I have to say a little bit about the subscription business. Just a little, but something.
I think subscriptions are a worthwhile thing to work on. The internet music industry is full of smoke and mirrors, and subscriptions are not that. Yes subscription companies often make lame software, but they don’t have to. Subscriptions to an on-demand stream service can be fun, useful, usable, awesome.
I don’t think everybody in the world is going to get a subscription, and I don’t think subscription companies need that big a market to be healthy businesses. I don’t think the fate of the music business rests on the shoulders of the subscription music companies.
All these companies have to do is please their customers and earn profits for their shareholders, and I think MOG has the chops to pull it off.
I’ll be moving to San Fran for the job. I’ll miss my friends in LA and lots of things about the city. I don’t like moving. But the bay area is the real homeland for web developers, even ones like me that specialize in music.
/via Dave Haynes
One of the functions of a well designed instrument is to help players understand where they are in the composition, in the rhythm, and in the harmony. I’m interested in this as a dynamically tweakable user interface, because that makes it possible for the interaction design to evolve.
The Streaming Content Payment use case for PaySwarm encompasses the same multi-vendor music provider environment as Playdar:
Tellulah is a DJ and would like to setup a non-profit Internet radio station to stream Weekly Top 40 songs along with a mix of independent music. She would like to cover her expenses as well as the standard per-song ephemeral broadcasting fee set by the US Copyright Arbitration Panel to ensure she is legally compliant at all times. Registering and tracking royalties can be a very daunting and time consuming process. A mechanism that reduces the burden of legal compliance could drive more stations to come online.
Online radio broadcasters are also presently limited in their ability to grow their stations due to the ephemeral broadcasting royalties that must be paid on a per person/per song basis. Running these stations make it difficult to collect, track and distribute royalties in a way that makes it easy to integrate into the web browser. Often, donating or signing up to a single download provider can be more trouble than it is worth. If there was a universal mechanism to pay very small amounts for data streams on the Web, new legal avenues for distributing content legally would be enabled.
Payment must be able to be associated with a section of a stream of data. Payment should be allowed to be associated with a particular number of bytes or temporal time frame.
Small fractions of whole currency amounts should be allowed in order to ensure accurate metering and payment recouping for content streams.
The “web” answer is more in the client / user agent than in the cloud.
Generally, payment mechanism on the web rely on someone being registered with a service, and then authenticated for each transaction.
That service handles a bunch of stuff that has to do with banking, and so is designed fundamentally as a node in the bank network rather than as a node on the WWW.
I don’t think that can be moved to the web in an open way. But, it’s possible to make that whole experience much more streamlined.
For example, someone who has a Google Checkout account can easily buy anything sold via Google Checkout. Same with PayPal and Amazon.
And, same with iTunes.
(And, on the other side: same with sellers, albeit with different restrictions about who can sell what / where through each service.)
And, that layer of web-to-banking service, theoretically, can be built on. And, I think it’d be most direct to work at the browser level, e.g. smart user agents.
In this case, an online seller would present, via a data format, a manifest of acceptable payment services, behind the scenes to the user experience. The buyer’s user agent (say, web browser) would then, behind the scenes and without hassle to the end-user, select the user’s preferred payment method and present the user with the minimal confirmation steps necessary to complete the transaction through that mechanism.
This could be akin to how Firefox handles subscription to RSS feeds, allowing the user to have a preset feed reader application that is invoked automatically when the user clicks a “subscribe to RSS” link.
However, in the case of online financial transactions, the user agent would want to allow for many services or protocols, and let the user define which is preferred for which types of transactions.
So, it’s “web” in the sense that it’s web browsers working directly banking APIs.
Flattr is a cloud service rather than a protocol.
PaySwarm is a protocol, not a cloud service.
The PaySwarm web platform is an open standard that enables web browsers and web devices to perform micropayments and copyright-aware, peer-to-peer digital media distribution.
Who can implement and use the technology?
One of the problems faced by music application developers is the issue of ID translation. You may have a collection of music that is in once ID space (Musicbrainz for instance) but you want to use a music service (such as the Echo Nest’s Artist Similarity API) that uses a completely different ID space. Before you can use the service you have to translate your Musicbrainz IDs into Echo Nest IDs, make the similarity call and then, since the artist similarity call returns Echo Nest IDs, you have to then map the IDs back into the Musicbrainz space. The mapping from one id space to another takes time (perhaps even requiring another API method call to ’search_artists’) and is a potential source of error — mapping artist names can be tricky – for example there are artists like Duran Duran Duran, Various Artists (the electronic musician), DJ Donna Summer, and Nirvana (the 60’s UK band) that will trip up even sophisticated name resolvers.
We hope to eliminate some of the trouble with mapping IDs with Project Rosetta Stone.
For now they only support two identifier types, Musicbrainz’ and their own Echonest IDs. But
keep an eye out for the addition of commercial ID spaces that will allow easy mapping being Echo Nest IDs and those associated with commercial music service providers.
If I were a commercial provider I’d be looking in getting my own IDs into this API.
I have payment protocols for the open web on the brain and ran across a protocol based on texting: Paypal’s Text To Give system.
Text the donation code to the number shown. We’ll call or text you back to confirm the donation.
Here’s another one, this time specialized for tickets: txt2buy.
To buy a ticket; txt the event name to 60300 and you will receive a txt confirming the details and cost of the ticket.
You must reply to this txt with your 3 digit security code (the last 3 digits on the back of your registered debit/credit card) to pay for the ticket(s).
We then send you an entrance code by txt and email. Show your txt at the door and jump the queue.
However, to return to the original question of whether HTML5 could (or should) include anything that creates a business model for app makers, I say no. HTML5 is (should be) a technology standard, not a way to directly make money. Who runs the HTML5 App Store? Who charges the user and passes on money to the developer? The W3C? Looking at it from another way, there’s no reason you can’t drop in PayPal, Amazon FPS, or something similar to your web app and charge for the app or special features (in-app purchases) today.
Of course, the point is that Apple has created a system where the technology is tied to the platform API which is tied to the discovering, sales, and delivery mechanisms. The general web doesn’t have this, both to its detriment and benefit.
Ok, so on to Pie Guy:
Pie Guy is available for totally free from http://mrgan.com/pieguy. Hit that on your iPhone, install once, and play forever. By the way, if there are updates to the game and you’re online when you launch it, the updates will be automatically installed. Web apps, dudes.
P.S. If you’d like to tip your developer, why not buy a shirt. Or, heck, buy anything else on my Amazon Store.
I’m trying it out right now, haven’t used it enough to come to a conclusion. Installation was certainly painless, and the app looks incredibly smooth for a non-native piece of code. But even though I somewhat buy the engineering model, the “buy a shirt” business model doesn’t strike me as credible.
The app store makes money for developers because of how good a job Apple did on making it easy to purchase apps. Apps are cheap and the shopping experience is excellent, so that buying an app is the same kind of quick satisfaction as picking up a candy bar at a newstand that you happen to be walking by. I don’t *mind* coughing up a few bucks for the developers of a cool app, actually I kind of enjoy it. Tipping by buying a shirt or exploring a random Amazon store is not in the same league.
Beyond the technical capacities of native vs. web apps, I think we underestimate the value of the ecosystem of small app business that Apple has created with the store.
Sometimes the web makes things free as in “liberated” but sometimes it makes things free as in “worthless”.
I don’t want to turn into a closed source anti-freedom reactionary, but there’s got to be some place in here for a business model for app makers.
What could we put in HTML5 that would support that?
How about an app-installation app? It would enable any developer to make their app available, handle payment, and install the app. There could be more than one of these. Or how about an in-app payment engine that enabled seamless transactions?
Are these feasible? Would they have an impact?
The world of Windows developers is full of small shops that make a decent living. They have to live in Microsoft’s shadow, and under the shadow of Microsoft’s falling foot sometimes, but even so these developers may well be happier and do better work than many of the no-$ projects on Sourceforge.