Re: [whatwg] 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 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 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 del...@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
Re: [whatwg] metadata (and royalty reporting for some weird reason)
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
