W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2017

Re: [whatwg] <audio> metadata

From: Roger Hågensen <rh_whatwg@skuldwyrm.no>
Date: Sat, 15 Apr 2017 13:46:28 +0200
To: whatwg@lists.whatwg.org
Message-ID: <2e984d4a-6654-501e-63d9-637460eebb0d@skuldwyrm.no>
On 2017-04-14 22:23, Andy Valencia wrote:
> Ok.  Note that this data structure suffices to encode the baseline
> information from Shoutcast/Icecast.  It does not, for instance,
> encode "Label", needed to do licensing reporting in the USA.
> "Year" is another datum often of interest.

Only "artist" and "title" are required for royalties reporting for 
internet radio.
But "album" and "year" provides additional information that helps.
Commercial radio and TV uses at minimum the artist and title, and if 
lucky the listener (digital radio) and viewer get to also see album and 
year.
Also royalty reporting is done in a earlier stage, what a listener sees 
is not what is logged/given for royalties reporting.


Ogg (Vorbis or Opus) should in theory be easily supported as metadata is 
given in a sidestream right? So is therefore independent of the audio 
stream.

Mozilla has audio.mozGetMetadata()
https://developer.mozilla.org/en/docs/Web/API/HTMLMediaElement

I have no idea if that fires once or each time more metadata is passed 
in the stream.

https://developer.mozilla.org/en-US/docs/Web/Events/loadedmetadata
Only says that it is fired when the metadata is loaded.
I'm assuming it's only at stream start though.

So with a few "tweaks" Firefox could support Icecast Ogg metadata, if 
the browser is compliant with the Ogg standard then support is very easy 
to add.

Shoutcast v1 would require parsing of the audio stream, Shoutcast v2 is 
a little different and can pass info like album and year and artwork.
The only Shoutcast v2 compatible player I'm aware of is the aging 
Winamp, the majority of Shoutcast streams are v1 streams.

So while Firefox almost is able to provide stream meta updates, all the 
other browsers do not though and would require polyfill which as you 
point out has it's own issues with having to reset the stream as the 
buffer fills up.

Maybe support for enabling a large cyclic buffer could be used, 
triggered by a "stream" parameter for html audio maybe.
There would still be a issue with metadata possibly being partly in the 
current buffer and partly in the next buffer so any javascript would 
need to splice that together.


Ogg seems simple enough
https://www.xiph.org/ogg/doc/oggstream.html
And parsing of this metadata should be in the ogg source (libogg?) so 
any browser that supports Ogg should be able to get that metadata.


-- 
Roger Hågensen,
Freelancer, Norway.
Received on Saturday, 15 April 2017 11:47:04 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 15 April 2017 11:47:04 UTC