Link: header for audio metadata

  1. • lucasgonze clears throat
  2. [6:21pm] lucasgonze: I have this thought –
  3. [6:22pm] lucasgonze: apply http://www.w3.org/wiki/LinkHeader to audio files on the web, as a method to annotate pcm data.
  4. [6:22pm] lucasgonze: as an alternative to id3
  5. [6:22pm] lucasgonze: so let’s say there is http://example.com/example.wav
  6. [6:22pm] lucasgonze: wav has no metadata support
  7. [6:23pm] lucasgonze: GET on http://example.com/example.wav would return a response header pointing to a metadata file
  8. [6:23pm] lucasgonze: Link: example-metadata.json; rel=meta
  9. [6:25pm] lucasgonze: GET http://example.com/stairwaytoheaven.wav
  10. [6:25pm] lucasgonze: Link: http://musicbrainz.org/ws/2/recording/ccfdd180-22e1-49b9-bd81-b5fcf2c6474e?inc=artist-credits%2Breleases; rel=meta
  11. [6:35pm] lucasgonze: use CORS on the metadata resource http://www.w3.org/TR/cors/ to enable cross site requests from ajax
  12. [6:36pm] lucasgonze: then a javascript-based audio renderer in the browser can access metadata for any file
  13. [6:37pm] lucasgonze: the metadata technology is factored out of the codec.
  14. [6:37pm] lucasgonze: the http request becomes the envelope for waveform data and metadata together.
  15. [6:37pm] lucasgonze: metadata technology and audio signal processing technology can evolve independently

See also the Web Audio API and jsmad.

2 thoughts on “Link: header for audio metadata

  1. Seems very cool. The one advantage of meta in file is that it travels everywhere with the file, including offline. In the above scenario, seems easy for the file to travel places where the client has no idea how to check for the meta header.

    Maybe a backup could be to also install meta link inside id3 as a fallback?

  2. I’d think of it as a caching thing.

    You have an audio resource at some URL. It’s just PCM bytes, no metadata. A wav file would match this description. But I’m thinking about next-generation audio formats that have real compression, are accessible to CORS, and can be fed into web audio APIs.

    For the most part the file would be kept with its URL. The bytes returned by the URL and the URL itself wouldn’t be decoupled, so that one could travel without the other. Given that the client has the URL and the URL is enough to get a metadata file, the metadata and audio do travel together.

    So let’s say there’s some client choosing the save the audio for offline use. At that point it’s going to do a lot of reformatting. Probably it will convert the bytes to a plain old MP3. At that point it can use the WOAF field for the URL of the metadata, if it wants to, or maybe just copy the metadata itself into the ID3 fields and throw out the metadata file. It’s like when your browser saves a page to disk and modifies it to include copies of the CSS, Javascript and images.

    I don’t see offline use as important. That whole way of approaching music is going away fast. The web audio API is the new standard. Developers writing Javascript to feed into that API will pick up the audio file in whatever format pleases them. No need to be reading from a standard format like MP3.

    The concept for metadata in this post is a sibling to the web audio API. It’s a web metadata API.

Leave a Reply

Your email address will not be published.