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

Hi all: 

  * I agree with the exposure of  issues Andy presents. I do sympathize
with his approach, too.

  * getMetadata sounds reasonable to me. The choice that a final
user/client of a web service, or a streaming service, can add some data
sounds reasonable to me. And I am not meaning the user/client as human
being here. Machine talks ( streams) to a machine using a browser based
solution, being precise.
  * Voice is de facto the new way human beings browse the web. Humans
search for things and interests out of work with her/his voices
commands. These voices have and hold meta-data. And I do not mean any
karaoke silly scenario, being more precise.

  * Concerning to all servers, radio/stations and other initial
committers.
  * I am not pretty we should lay on them the responsibility to add or
remove metadata
  * there was an issue, citing by memory an example,  with that
Soundcloud music browser based platform on the treatment of its
meta-data, while streaming audio, I guess.
(http://preview.tinyurl.com/issue-metadata ) _"In fact SoundCloud was
initially started with the mission to be the world's largest database of
sounds and it seems as if it never properly adapted their architecture"_
  * The example of Soundcloud looks to me what a browser based software
( radio service or music service) offers streaming its data, and may
take real advantage of any future API enhancement or the <audio> tag we
are trying to improve in this written talk.
  * the link provided before is another solution built by two mates who
are, maybe, as much experienced dealing with <audio> files as Roger is.
https://www.orfium.com/press/ 
  *  I wonder , Shall not be profitable or interesting to ask those
engineers, to know a bit of their browser based service solution?
  * Returning to the technical aspects, and according with
Andy,considering a  getMetadata() class is a plus

Cheers

---

Delfi Ramirez -- At Work

My digital signature [1]

0034 633 589231
 delfin@segonquart.net [2] 

twitter: @delfinramirez [3]
 IRC: segonquart
 Skype: segonquart [4]

http://segonquart.net

http://delfiramirez.info
 [5]

On 2017-04-23 20:55, Roger Hågensen wrote:

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

 

Links:
------
[1] http://delfiramirez.info/public/dr_public_key.asc
[2] mail:%20delfin@segonquart.net
[3] https://twitter.com/delfinramirez
[4] skype:segonquart
[5] http://delfiramirez.info

Received on Sunday, 23 April 2017 20:23:27 UTC