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

Re: [whatwg] <audio> metadata (and royalty reporting for some weird reason)

From: Roger Hågensen <rh_whatwg@skuldwyrm.no>
Date: Sun, 23 Apr 2017 20:55:10 +0200
To: whatwg@lists.whatwg.org
Message-ID: <eb025b9b-ee98-75f8-5a96-7e5b697cf69c@skuldwyrm.no>
On 2017-04-23 18:58, Andy Valencia wrote:
>> 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.

That has nothing to do with a web browser or related standards.

That type of reporting is done at the admin side of a streams server via 
listener/performance logs.
Icecast do these, and AFAIK so can Shoutcast v2. And in any case most 
streaming service providers use Centovacast which has it's own 
performance log.

A radio broadcaster can also choose (and it's probably better) to log 
locally in the radio software they use. There is a lot of radio software 
out there and even the more crappier ones let you do song logs.

Also note that it is possible to pay a extra yearly fee to avoid the 
reporting for smaller stations.

Also note that services like StreamLicensing.com do all the reporting 
for you it is fully automated and do Total Listener Hour calculations 
for you. And they do fetch stats directly from a Shoutcast v1 or v2 or 
KH-Icecast server, although not in an ideal way. They are for US based 
radio station only though and only handle the royalty reporting/paying, 
the rest you have to handle yourself. For Canada SoniXCast.com might be 
a good all in one solution (royalties/streaming/website hosting).

Also you say a local station. IF you are local (is it DAB/DAB+/DRM or 
something else? Is it simulcast FM and Internet? Over-The-Air stations 
that also broadcast via the internet has to follow different rules than 
internet only stations. And there is no "local" station on the internet, 
anyone anywhere in the world can tune in. Unless it's gated behind a 
paywall or similar.


> 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

Chrome had that issue (forgot which version maybe Chrome v55) but added 
some workaround code so old Invalid Shoutcast v1 HTTP responses will 
work in both Chrome and Firefox (which has a different workaround), also 
most streaming providers has a port 80 proxy option available which will 
make the stream work with Chrome 55.

And never heard of StreamCast, all I see is a (dead?) project on 
sourceforge.
If you are talking about the Shoutcast metadata then that is Shoutcast 
v1 only (and slightly changed for Shoutcast v2 streams but you need a 
Shoutcast v2 stream source software that support this, most still sue 
the v1 method even with v2 servers).
Icecast uses Ogg streams with (I forget the term) virtual sidestreams 
with metadata, that can be sent at any point (at track change for 
example). The stream source must support this obviously.

> The goal is to glean
> the information which is *available anyway*.  Without changing the
> protection regime.

"*available anyway** is only song artist and song title, I know this for 
a fact as I'm the tech guy in one of the oldest internet radio stations. 
Do you know how I know this? Because that is the only info that is sent 
from the DJs to the stream server over Shoutcast v1.

A DJ connecting to a Shoutcast v2 server using Shoutcast v2 mode can 
send album and year data etc. But there are almost no Shoutcast v2 
players out there (the biggest and most popular one I'm aware of is 
Winamp) pretty much all other players with shoutcast support only 
support v1 metadata. And ther are even more players out there that do 
not support shoutcast metadata at all. To them the metadata looks like 
invalid MP3 or AAC(+) data and is skipped/ignored. That metadata is a 
hack. Icecast does it as part of the Ogg standard and "should" work on 
all Ogg compatible players.

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

There exists professional radio broadcast software for this which can 
cost thousands. And they need to be rock solid 24/7/365. No browser is 
designed to run that long. Not sure they even test that long runtimes as 
usually every few months there is a browser update anyway.

> === Proposed new API direction
> 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.

There is no legal requirement for any player to show certain fields. 
There are physical internet radio boxes (like Roku if I recall 
correctly) that do not even show Shoutcast metadata. If this was a legal 
issue then every single player/radiobox out there as well as all streams 
in the world would be forced to adhere to it.

Remember, soundexchange is not looking at the info the player is 
displaying. They just want logs and money. (they don't really care much 
about the logs or getting the money to the artists, as a unsigned artist 
they have pocketed my money on my behalf without my permission even when 
my music is under a Creative Commons license, but that is another 
discussion best served elsewhere than here.)

getMetadata however would be nice if adopted by all browsers as it would 
allow a webplayer to show info a listener might find interesting without 
having to use XHR (or in the future Fetch) to poll a weburl script that 
grabs the info as XML or JSON from the streaming server (which is how I 
do it for our radio station and our web player currently, the royalty 
reporting is currently via streamlicensing which has admin access to the 
stream server to get song info and listener info.)

> Then, metadatachange is added.  While an event handler is active,
> then on each detected change of metadata a callback occurs.

Maybe somebody else at Mozilla could test that, but I'm hoping that the 
info is updated when it's changed so a simple polling of getMetadata can 
make it work right now. But this assumes that the MP3 decoder supports 
shoutcast metadata (which is most likely don't, and probably not v2), 
the Ogg Vorbis decoder (and hopefully the Ogg Opus decoder) should 
support the metadata but if it actually presents that to getMetadata I 
have no idea.

If that is the case then the polling could be used temporarily until a 
event is added for such a metadata change.

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

Icecast does not require a special header, the Icecast stream is HTTP 
standard compliant, it is no different from a static vorbis file with 
the proper MIME type (but without a file length obviously as it's a live 
stream).

I do not see why a different event would be needed, just make the 
loadedmetadata event fire for both. With a stream the metadata may be at 
the start or several KB into a stream.


Also note that you should not wish for too much metadata in such streams 
as they bloat the stream and do count towards the bitrate of the stream 
so that it is for example 96kbit of audio AND metadata as opposed to 
just 96kbit of audio.
The best is to provide the minimal of info and then do a asynchronous 
lookup to get more details and cover artwork and then display that.


BTW! If I still can't make you understand that royalty reporting has 
nothing to do with playing the stream in a web browser then I really do 
not know what to do. Such royalty reporting is done at either radio 
level, DJ level, or server level, way before any stream or metadata ever 
reaches a browser. I'd like this to be my last post on this, I'm tired 
of repeating myself and I can only guess how annoying the others might 
find this weird topic now. So I'm not going to respond to any future 
posts on this semi-off-topic.


-- 
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0). My opinions are my own unless specified otherwise.
Roger Hågensen,
Freelancer, Norway.
Received on Sunday, 23 April 2017 18:55:43 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 23 April 2017 18:55:43 UTC