One vision is to kill the internet. Another vision is to kill the incumbent media business. Another is to reinvent the media industry around tax revenues. SOPA, Pirate Bay, deus ex machina.

Here is my vision: allow private law to flourish. Enforce contracts. Introduce the rule of law.

There are just two problems, and both can be handled as incremental improvements.

One is fraudulent takedown requests. There are no meaningful barriers to requesting that something not infringing be taken down. This allows incumbents to do a denial of service attack on anybody who actually wants their music to be up. I don't think these are usually deliberately fraudulent, I think that they are accidents.

Easy fix: penalties that are big enough to cause rights holders to care.

The other problem is scaling up the takedown request machinery. For the moment the process is manual and rights holders can't go fast enough to make a dent. They need to be able to spider newly posted content, to accurately diagnose whether it is infringing, and to generate a takedown request, all at internet scale and speed. This is technologically possible, I believe. (But I won't document a system to do that here, because it would be tedious and not very interesting).

Ian Roger's proposal

I appreciate Ian's proposal for a global scale rights registry, but I think it is far harder than just making adjustments to DMCA notice and takedown. Ian's strategy requires rights holders to make their catalogs available to all comers at well known prices. This sacrifices negotiating power, so they will have to be dragged to the system kicking and screaming. Notice and takedown, on the other hand, is something they're willing to do as long as it actually works.

What's somewhat amazing about a system based on notice and takedown is that it administers itself in a completely decentralized way. Each rights holder would have its own registry of permitted URLs. Sony Music would have sony.com in this exception list, for example. Any domain not in the exception list would get a takedown request. The exception list can be highly detailed; for example it can remember which tracks a site is permitted to host and which tracks it may not host. This is mature technology.

The system I propose here can be implemented without any leaps of imagination. The details would be pretty easy, or at least practical.

This made me think about a music-only application of hyper audio and captioning - synchronizing music notation with a recorded performance. How would it be a different thing than synchronizing lyrics with music, or a transcription with a movie?

Notation sometimes contains a complete map of the performance. Everything is written up in some way, including the intro, solos, and all the little bits. This style of notation gets out of sync with a performance easily. It would fit with performances read from that score or with scores transcribed from a performance. Automatically matching the written part to the recording would still be tricky, because of how the tempo affects them both.

Notation is often deliberately incomplete. It describes certain highlights: here's the main melody, here's the order of the parts, here's the guitar solo. This kind of notation would be fragments inserted at multiple different points.

But then there's the issue that notation is not an internet standard. As far as the Internet as a whole is concerned, relatively open approaches like MusicXML and the Lilypond format are just as opaque as a bitmap of a scan of a handwritten score.

And to the point of WebVTT, the stuff it's synchronizing with the media is text. It's not for random binary objects as far as I know.

Whatever the obstacles, it's plainly useful to synch written music with recorded performances. You might be annotating the performance to make a point to musicians. You might be illustrating the notation to make it easier to sight read. You might be enabling web search for recordings of a melody.

This idea seemed fairly bland when I sat down to write this. Not so much at this point.

When I go out looking for birds, I can cope with many overlapping sounds at once, some near, some far, and they provide clues and cues as opposed to content.  I imagine something not unlike Brian Eno’s ambient music (cf. Music for Airports), where sound is meant to be something you don’t concentrate on, but part of the experience of the space.

I’ve wondered if there is a place for sound on the web that is different from music or sound effects.  As Laurian discusses, a way to get more information about the content of a page before you encounter it, much as you gain information about a field or woods by the sounds you hear (and those you don’t).

via Xbox 360 Dashboard update review (fall 2011) -- Engadget.

For connected TVs the biggest technology obstacle is input devices. Being able to use gestures + voice control without even having to pick up a physical is a huge win.

However, the hardware may be too expensive. Putting an accelerometer in an otherwise simple remote may be the sweet spot for cost/benefit tradeoffs. This is the strategy for Wii, LG's Magic Motion remote, and the new Roku.

He's wrong that it makes zero engineering sense.

