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

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

Reply via email to