I've become aware of quite a bit more metadata support in the world of web browsers; please consider my old proposal withdrawn.
=== Reporting > Only "artist" and "title" are required for royalties reporting for > internet radio. I'm sorry for a bit of topic drift on this list, and I'm sure requirements vary by nation. I do reporting for a local station and among the requirements I have to meet: https://www.soundexchange.com/service-provider/reporting-requirements/ This is the last thing I'll say on this tangent. === Dynamic versus static metadata Pretty much all audio formats have at least one metadata format. While some apparently can embed them at time points, this is not used by any players I can find. The Icecast/Streamcast "metastream" format is the only technique I've ever encountered. The industry is quickly shifting to the so-called "Shoutcast v2" format due to: https://forums.developer.apple.com/thread/66586 Metadata formats as applied to static information are, of course, of great interest. Any dynamic technique should fit into the existing approach. You have to draw a distinction between API's concerned with UI/UX presentation, and those concerned with getting the underlying information. MediaMetadata is an example of the former, mozGetMetadata the latter. I'm now looking at mozGetMetadata as a starting point, with a minimal change to add dynamic metadata events. Of course, mozGetMetadata makes a very nice counterpart to Chrome's MediaMetadata API for rendering the information to the listener. === Processing a stream programatically > If the same-origin policy stops you, it should also stop a C++ > implementation. It's there for a reason. This is all framed by techniques exemplified by <audio src="..."> which enjoy permissive origin treatment. The goal is to glean the information which is *available anyway*. Without changing the protection regime. === Non-trivial audio application > Also royalty reporting is done in a earlier stage, what a listener sees > is not what is logged/given for royalties reporting. In addition to the obvious benefits of gleaning metadata and updating the UI, I'm also interested in non-trivial audio applications like: https://en.wikipedia.org/wiki/Broadcast_automation both static and dynamic metadata sources are very much of interest. The browser execution environment is an excellent platform for these sorts of applications. === Proposed new API direction Here's the approach which now makes the most sense to me. Ultimately, I'd hope that the moz-prefixed mozGetMetadata could indeed be standardised (to getMetadata). Keep the same semantics, possibly formalize some basic fields (artist, title, album, year, ...). If one of those receives a value from the underlying media, it'll have that value. It's legal to omit fields which have no value. Then, metadatachange is added. While an event handler is active, then on each detected change of metadata a callback occurs. For the special case of Icecast/Shoutcast where the initial HTTP GET requires a special header, the change handler must be in place before the stream is opened. Thus "<audio id="player" onmetadatachange="changes()>" will fire changes() after player.src is set. The initial call would be at the same point that the existing loadedmetadata event would fire, and then subsequent calls at each metadata update from the stream. Thanks again for your comments, Andy Valencia