Apps written on the browser stack - HTML, CSS, Javascript - iterate faster than client-side apps. They start as weak approximations but end up as far better. They start behind but run faster.

For example, browser-based mail apps like Hotmail were originally much worse than client side ones like Eudora. But huge advances have been made in these apps, and now client side mail readers like Outlook are clearly lagging edge in comparison to ajax apps like Gmail. It's not just ancient rotting hulks like Outlook; even relatively recent client-side mailers like Mail.app aren't as good as the best web mail apps.

Any application that can be written on the web stack will eventually surpass the same application on the client-side stack.

Why do web apps interate faster? My intuition is that it's about the size of the community of developers attacking technical obstacles. On the web you aren't the only engineer blocked by Problem X. There are huge numbers of other engineers stuck there. All these engineers swarm the problems and knock them down. The near-instant speed of deployment of new code (especially in a shop using continuous integration) takes over and allows each incremental solution to go live. Then the transparency of web coding enables the innovation to spread: engineers discover one another's solutions, read the source (which is always available), and copy the innovation. And this applies to virtually every aspect of the web stack, so that all of these innovations accumulate to the benefit of all web apps.

It is sometimes more technically difficult to write applications that rely on internet standards rather than client-side conventions. That creates the impression that the client-side approach is better engineering. But the client-side approach can rarely accomplish as much.

The gray list is works which are not policed. Some are in the public domain or under a permissive license like one from Creative Commons. Some are in copyright but not being actively exploited, including orphan works whose owners can't be reached, as well as barely-exploitable works whose owners can't be bothered.

Anybody can find out which is which: post a given recording in a visible location and see whether you get a takedown request.

The conversational context is that he's explaining why the Rdio in-browser player uses a a headless Flash module to stream audio rather than the Audio element.

We have no plans to support streaming via <audio> tags. There are a few show-stopper issues with the specification and the implementations that make it inappropriate for our use.

First of all there is no audio codec supported across popular browsers: http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5_Media)#Audio_format_support As you can see Firefox only supports Ogg Vorbis and while Chrome supports that Safari and IE do not.

Current implementations are immature and generally of poor quality. For example while iOS browsers have an <audio> tag it seems that they apparently don't actually work very well: http://www.phoboslab.org/log/2011/03/the-state-of-html5-audio Most other browsers have have their own warts and bugs too. I'm sure this will all look a lot better in a few years, but for the time being the platform isn't ready. And for all of Flash's bugs and flaws they do handle music streaming pretty well.

The <audio> API doesn't support streaming which *significantly* increases bandwidth usage. Flash's RTMP protocol allows devices to only download what they're actually playing. If you skip 20 seconds into a song then Flash will have only downloaded about 30 seconds worth of audio. Using HTTP progressive download playback (the only protocol that <audio> supports) then you'd have downloaded as much of the track as could be streamed across your network connection. Seeking with RTMP also significantly more efficient and quick than with plain old HTTP.

Finally Rdio's business and the businesses of our content partners depends on being able to securely deliver content to subscribers. When I listen to a song by a friend's band (eg: http://rd.io/x/Q1I2VLLD) I know that my friend is getting paid. While we all know that no security mechanisms are perfect the ones available in Flash are significantly more sophisticated, robust and well tested than what we could build on top of HTML5 <audio>.

Media type:
application/json; schema=dublin_core

Null data URI with this type:
data:application/json;schema=dublin_core,%7B%7D

Link response header with null data URI:
Link: data:application/json;schema=dublin_core,%7B%7D; rel="meta"

Link response header with artist and song title:
data:application/json; schema=dublin_core,{Creator%3A"Michael%20Jackson"%2CTitle%3D"Billie%20Jean"}

Using a data URI instead an HTTP URI is more robust, simpler and faster. I had to invent the media type, though. application/json; schema=dublin_core is a neologism.

Also, having two semicolons in there (you need one for the media type parameter to the data URI and one for the rel attribute) might be a bug.

See also the Web Audio API and jsmad.