Category: .

I doubt alarm monitoring services are kept up. I think most of those signs you see out front of houses – “Protected by [BRAND X] security system” – are about systems that have fallen into disrepair.

That’s a guess, but I’m pretty confident about it.

You need to keep changing the batteries in every single component. Every entry way with a sensor and every room with a motion detector now has a battery. A house can easily have 20 new batteries to change. Each of these components is manufactured cheaply and most will need to be replaced or upgraded at some point.

The codes need to be kept secret, or they need to be changed from time to time. The safe word needs to be taught to everybody and then remembered. The kids have to be kept from hitting the panic button or arming the system using the one-click button on your keychain. And of course you need to keep paying the alarm monitoring service, for life.

What’s the alternative? Security measures that are permanent. One-shot investments.

Good quality locks. Fix the strike plate to make it hard to kick the door in. Get rid of glass windows within arms reach of a doorknob.

Once you make a fix like that, it keeps on repelling thieves indefinitely.

Usecases for WebRTC:

4.2.  Browser-to-browser use-cases . . . . . . . . . . . . . . .  4
  4.2.1.  Simple Video Communication Service . . . . . . . . . .  4
  4.2.2.  Simple Video Communication Service, NAT/FW that
          blocks UDP . . . . . . . . . . . . . . . . . . . . . .  5
  4.2.3.  Simple Video Communication Service, global service
          provider . . . . . . . . . . . . . . . . . . . . . . .  5
  4.2.4.  Simple Video Communication Service, enterprise
          aspects  . . . . . . . . . . . . . . . . . . . . . . .  5
  4.2.5.  Simple Video Communication Service, access change  . .  6
  4.2.6.  Simple Video Communication Service, QoS  . . . . . . .  7
  4.2.7.  Simple Video Communication Service with sharing  . . .  7
  4.2.8.  Simple video communication service with
          inter-operator calling . . . . . . . . . . . . . . . .  8
  4.2.9.  Hockey Game Viewer . . . . . . . . . . . . . . . . . .  8
  4.2.10. Multiparty video communication . . . . . . . . . . . .  9
  4.2.11. Multiparty on-line game with voice communication . . . 10
  4.2.12. Distributed Music Band . . . . . . . . . . . . . . . . 11
4.3.  Browser - GW/Server use cases  . . . . . . . . . . . . . . 11
  4.3.1.  Telephony terminal . . . . . . . . . . . . . . . . . . 11
  4.3.2.  Fedex Call . . . . . . . . . . . . . . . . . . . . . . 12
  4.3.3.  Video conferencing system with central server  . . . . 12

Digging deeper on one of those:

4.2.12.  Distributed Music Band

4.2.12.1.  Description

   In this use-case, a music band is playing music while the members are
   at different physical locations.  No central server is used, instead
   all streams are set up in a mesh fashion.

   Discussion: This use-case was briefly discussed at the Quebec webrtc
   meeting and it got support.  So far the only concrete requirement
   (A17) derived is that the application must be able to ask the browser
   to treat the audio signal as audio (in contrast to speech).  However,
   the use case should be further analysed to determine other
   requirements (could be e.g. on delay mic->speaker, level control of
   audio signals, etc.).

p.s. That’s right, I used the <pre> and <big> tags TOGETHER. MWAHAHAHAHAHA.

When it comes to infringement control, there aren’t many competing visions.

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.

DMCA notice and takedown is basically an excellent system for administering a global-scale internet music infrastructure.

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.

There’s video captioning with WebVTT, and there’s a closely related vision of hyperaudio.

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.

On the web as soundscape (David Humphrey):

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).

Kinect motion control permeates the entire Dashboard experience. … Voice control goes almost as deep as gesture control, and is infinitely easier to use. This too, was once available in the Kinect Hub, but the contemporary implementation is heavily refined.

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.

Jeff Atwood said any application that can be written in JavaScript, will eventually be written in JavaScript. Writing Photoshop, Word, or Excel in JavaScript makes zero engineering sense, but it’s inevitable. It will happen. In fact, it’s already happening. Just look around you. As a software developer, I am happiest writing software that gets used.

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.

If the owner of a copyright doesn’t care to commercially exploit their work, they won’t cover the ongoing expenses to police infringements by submitting takedown requests. There is basically a blacklist of works whose copyrights are valuable enough to cover the bill for submitting takedown requests. This blacklist is self maintaining – there doesn’t need to be a central registry.

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 HTML5 audio element has unfinished business. This posting by Ian McKellar of Rdio to the Rdio-API mailing list articulates the problems well.

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>.