On 2017-04-23 18:58, Andy Valencia wrote:
Reporting Only "artist" and "title" are required for royalties reporting for
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
Icecast do these, and AFAIK so can Shoutcast v2. And in any case most
streaming service providers use Centovacast which has it's own
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
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
"*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
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.