Re: [whatwg] metadata

[Silvia Pfeiffer]

On Mon, Apr 24, 2017 at 5:04 AM, Kevin Marks  wrote:
> On Sun, Apr 23, 2017 at 5:58 PM, Andy Valencia
>  wrote:
>> === Dynamic versus static metadata
>>
>> Pretty much all audio formats have at least one metadata format.  While
>> some apparently can embed them at time points, this is not used by any
>> players I can find.  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
>>
>> Metadata formats as applied to static information are, of course, of
>> great interest.  Any dynamic technique should fit into the existing
>> approach.
>
> There are lots of models for dynamic metadata - look at soundcloud
> comments at times, youtube captions and overlays, Historically there
> have been chapter list markers in MPEG, QuickTime and mpeg4 (m4a, m4v)
> files too.

A different method is used on the Web for dynamic metadata: TextTracks
have been standardised to expose such time-aligned metadata. I don't
think this is the core of the discussion here though.

Cheers,
Silvia.

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

[Delfi Ramirez]

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

[Kevin Marks]

On Sun, Apr 23, 2017 at 5:58 PM, Andy Valencia
 wrote:
> === Dynamic versus static metadata
>
> Pretty much all audio formats have at least one metadata format.  While
> some apparently can embed them at time points, this is not used by any
> players I can find.  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
>
> Metadata formats as applied to static information are, of course, of
> great interest.  Any dynamic technique should fit into the existing
> approach.

There are lots of models for dynamic metadata - look at soundcloud
comments at times, youtube captions and overlays, Historically there
have been chapter list markers in MPEG, QuickTime and mpeg4 (m4a, m4v)
files too.

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

[Roger Hågensen]

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 

Re: [whatwg] metadata

[Andy Valencia]

I've become aware of quite a bit more metadata support in the world
of web browsers; please consider my old proposal withdrawn.

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

=== Dynamic versus static metadata

Pretty much all audio formats have at least one metadata format.  While
some apparently can embed them at time points, this is not used by any
players I can find.  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

Metadata formats as applied to static information are, of course, of
great interest.  Any dynamic technique should fit into the existing
approach.

You have to draw a distinction between API's concerned with UI/UX
presentation, and those concerned with getting the underlying
information.  MediaMetadata is an example of the former, mozGetMetadata
the latter.  I'm now looking at mozGetMetadata as a starting point,
with a minimal change to add dynamic metadata events.

Of course, mozGetMetadata makes a very nice counterpart to Chrome's
MediaMetadata API for rendering the information to the listener.

=== Processing a stream programatically
> If the same-origin policy stops you, it should also stop a C++
> implementation. It's there for a reason.

This is all framed by techniques exemplified by 
which enjoy permissive origin treatment.  The goal is to glean
the information which is *available anyway*.  Without changing the
protection regime.

=== Non-trivial audio application
> Also royalty reporting is done in a earlier stage, what a listener sees
> is not what is logged/given for royalties reporting.

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.

=== Proposed new API direction

Here's the approach which now makes the most sense to me.

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.

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

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 "

Re: [whatwg] metadata (re-mapping)

[Roger Hågensen]

On 2017-04-16 15:36, Delfi Ramirez wrote:

* Sound.load(new URLRequest("07 - audio.mp3"));
* Some old tricks on the issue were done in the past. here the link of
an ECMAScript derivative from the past, if it serves you as a model ID3
tags Get/Receive [6].


That is not a trick, that is Flash ActionScript by the looks of it. 
Flash (and by proxy it's scripting) is pretty much deprecated now.
And if you are suggesting presenting id3 metadata then I'd rather not 
see that, the web developer do not need to know if it's a mp3 ID3 tag or 
Ogg metadata, they only need key value pairs. And the mp3 stream parsing 
code can re-map the most common id3 tags to a more sensible (UTF8/UTF16) 
lowercase key name, it's possible even some of the Ogg tags may need 
re-mapping.


People at Hydrogen audio have tried to remap these into something common
http://wiki.hydrogenaud.io/index.php?title=Tag_Mapping
That is probably the most comprehensive re-mapping guide on the web 
right now.


Using Vorbis Comments as the basis seems sensible (only lowercase 
instead as lowercase compress better with gzip as there are more 
lowercase text than uppercase text in webpages and javascript).



* Sounds: Rings and bleeps of a mobile device or a computer device.
Audio meta tags should be applicable to the webplayer ( one file vs.
multiple files ).


I doubt anyone streams their ringtone from the web.



*  Streaming on the web: As I noticed to this group in my last email,
in our present days there is a growing demand for streaming by
scientific communities to publish audio conferences or talks.


I do not see why this is an issue, as long as metadata can be handled, 
like for example meta data in ogg (files and live streams). Then any 
metadata can be added.


Are you suggesting that the default audio and video player presents a 
info via the UI?
I can see artist (creator) and title, year, copyright/license (for 
example "CC BY") as the 4 minimum pieces of info that would be useful. 
And would work for audio and video.


But for custom UIs or enhanced UIs the webdeveloper would (or at least 
ideally should) be able to pull any metadata from the file/stream and be 
notified if a stream changes/send new metadata.




* The only important issue to consider would be the five seconds
minimum lenght.


I fail to see what this has to do with metadata. And if you are 
suggesting any playback length limiting for audio that is not "licensed" 
then that is not a discussion I wish to be part of as that would be akin 
to censorship. As a independent artist myself I'm not registered with 
any PROs nor do I ever have the intention to do so which would mean my 
own music would be limited to 5 sec playback.



I suspect that you are addressing the wrong group here for most of the 
stuff you are talking about. Any playback length limitations due to 
potentially legal issues is the responsibility of the party that 
actually shares the audio or video, not that of the browser developers 
nor the web standards.


If you want certain metadata tags standardized then please know that 
none really exists of id3. Not even Ogg (Vorbis comments) is "standard".
But a few semi-official ones are found here 
https://xiph.org/vorbis/doc/v-comment.html

(these are also listed on the Hydrogen Audio wiki page)
Also note that Vorbis comment keys should be treated as case insensitive 
so Vorbis comment keys could easily be used as is with no re-mapping 
just a case conversion.
And I'm sure Xiph and Hydrogen Audio would be happy to help 
"standardize" various key names for tags and the tag formatting as well.


This could be as simple as WHATWG creating a table of the most 
important/common keys used. And then the Hydrogen Audio wiki would 
replicate that table and add the mapping advisory between WHATWG and 
Vorbis/id3/MP4 etc.
Xiph could update their page on Vorbis comments to match/include the 
WHATWG key names if they are not already listed.


I have no idea who maintains http://id3.org/ but I'm sure they would 
want to participate too.


--
Unless specified otherwise, anything I write publicly is considered 
Public Domain (CC0).

Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] metadata

[Delfi Ramirez]

Hi Roger, hi all: 

* "_passing metadata in a stream so that a HTML webplayer can show
artist and title_" can be accomplished extracting the ID3 tags from the
file and presenting them as JSON values, for example 

* Sound.load(new URLRequest("07 - audio.mp3"));
* Some old tricks on the issue were done in the past. here the link of
an ECMAScript derivative from the past, if it serves you as a model ID3
tags Get/Receive [6].

But, please take in consideration: 

* Not all webplayers stream music by obligation. Not all webplayers
are designed to play music.

* Sounds: Rings and bleeps of a mobile device or a computer device.
Audio meta tags should be applicable to the webplayer ( one file vs.
multiple files ).
*  Streaming on the web: As I noticed to this group in my last email,
in our present days there is a growing demand for streaming by
scientific communities to publish audio conferences or talks.

* Concerning to my references WIPO et al, yes I agree , technology
should be considered neutral.

* The only important issue to consider would be the five seconds
minimum lenght.

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-16 13:54, Roger Hågensen wrote:

> On 2017-04-16 03:01, Delfi Ramirez wrote: 
> 
>> * WIPO stands for _World Intellectual Property Organization_, and the
>> ...
>> *  Meta-Data: Following the indications of the WIPO ( focusing on a
>> World Wide Web service ) that now, services like Pandora are not allowed
>> to stream ( are de facto banned ) in earth places like Africa, Europe,
>> or The East. May it be due to not meet the legal requirements.
> 
> The reason for services like Pandora geoblocking is because the PROs are 
> basically trying to carve out regions (like region blocking for DVDs and 
> BlueRay), it's greedy and stupid. The EU is working on legislations to limit 
> or do away with this for online stuff.
> 
> Also, metadata sent to the user/listener has very little to do with royalty 
> reporting. The reporting must be done by the webmaster at the webserver level 
> or by the DJ at the encoding level.
> These logs are then passed independently of what the the listener see/hear.
> 
> One thing that could be useful to show to the listener is a copyright hint 
> like indicating if the stream is CC BY (Creative Commons Attribution) for 
> example.
> 
> May I also point out that this has gone very offtopic (I should probably be 
> the last person to point this out though).
> 
> WHATWG has very little to do with PROs/WIPO/Royalties/rights, a different 
> fora should be used for that.
> 
> I'd like to get back on topic and to the discussion of passing metadata in a 
> stream so that a HTML webplayer can show artist and title (and maybe 
> year/album if present) to the listener and have this be changed/updated when 
> this info changes in the stream (usually at song change but can occur more 
> often to provide special non-song messages as well).
> 
> Firefox seems to support it (though I have not had the time to test it yet) 
> but it is uncertain what formats it works on and if it works for streams at 
> all.
> 
> -- 
> Roger Hågensen,
> Freelancer, Norway.
 

Links:
--
[1] http://delfiramirez.info/public/dr_public_key.asc
[2] mail:%20del...@segonquart.net
[3] https://twitter.com/delfinramirez
[4] skype:segonquart
[5] http://delfiramirez.info
[6]
http://help.adobe.com/en_US/as2/reference/flashlite/WS5b3ccc516d4fbf351e63e3d118ccf9c47f-7bc8.html

Re: [whatwg] metadata

[Roger Hågensen]

On 2017-04-16 03:01, Delfi Ramirez wrote:

* WIPO stands for _World Intellectual Property Organization_, and the
...
*  Meta-Data: Following the indications of the WIPO ( focusing on a
World Wide Web service ) that now, services like Pandora are not allowed
to stream ( are de facto banned ) in earth places like Africa, Europe,
or The East. May it be due to not meet the legal requirements.


The reason for services like Pandora geoblocking is because the PROs are 
basically trying to carve out regions (like region blocking for DVDs and 
BlueRay), it's greedy and stupid. The EU is working on legislations to 
limit or do away with this for online stuff.


Also, metadata sent to the user/listener has very little to do with 
royalty reporting. The reporting must be done by the webmaster at the 
webserver level or by the DJ at the encoding level.

These logs are then passed independently of what the the listener see/hear.

One thing that could be useful to show to the listener is a copyright 
hint like indicating if the stream is CC BY (Creative Commons 
Attribution) for example.



May I also point out that this has gone very offtopic (I should probably 
be the last person to point this out though).


WHATWG has very little to do with PROs/WIPO/Royalties/rights, a 
different fora should be used for that.


I'd like to get back on topic and to the discussion of passing metadata 
in a stream so that a HTML webplayer can show artist and title (and 
maybe year/album if present) to the listener and have this be 
changed/updated when this info changes in the stream (usually at song 
change but can occur more often to provide special non-song messages as 
well).


Firefox seems to support it (though I have not had the time to test it 
yet) but it is uncertain what formats it works on and if it works for 
streams at all.




--
Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] metadata

[Delfi Ramirez]

Hi Roger, hi all: 

My fault WPI, was horrendous mistake due to the keyboard, and other
thingsin mind : WIPO, I meant. 

here below the info to avoid future re-works in the API and teh 
tag, if it helps. 

* WIPO stands for _World Intellectual Property Organization_, and the
IP acronym for them, mean _royalties. _Speaking in our technical terms,_
funding_.

* http://www.wipo.int/wipo_magazine/en/2015/02/article_0001.html 
* The international legal rule is featured in the Article 15  of the
treaty : 
[6]http://www.wipo.int/treaties/en/text.jsp?file_id=295578#P126_16257

Addenda: 

I did not want to be rude, neither to pray for extra efforts by the team
at WHATWG. just put in common knowledge , based on my past personal (
say vane ) professional experience. 

Jut three final observations to serve and to help 

* Length: Five seconds MAY be the minimum legal.

* (5") Five seconds of 'stolen' / Ring sounds that are digitised audio
files/Different mixes/edits seconds/et cetera of  is the minimum
for a wannabe-lawyer to go to court.. Please, keep this fact in mind.

*  Meta-Data: Following the indications of the WIPO ( focusing on a
World Wide Web service ) that now, services like Pandora are not allowed
to stream ( are de facto banned ) in earth places like Africa, Europe,
or The East. May it be due to not meet the legal requirements.  Because
of, sadly, streaming besides the neutrality of the technique is a unique
sales channel.
* IRSC: "_The MP3 format does allow rights management information like
ISRC to be included however it is rarely used. What is used is the ID3
system of tags, which is not part of the international standard, but
does enable ISRC to be encoded. It is therefore recommended that an ISRC
be encoded into the ID3 tag._" Uh. 
*   files may not just to streaming songs or bleeps, but to
scientific talks and college conferences. which may be radio live
transmitted.
* Thus, the (Title - Author) binomial proposed, in this clear need,
does not works.

just mumbling 

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-15 20:21, Roger Hågensen wrote:

> On 2017-04-15 14:00, Delfi Ramirez wrote: 
> 
>> Some information that may be of use, concerning to the WPI rules for
>> royalties et al in  files.
> 
> I have no idea what/who WPI is.
> 
> But StreamLicensing.com (which has a deal with ASCAP/BMI/SESAC/SoundExchange)
> Only require artist and title, and that artist and title is viewable by the 
> listener.
> One of the PROs (Performance Royalty Organization) did want album but waived 
> that requirement.
> 
>> Meta elements required
>> 
>> * Title : 100%
>> * Artist ( Interpreter): 12%
>> * Time: lenght of the  piece. Royalties are assigned by time
>> sequences.
>> * Year: (_Objective Reason: It use to happen that some__  files
>> have the same name, thus causing a mistake in the attribution to the
>> artist as it happen in the past_)
>> * Composer: 20%
>> * Arrangements: 20%
>> * Producer: 40%
> 
> Artist and title is always required. But I assume that by title you the field 
> itself as in it being "Some Artist - Some Song" where spacedashspace (" - ") 
> is a separator for artist and title.
> As to length, any listened time longer than 30 seconds is counted, and I 
> forge the max time.
> You also forgot about mentioning ISRC which is a globally unique identifier 
> for tracks, radio stations may use ISRC when sending in performance logs.
> 
> I'm not sure a end listener would need all this meta data though, such info 
> should be logged separately by the radio station or by the streaming server 
> itself.
> The listener would only be interested in (minimum) artist and title, album, 
> year and artwork being a bonus. And lyrics being a nice surprise.
> Although I'd argue that artist and title (+ album and year) could be used to 
> fetch artwork and lyrics using XHR upon user interaction instead.
> 
> I'm not going to comment further on the royalty stuff as this is weering 
> quite off-topic now.
> 
> -- 
> Roger Hågensen,
> Freelancer, Norway.
 

Links:
--
[1] http://delfiramirez.info/public/dr_public_key.asc
[2] mail:%20del...@segonquart.net
[3] https://twitter.com/delfinramirez
[4] skype:segonquart
[5] http://delfiramirez.info
[6] http://www.wipo.int/treaties/en/text.jsp?file_id=295578#P126_16257

Re: [whatwg] metadata

[Anne van Kesteren]

On Fri, Apr 14, 2017 at 10:23 PM, Andy Valencia
 wrote:
> But the overarching issue is that you're doing JS-initiated
> network operations, and origin policy is going to stop you.
> You can claim Shoutcast/Icecast should give permissive
> origins, but they don't, and since an admin-ish interface is
> also multiplexed at the host, probably shouldn't.

If the same-origin policy stops you, it should also stop a C++
implementation. It's there for a reason.


-- 
https://annevankesteren.nl/

Re: [whatwg] metadata

[Roger Hågensen]

On 2017-04-15 14:00, Delfi Ramirez wrote:

Some information that may be of use, concerning to the WPI rules for
royalties et al in  files.


I have no idea what/who WPI is.

But StreamLicensing.com (which has a deal with 
ASCAP/BMI/SESAC/SoundExchange)
Only require artist and title, and that artist and title is viewable by 
the listener.
One of the PROs (Performance Royalty Organization) did want album but 
waived that requirement.



Meta elements required

* Title : 100%
* Artist ( Interpreter): 12%
* Time: lenght of the  piece. Royalties are assigned by time
sequences.
* Year: (_Objective Reason: It use to happen that some__  files
have the same name, thus causing a mistake in the attribution to the
artist as it happen in the past_)
* Composer: 20%
* Arrangements: 20%
* Producer: 40%


Artist and title is always required. But I assume that by title you the 
field itself as in it being "Some Artist - Some Song" where 
spacedashspace (" - ") is a separator for artist and title.
As to length, any listened time longer than 30 seconds is counted, and I 
forge the max time.
You also forgot about mentioning ISRC which is a globally unique 
identifier for tracks, radio stations may use ISRC when sending in 
performance logs.


I'm not sure a end listener would need all this meta data though, such 
info should be logged separately by the radio station or by the 
streaming server itself.
The listener would only be interested in (minimum) artist and title, 
album, year and artwork being a bonus. And lyrics being a nice surprise.
Although I'd argue that artist and title (+ album and year) could be 
used to fetch artwork and lyrics using XHR upon user interaction instead.


I'm not going to comment further on the royalty stuff as this is weering 
quite off-topic now.


--
Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] metadata

[Delfi Ramirez]

Hi All: 

Some information that may be of use, concerning to the WPI rules for
royalties et al in  files. 

What we know as rights. Uh, 

Meta elements required 

* Title : 100%
* Artist ( Interpreter): 12%
* Time: lenght of the  piece. Royalties are assigned by time
sequences.
* Year: (_Objective Reason: It use to happen that some__  files
have the same name, thus causing a mistake in the attribution to the
artist as it happen in the past_)
* Composer: 20%
* Arrangements: 20%
* Producer: 40%
* Label: It depends on the contract, but as an agent collects all the
rights
* Software: Last but not least, some software use in the production of
audio has its own rights. Uh.

Hope this information it helps for the meta-tag issues 

_BTW . There is a new start-up  company named orfium.com, which CEOs now
all this issues, there is the cahnce ask them for more info._ 

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-15 13:46, Roger Hågensen wrote:

> On 2017-04-14 22:23, Andy Valencia wrote: 
> 
>> Ok.  Note that this data structure suffices to encode the baseline
>> information from Shoutcast/Icecast.  It does not, for instance,
>> encode "Label", needed to do licensing reporting in the USA.
>> "Year" is another datum often of interest.
> 
> Only "artist" and "title" are required for royalties reporting for internet 
> radio.
> But "album" and "year" provides additional information that helps.
> Commercial radio and TV uses at minimum the artist and title, and if lucky 
> the listener (digital radio) and viewer get to also see album and year.
> Also royalty reporting is done in a earlier stage, what a listener sees is 
> not what is logged/given for royalties reporting.
> 
> Ogg (Vorbis or Opus) should in theory be easily supported as metadata is 
> given in a sidestream right? So is therefore independent of the audio stream.
> 
> Mozilla has audio.mozGetMetadata()
> https://developer.mozilla.org/en/docs/Web/API/HTMLMediaElement
> 
> I have no idea if that fires once or each time more metadata is passed in the 
> stream.
> 
> https://developer.mozilla.org/en-US/docs/Web/Events/loadedmetadata
> Only says that it is fired when the metadata is loaded.
> I'm assuming it's only at stream start though.
> 
> So with a few "tweaks" Firefox could support Icecast Ogg metadata, if the 
> browser is compliant with the Ogg standard then support is very easy to add.
> 
> Shoutcast v1 would require parsing of the audio stream, Shoutcast v2 is a 
> little different and can pass info like album and year and artwork.
> The only Shoutcast v2 compatible player I'm aware of is the aging Winamp, the 
> majority of Shoutcast streams are v1 streams.
> 
> So while Firefox almost is able to provide stream meta updates, all the other 
> browsers do not though and would require polyfill which as you point out has 
> it's own issues with having to reset the stream as the buffer fills up.
> 
> Maybe support for enabling a large cyclic buffer could be used, triggered by 
> a "stream" parameter for html audio maybe.
> There would still be a issue with metadata possibly being partly in the 
> current buffer and partly in the next buffer so any javascript would need to 
> splice that together.
> 
> Ogg seems simple enough
> https://www.xiph.org/ogg/doc/oggstream.html
> And parsing of this metadata should be in the ogg source (libogg?) so any 
> browser that supports Ogg should be able to get that metadata.
> 
> -- 
> Roger Hågensen,
> Freelancer, Norway.
 

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

Re: [whatwg] metadata

[Roger Hågensen]

On 2017-04-14 22:23, Andy Valencia wrote:

Ok.  Note that this data structure suffices to encode the baseline
information from Shoutcast/Icecast.  It does not, for instance,
encode "Label", needed to do licensing reporting in the USA.
"Year" is another datum often of interest.


Only "artist" and "title" are required for royalties reporting for 
internet radio.

But "album" and "year" provides additional information that helps.
Commercial radio and TV uses at minimum the artist and title, and if 
lucky the listener (digital radio) and viewer get to also see album and 
year.
Also royalty reporting is done in a earlier stage, what a listener sees 
is not what is logged/given for royalties reporting.



Ogg (Vorbis or Opus) should in theory be easily supported as metadata is 
given in a sidestream right? So is therefore independent of the audio 
stream.


Mozilla has audio.mozGetMetadata()
https://developer.mozilla.org/en/docs/Web/API/HTMLMediaElement

I have no idea if that fires once or each time more metadata is passed 
in the stream.


https://developer.mozilla.org/en-US/docs/Web/Events/loadedmetadata
Only says that it is fired when the metadata is loaded.
I'm assuming it's only at stream start though.

So with a few "tweaks" Firefox could support Icecast Ogg metadata, if 
the browser is compliant with the Ogg standard then support is very easy 
to add.


Shoutcast v1 would require parsing of the audio stream, Shoutcast v2 is 
a little different and can pass info like album and year and artwork.
The only Shoutcast v2 compatible player I'm aware of is the aging 
Winamp, the majority of Shoutcast streams are v1 streams.


So while Firefox almost is able to provide stream meta updates, all the 
other browsers do not though and would require polyfill which as you 
point out has it's own issues with having to reset the stream as the 
buffer fills up.


Maybe support for enabling a large cyclic buffer could be used, 
triggered by a "stream" parameter for html audio maybe.
There would still be a issue with metadata possibly being partly in the 
current buffer and partly in the next buffer so any javascript would 
need to splice that together.



Ogg seems simple enough
https://www.xiph.org/ogg/doc/oggstream.html
And parsing of this metadata should be in the ogg source (libogg?) so 
any browser that supports Ogg should be able to get that metadata.



--
Roger Hågensen,
Freelancer, Norway.

Re: [whatwg] metadata

[Andy Valencia]

Thank you for the helpful comments.

 wrote:
> http://www.smackfu.com/stuff/programming/shoutcast.html isn't detailed
> enough to get interoperable implementations, in particular the metadata
> keys would have to be defined.

Note that mp3, flag, ogg, and wav all have entirely open ended
container formats for their metadata.  The framework as used by
Shoutcast and Icecast is similarly extensible, although StreamTitle
and StreamUrl are the obvious low-hanging fruit.  I've reached
out to the Icecast folks to see if there's interest in, say,
an informational RFC.

> Second, as already outlined above, one needs to be able to get the
> current metadata somehow. I think that a mediaElement.getMetadata()
> method that returns a
> https://wicg.github.io/mediasession/#the-mediametadata-interface
> instance would make sense, and then the metadatachange event could
> be a simple event with no extra information on it.

Ok.  Note that this data structure suffices to encode the baseline
information from Shoutcast/Icecast.  It does not, for instance,
encode "Label", needed to do licensing reporting in the USA.
"Year" is another datum often of interest.

But "good enough" as a starting point is fine by me.

I'm assuming getMetadata() is based on the older mozGetMetadata()
API?  That API appears to auto-populate from the various supported
audio file headers.  So adding "dynamicmetadata" is just another
way for those fields to be populated.

(I'm going to look at submitting an edit to the metadata container
so it can handle extension information, something along the lines
of the "X-" prefix in RFC-822 headers.  That would be orthogonal
to this work.)

> In order to make progress, there needs to be implementer interest.

Yes; I have no doubt there's many more ideas to lob at browser
implementors than they could ever cook up (even if vetted to just
the "good ones").  However, as a long-time C dev with a touch of C++,
I'm counting on doing an implementation for at least one major
browser if I get to rough consensus.

I know, it doesn't guarantee they'll accept my submission.

 wrote:
> Demonstrating there's interest in this through a popular JavaScript
> library or two would help a lot.

If I could do this in Javascript, I would.  Multiple issues:

 and src= run at the full efficiency of platform audio
streaming.  But you don't get to see the bytes.

You can do the fetch yourself and look at the partial data in
responseText (remember, it's an ongoing stream).  But responseText
keeps growing, requiring you to periodically reset the connection.
Hard to maintain a listening experience.

What to do with the bytes after peeling out the mdatadata?  A local
URL is based on a Blob, which is immutable, so no good way to tack on
newly arrived data.  You can run your own ogg/flac/mp3/wav decoder,
but you'll come up short of platform efficiency.  Probably a non-
starter for mobile.

The new ReadableStream mechanism to feed fetches out of a
Service Worker is either a solution, or at least pretty close.
(I can't quite convince myself it's actually mutable in the way
needed to endlessly append stream data as it arrives.)

But the overarching issue is that you're doing JS-initiated
network operations, and origin policy is going to stop you.
You can claim Shoutcast/Icecast should give permissive
origins, but they don't, and since an admin-ish interface is
also multiplexed at the host, probably shouldn't.

I'll rework my submission based on these comments, thanks again.

Re: [whatwg] metadata

[Anne van Kesteren]

On Mon, Apr 10, 2017 at 6:44 AM, Philip Jägenstedt  wrote:
> There is a very old bug for exposing the metadata:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=5755
>
> In order to make progress, there needs to be implementer interest. Although
> it may well fizzle out, a new issue
> https://github.com/whatwg/html/issues/new with the concrete suggested
> changes for HTML would be a good starting point.

Demonstrating there's interest in this through a popular JavaScript
library or two would help a lot.


-- 
https://annevankesteren.nl/

Re: [whatwg] metadata

[Philip Jägenstedt]

On Mon, Apr 10, 2017 at 8:38 AM Andy Valencia 
wrote:

> What follows is a first pass at addressing a missing ability
> when dealing with Internet streams, usually radio ones.
> Comments and suggestions are quite welcome; as my first
> attempt--ever--at submitting to this group, apologies if
> I've made any mistakes in how I've proceeded.
>
> Thanks,
> Andy Valencia
> Contact: https://vsta.org/contact/andy
>
> 
> Proposal for enhancement to HTML5  element to better support
> metadata provided by streams.
>
> # Background
>
> Browsers have an  element which can directly play streaming
> URL's.  When the stream is an Internet radio station, the stream
> almost certainly offers metadata; typically, the artist and track,
> and often an album cover URL as well.  While modern browsers can
> play these streams, there is no way to access this metadata.
>
> Media elements in modern browsers _do_ have the notion of metadata,
> but in current standards this is limited to static characteristics
> such as duration.  When listening to a radio stream, the metadata will
> change as successive tracks are played.
>
> # Stream Delivery of Dynamic Metadata
>
> A moderately detailed description of current practices in providing
> metadata is provided at:
>
> http://www.smackfu.com/stuff/programming/shoutcast.html
>
> (One detail glossed over in this page is that older streaming servers
> start their GET response with "ICY 200 OK" rather than a standard
> HTTP response.  This technically means the response is HTTP 0.9
> without headers; the headers are present, but must be processed by
> the application and trimmed from the start of the media stream
> in the GET response.  Apple Safari already declines to play 0.9
> media elements within a post-0.9 page, and there are signs that
> Chrome will follow suit.  Thus, accomodating this older mode should
> be considered optional.)
>
> Newer streaming server versions use a proper HTTP response, with
> the documented elements in the HTTP response header.
>
> Because the metadata is encoded in a general attribute=value
> format, a wide variety of metadata may be encoded.  By convention,
> at least the attributes "StreamTitle" and "StreamUrl" will be
> included in the response.  Also by convention, StreamTitle is
> structured as "Artist - Track Name".
>
> # API Considerations
>
> While listening to streams with metadata is a compelling application
> of web technology, it is probably a tiny percentage of the use
> of  elements.  Thus, this proposal describes a mechanism
> which leaves the default browser behavior unchanged.  It also
> gracefully degrades when presented to a non-implementing
> browser, still permitting stream play while in the existing
> non-metadata fashion.
>
> This proposal is designed with the current state of streaming,
> currently depending on the HTTP Icy-MetaData header element.  However,
> this specific detail is abstracted, in recognition that streaming
> technology could evolve in the future.  The intention is that this API
> will remain stable even if the details of metadata request and
> delivery change.
>
> As noted, current HTML5 media elements do have some metadata support.
> This API is also structured to permit these existing elements to
> participate in this API if desired.
>
> #  element changes
>
> These enhancements are activated when the  element has the
> new attribute "dynamicmetadata" present.  Without this attribute,
> no metadata request header is added to the stream HTTP request, and no
> other attributes of this proposal will be acted upon even if present.
>
> If the server response indicates support for dynamic metadata,
> on each metadata update, the  element's attributes are changed
> to reflect the latest received metadata.  For each "Attribute=Value"
> in the metadata update, an attribute "metaAttribute" with value "Value"
> will
> be added to the  element.  Previous metadata attributes which
> are not present in the latest update are left untouched.  The browser
> must verify well-formed identifier names for each Attribute, and
> quietly reject ill-formed names.  It can also apply checks on the
> Value.  (Implementors are reminded that the Value, because it encodes
> information such as names, might contain a wide range of character
> encodings.)
>
> The  element adds the hook "onmetadatachange", connecting to
> a function which is called on each update of metadata.  This
> function is called with an event, which includes the attribute
> "changed" with a value which is a list of Attribute names which
> are present in the update.
>
> # Example code
>
> 
> function new_meta(ev) {
> const changes = ev.changed;
> if (changes.indexOf("StreamTitle") >= 0) {
> const title = player.metaStreamTitle;
> const idx = title.indexOf(" - ");
> if (idx == -1) {
> // "Just a plain old piece of text"
> artist.textContent = title;
> 

[whatwg] metadata

[Andy Valencia]

What follows is a first pass at addressing a missing ability
when dealing with Internet streams, usually radio ones.
Comments and suggestions are quite welcome; as my first
attempt--ever--at submitting to this group, apologies if
I've made any mistakes in how I've proceeded.

Thanks,
Andy Valencia
Contact: https://vsta.org/contact/andy


Proposal for enhancement to HTML5  element to better support
metadata provided by streams.

# Background

Browsers have an  element which can directly play streaming
URL's.  When the stream is an Internet radio station, the stream
almost certainly offers metadata; typically, the artist and track,
and often an album cover URL as well.  While modern browsers can
play these streams, there is no way to access this metadata.

Media elements in modern browsers _do_ have the notion of metadata,
but in current standards this is limited to static characteristics
such as duration.  When listening to a radio stream, the metadata will
change as successive tracks are played.

# Stream Delivery of Dynamic Metadata

A moderately detailed description of current practices in providing
metadata is provided at:

http://www.smackfu.com/stuff/programming/shoutcast.html

(One detail glossed over in this page is that older streaming servers
start their GET response with "ICY 200 OK" rather than a standard
HTTP response.  This technically means the response is HTTP 0.9
without headers; the headers are present, but must be processed by
the application and trimmed from the start of the media stream
in the GET response.  Apple Safari already declines to play 0.9
media elements within a post-0.9 page, and there are signs that
Chrome will follow suit.  Thus, accomodating this older mode should
be considered optional.)

Newer streaming server versions use a proper HTTP response, with
the documented elements in the HTTP response header.

Because the metadata is encoded in a general attribute=value
format, a wide variety of metadata may be encoded.  By convention,
at least the attributes "StreamTitle" and "StreamUrl" will be
included in the response.  Also by convention, StreamTitle is
structured as "Artist - Track Name".

# API Considerations

While listening to streams with metadata is a compelling application
of web technology, it is probably a tiny percentage of the use
of  elements.  Thus, this proposal describes a mechanism
which leaves the default browser behavior unchanged.  It also
gracefully degrades when presented to a non-implementing
browser, still permitting stream play while in the existing
non-metadata fashion.

This proposal is designed with the current state of streaming,
currently depending on the HTTP Icy-MetaData header element.  However,
this specific detail is abstracted, in recognition that streaming
technology could evolve in the future.  The intention is that this API
will remain stable even if the details of metadata request and
delivery change.

As noted, current HTML5 media elements do have some metadata support.
This API is also structured to permit these existing elements to
participate in this API if desired.

#  element changes

These enhancements are activated when the  element has the
new attribute "dynamicmetadata" present.  Without this attribute,
no metadata request header is added to the stream HTTP request, and no
other attributes of this proposal will be acted upon even if present.

If the server response indicates support for dynamic metadata,
on each metadata update, the  element's attributes are changed
to reflect the latest received metadata.  For each "Attribute=Value"
in the metadata update, an attribute "metaAttribute" with value "Value" will
be added to the  element.  Previous metadata attributes which
are not present in the latest update are left untouched.  The browser
must verify well-formed identifier names for each Attribute, and
quietly reject ill-formed names.  It can also apply checks on the
Value.  (Implementors are reminded that the Value, because it encodes
information such as names, might contain a wide range of character
encodings.)

The  element adds the hook "onmetadatachange", connecting to
a function which is called on each update of metadata.  This
function is called with an event, which includes the attribute
"changed" with a value which is a list of Attribute names which
are present in the update.

# Example code


function new_meta(ev) {
const changes = ev.changed;
if (changes.indexOf("StreamTitle") >= 0) {
const title = player.metaStreamTitle;
const idx = title.indexOf(" - ");
if (idx == -1) {
// "Just a plain old piece of text"
artist.textContent = title;
track.textContent = "";
} else {
//  - 
artist.textContent = title.slice(0, idx);
track.textContent = title.slice(idx+3);
}
}
if (changes.indexOf("StreamUrl") >= 0) {
// Display album art
art.src = 

Re: [whatwg] metadata attribute for media

[Ralph Giles]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 17/02/13 05:48 AM, Nils Dagsson Moskopp wrote:

 If one cares to that extent, and is
 already handling format differences, dealing with vendor
 variation on top isn't that much more effort.
 
 I disagree, strongly.

Ok, thanks for the feedback. Do you like my subsequent proposal better?

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-January/038705.html

 -r

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRImnnAAoJEEcAD3uxRB3vHBwH/14a91L4oN6nktTttTRvQQFf
hmtz52nAO7BdInpG68fRACgLVsz2eT+eWakAAMuzh7T57NH9ZNCSWp1Rk/AM3BXD
akx6QXQuk9eOwuRlk+BIVIUaKVFyod9D133BdTjGqF6/cVmn7emmIm9BWB0sxXrE
3CPuALqs+07ExHbyB/UsE5BWqsJRccJHg9QnJwXd4aMtHbIg37KAcfgN4aYVTHQV
B1I95Uh1Ron2LUCNI9P+Pm8WPQGDcj0cuwFcueRMYy2O26a1xHisOew/l3Cz46Ex
Oq6gAX3Lz/y5LxFhnnlPIeBDhBE9bB0r4jqOtY3FNA+dcUruKI769nIw5WtTmd4=
=zJ6M
-END PGP SIGNATURE-

Re: [whatwg] metadata attribute for media

[Nils Dagsson Moskopp]

Ralph Giles gi...@mozilla.com schrieb am Tue, 11 Dec 2012 17:23:38
-0800:

 On 12-12-11 4:58 PM, Ian Hickson wrote:
 
 […]

  I don't think we should have an open-ended API without fixed names, 
  because that is a recipe for an interoperability disaster.
 
 I agree it would have interoperability issues. My own implementation
 experience is that the easy thing to do is to mirror whatever
 representation your playback framework offers, which can result in
 per-platform differences as well as per-media-format (and per tagging
 application, etc.).

Just doing “the easiest thing” when you are a content-emitter (e.g. a
software developer just mirroring what the platform provides)
does make it easier for the sender while making it harder for the
receiver – it creates “computational dark energy” that has to be
consumed somehow at the receiving side, as someone has to map all of
these platform-specific conventions onto common semantics.

I rather not have a world in which one needs even more JavaScript blobs
just to provide basic functionality cross-browser.

 That said, I'm not convinced this is an issue given the primary
 use-case, which is pretty much that web content wants to do more
 sophisticated things with the metadata than the user-agent's
 standardized parsing allows. If one cares to that extent, and is
 already handling format differences, dealing with vendor variation on
 top isn't that much more effort.

I disagree, strongly.

-- 
Nils Dagsson Moskopp // erlehmann
http://dieweltistgarnichtso.net

Re: [whatwg] metadata attribute for media

[Ralph Giles]

On 12-12-11 5:23 PM, Ralph Giles wrote:

 That said, I'm not convinced this is an issue given the primary
 use-case, which is pretty much that web content wants to do more
 sophisticated things with the metadata than the user-agent's
 standardized parsing allows. If one cares to that extent, and is already
 handling format differences, dealing with vendor variation on top isn't
 that much more effort.

Robert O'Callahan argued (off-list) that there is a significant
difference. Exposing what the media framework supplies for metadata,
multiplies the established format fragmentation by per-platform
differences. That's  not something we want to do if we can avoid it, and
we can avoid it by doing our own tag normalization as part of the
exposed API.

We feel that's more important than the extended and custom tag use case,
which is still addressible by direct parsing in javascript, etc.

I don't intend to continue with implementation of the raw metadata api,
and instead will focus on mapping everthing to a standard set of
attributes. To that proposal I've added a 'tracknumber' attribute since
this is imporant for sorting resources in media player applications.

interface Metadata {
  readonly attribute DOMString title;
  readonly attribute DOMString artist;
  readonly attribute DOMString album;
  readonly attribute long tracknumber;
  readonly attribute Blob? artwork;
};

partial interface MediaElement {
  Metadata metadata;
};

 -r

Re: [whatwg] metadata attribute for media

[Robert O'Callahan]

On Wed, Dec 12, 2012 at 2:23 PM, Ralph Giles gi...@mozilla.com wrote:

 That said, I'm not convinced this is an issue given the primary
 use-case, which is pretty much that web content wants to do more
 sophisticated things with the metadata than the user-agent's
 standardized parsing allows. If one cares to that extent, and is already
 handling format differences, dealing with vendor variation on top isn't
 that much more effort.


I disagree. Vendors proliferate more than formats. A Web application may
well have some knowledge about the formats of its resources, but we don't
want to bind it to particular platforms or UAs.

Rob
-- 
Jesus called them together and said, “You know that the rulers of the
Gentiles lord it over them, and their high officials exercise authority
over them. Not so with you. Instead, whoever wants to become great among
you must be your servant, and whoever wants to be first must be your
slave — just
as the Son of Man did not come to be served, but to serve, and to give his
life as a ransom for many.” [Matthew 20:25-28]

Re: [whatwg] metadata attribute for media

[Ian Hickson]

On Thu, 20 Sep 2012, Ralph Giles wrote:

 Back in June, I proposed[1] a new attribute to get metadata tag data 
 out of media resources.
 
 I've done an experimental implementation of this which is now in the 
 Firefox Aurora (alpha) channel[2] and Nightly development builds.
 
 The method is media.mozGetMetadata() and it returns a new object each 
 time, whose properties are key:value pairs representing the metadata 
 tags from the file. Aurora supports this for Ogg Vorbis (.ogg) streams. 
 Nightly supports Opus (.opus) files as well.
 
 Right now the method returns whatever set of tags happen to be in the 
 media stream, at least if they can be interpreted as unicode text. There 
 are several things I'd like to fix about this. Media formats generally 
 have rules about how to map various tags to a standard vocabulary. Right 
 now, web content has to implement those rules, but the user-agent is in 
 a better position to do so.
 
 Also, a number of Mozilla (C++) developers I've talked to prefer a fixed 
 schema for metadata, rather than the more dynamic approach.
 
 So, I'd like to do a new method which returns an object with a fixed 
 schema we can describe in idl, representing standard fields derived from 
 the dublic core tag set. The raw metadata would be available under the 
 old method for advanced applications.
 
 Some metadata is also per-track, rather than per-stream, so it makes 
 sense to have these calls available on track objects as well as media 
 objects.
 
 The most essential tags are dc:creator and dc:title. That covers almost 
 all player use cases. For per-track metadata, the language is perhaps 
 also useful for selection purposes. Are there any other tags folks would 
 like to see in the initial proposal?

 [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-June/036352.html
 [2] available from aurora.mozilla.org

This seems reasonable. If there's implementor interest from other vendors, 
and if there's a spec that I can point to for how to get the metadata out 
of the various formats, then I'd be happy to add it to the spec.

I don't want to be the one to maintain the mapping from media formats to 
metadata schema, because this isn't my area of expertise, and it isn't 
trivial work.

I don't think we should have an open-ended API without fixed names, 
because that is a recipe for an interoperability disaster. We'd just end 
up having to define the mapping later when major yet poorly-tested sites 
started depending on particular mappings of popular UAs.


On Mon, 26 Nov 2012, Ralph Giles wrote:
 On 12-09-27 1:44 AM, Philip Jägenstedt wrote:
 
  I'm skeptical that all that we want from ID3v2 or common VorbisComment 
  tags can be mapped to Dublin Core, it seems better to define mappings 
  directly from the underlying format to the WebIDL interface.
 
 You're right.

Indeed.


  Given the open-endedness of metadata contained in actual media 
  resources, I'm personally a bit skeptical that there's something we 
  could add to the Web platform that would be better than just letting 
  authors pass that metadata out-of-band using any representation they 
  like, but what use cases are you trying to cover here?
 
 Two use cases I'm trying to address:
 
 - A web application presents some view of a media library. If the libray 
 resides on a server, then yes, the server-side component of the app can 
 parse, cache, and deliver the metadata out-of-band. But the library 
 could also be local, in which case the webapp must do its own parsing, 
 e.g. from a list of blob urls returned by the file api.
 
 - An author wants to display the embedded track title and artist name 
 with simple scripting on a webpage.

For music in particular this seems reasonable.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] metadata attribute for media

[Ralph Giles]

On 12-12-11 4:58 PM, Ian Hickson wrote:

 This seems reasonable.

Thanks for the feedback. Anyone else? :-)

 I don't want to be the one to maintain the mapping from media formats to 
 metadata schema, because this isn't my area of expertise, and it isn't 
 trivial work.

Good point. This would need to be standardized for the fixed-schema
proposal, at least for the formats commonly supported by the HTML media
element. The Web Ontology working group has done some work here, as
Silvia mentioned.

 I don't think we should have an open-ended API without fixed names, 
 because that is a recipe for an interoperability disaster.

I agree it would have interoperability issues. My own implementation
experience is that the easy thing to do is to mirror whatever
representation your playback framework offers, which can result in
per-platform differences as well as per-media-format (and per tagging
application, etc.).

That said, I'm not convinced this is an issue given the primary
use-case, which is pretty much that web content wants to do more
sophisticated things with the metadata than the user-agent's
standardized parsing allows. If one cares to that extent, and is already
handling format differences, dealing with vendor variation on top isn't
that much more effort.

We could say that user-agents should represent the metadata dictionaries
as directly as possible, and to match the tag names from the schema spec
when that's not possible.

 -r

Re: [whatwg] metadata attribute for media

[Ralph Giles]

On 12-11-26 4:18 PM, Ralph Giles wrote:

 interface HTMLMediaElement {
   ...
   object getMetadata();
 };
 
 After the metadataloaded event fires, this method would return a new
 object containing a copy of the metadata read from the resource, in
 whatever format the decoder implementation supplies. It would be up to
 the caller to do any semantic interpretation. The same method should be
 present on AudioTrack, VideoTrack, (TextTrack?) and Image elements.

The prefixed version of this in Firefox is documented in the 'Methods'
section of https://developer.mozilla.org/en-US/docs/DOM/HTMLMediaElement

 -r

Re: [whatwg] metadata attribute for media

[Ralph Giles]

On 12-09-27 1:44 AM, Philip Jägenstedt wrote:

 I'm skeptical that all that we want from ID3v2 or common VorbisComment
 tags can be mapped to Dublin Core, it seems better to define mappings
 directly from the underlying format to the WebIDL interface.

You're right.

 Given the open-endedness of metadata contained in actual media
 resources, I'm personally a bit skeptical that there's something we
 could add to the Web platform that would be better than just letting
 authors pass that metadata out-of-band using any representation they
 like, but what use cases are you trying to cover here?

Two use cases I'm trying to address:

- A web application presents some view of a media library. If the libray
resides on a server, then yes, the server-side component of the app can
parse, cache, and deliver the metadata out-of-band. But the library
could also be local, in which case the webapp must do its own parsing,
e.g. from a list of blob urls returned by the file api.

- An author wants to display the embedded track title and artist name
with simple scripting on a webpage.

One of the goals of html media was to make video and audio as simple to
include as images. User agents are generally parsing this metadata
anyway; exposing it is straightforward, and greatly simplifies the two
tasks above.

In any case, the media.mozGetMetadata() method I described earlier is
available in Firefox 17, released last week, with support for Vorbis
tags in .ogg files. Firefox 18, now in beta, adds support for .opus
files as well. Here's an example:

  https://people.xiph.org/~giles/2012/metadata.html

You should see 'Title', 'Album', etc. below the controls if your browser
supports mozGetMetadata().

We're continuing to implement this interface for other formats we support.

I still think it's useful to define both this 'raw' metadata interface,
returning just the data out of the file, and a more structured metadata
object with standardized tag names. I've left off implementing the
second one for lack of feedback on what the basic tags should be, and
how useful they are. There certainly wasn't consensus here.

So, what do you think of these two proposals:

1. Define the 'raw' getMetadata method in an unprefixed form:

interface HTMLMediaElement {
  ...
  object getMetadata();
};

After the metadataloaded event fires, this method would return a new
object containing a copy of the metadata read from the resource, in
whatever format the decoder implementation supplies. It would be up to
the caller to do any semantic interpretation. The same method should be
present on AudioTrack, VideoTrack, (TextTrack?) and Image elements.

2. Define a parsed metadata attribute with some standard tags:

interface Metadata {
  readonly attribute DOMString title;
  readonly attribute DOMString artist;
  readonly attribute DOMString album;
  readonly attribute Blob? artwork;
};

interface MediaElement {
  ...
  Metadata metadata;
};

So you could say something as simple as

  img.src = audio.metadata.artwork;

to display the cover art embedded in a download single. DOMString
attributes would have the value of an empty string if the underlying
data isn't available. These four attributes are the absolute minimum, I
think, for the use cases above. More could be added later as usage of
the api evolves. For example: date, publisher, tracknumber, tracktotal,
description, genre, sort-artist, sort-title, copyright, license, url.

If having both media.getMetadata() (raw) and media.metadata is
confusing, the first proposal could be named media.getRawMetadata() as well.

Does it make sense to include more technical metadata here? For example:
samplerate, channels, duration, width, height, framerate, aspect-ratio.
Firefox currently has prefixed properties for the number of channels and
the audio sample rate, and including these in the metadata interface
would let us deprecate the prefixed versions. On the other hand,
properties like duration, width, and height are available directly on
media elements today, so maybe it makes more sense to do the same for
the others.

In that case, do we want the indirection of the Metadata inferface?
Saying 'video.title' or 'img.src = audio.artwork' instead is shorter.

Feedback welcome,
 -r

Re: [whatwg] metadata attribute for media

[Philip Jägenstedt]

On Fri, 21 Sep 2012 01:32:19 +0200, Ralph Giles gi...@mozilla.com wrote:


Back in June, I proposed[1] a new attribute to get metadata tag data
out of media resources.

I've done an experimental implementation of this which is now in the
Firefox Aurora (alpha) channel[2] and Nightly development builds.

The method is media.mozGetMetadata() and it returns a new object each
time, whose properties are key:value pairs representing the metadata
tags from the file. Aurora supports this for Ogg Vorbis (.ogg) streams.
Nightly supports Opus (.opus) files as well.

Right now the method returns whatever set of tags happen to be in the
media stream, at least if they can be interpreted as unicode text. There
are several things I'd like to fix about this. Media formats generally
have rules about how to map various tags to a standard vocabulary. Right
now, web content has to implement those rules, but the user-agent is in
a better position to do so.

Also, a number of Mozilla (C++) developers I've talked to prefer a fixed
schema for metadata, rather than the more dynamic approach.

So, I'd like to do a new method which returns an object with a fixed
schema we can describe in idl, representing standard fields derived from
the dublic core tag set. The raw metadata would be available under the
old method for advanced applications.

Some metadata is also per-track, rather than per-stream, so it makes
sense to have these calls available on track objects as well as media
objects.

The most essential tags are dc:creator and dc:title. That covers almost
all player use cases. For per-track metadata, the language is perhaps
also useful for selection purposes. Are there any other tags folks would
like to see in the initial proposal?


I'm skeptical that all that we want from ID3v2 or common VorbisComment  
tags can be mapped to Dublin Core, it seems better to define mappings  
directly from the underlying format to the WebIDL interface. As an  
example, the MusicBrainz schema has both a track artist (e.g. Queen feat.  
George Michael) and an album artist (e.g. Queen) and two kinds of  
titles (track title and recording title) which doesn't seem to benefit  
from being passed through dc:creator and dc:title.


Given the open-endedness of metadata contained in actual media resources,  
I'm personally a bit skeptical that there's something we could add to the  
Web platform that would be better than just letting authors pass that  
metadata out-of-band using any representation they like, but what use  
cases are you trying to cover here?


--
Philip Jägenstedt
Core Developer
Opera Software

[whatwg] metadata attribute for media

[Ralph Giles]

Recently, we've been considering adding a 'tags' or 'metadata' attribute
to HTML media elements in Firefox, to allow webcontent access to
metadata from the playing media resource. In particular we're interested
in tag data like creator, title, date, and so on.

My recollection is that this has been discussed a number of times in the
past, but there was never suffient motivation to support the interface.
Our particular motivation here is webapps that present a media file
library. While it's certainly possible to parse the tag data out
directly with javascript, it's more convenient if the HTML media element
does so, and the underlying platform decoder libraries usually provide
this data already.

As such I wanted to raise the issue here and get design feedback and
levels of interest for other user agents.

Here's a first idea:

partial interface HTMLMediaElement {
  readonly attribute object tags;
};

Accessing media.tags provides an object with a key: value data, for example:

{
  'title': 'My Movie',
  'creator': 'This User',
  'date': '2012-06-18',
  'license': 'http://creativecommons.org/licenses/by-nc-sa/'
}

The keys may need to be filtered, since the files can contain things
like base64-encoded cover art, which makes the object prohibitively
large. The keys may need to be mapped to some standard scheme (i.e.
dublic core) since vocabularies vary from format to format.

This is nice because it's easy to access, can be simply enumerated,
and extensible. Which is helpful when if gets added the img for exif data.

 -r

Re: [whatwg] metadata attribute for media

[Silvia Pfeiffer]

On Tue, Jun 12, 2012 at 7:53 AM, Ralph Giles gi...@mozilla.com wrote:
 Recently, we've been considering adding a 'tags' or 'metadata' attribute
 to HTML media elements in Firefox, to allow webcontent access to
 metadata from the playing media resource. In particular we're interested
 in tag data like creator, title, date, and so on.

 My recollection is that this has been discussed a number of times in the
 past, but there was never suffient motivation to support the interface.
 Our particular motivation here is webapps that present a media file
 library. While it's certainly possible to parse the tag data out
 directly with javascript, it's more convenient if the HTML media element
 does so, and the underlying platform decoder libraries usually provide
 this data already.

 As such I wanted to raise the issue here and get design feedback and
 levels of interest for other user agents.

 Here's a first idea:

 partial interface HTMLMediaElement {
  readonly attribute object tags;
 };

 Accessing media.tags provides an object with a key: value data, for example:

 {
  'title': 'My Movie',
  'creator': 'This User',
  'date': '2012-06-18',
  'license': 'http://creativecommons.org/licenses/by-nc-sa/'
 }

 The keys may need to be filtered, since the files can contain things
 like base64-encoded cover art, which makes the object prohibitively
 large. The keys may need to be mapped to some standard scheme (i.e.
 dublic core) since vocabularies vary from format to format.

 This is nice because it's easy to access, can be simply enumerated,
 and extensible. Which is helpful when if gets added the img for exif data.


Did you know that the W3C media annotations WG has specified such an
API in http://www.w3.org/TR/2011/WD-mediaont-api-1.0-2022/#api-description
. Essentially, their suggestion is to add the following IDL functions:

void getMediaProperty (DOMString[] propertyNames, PropertyCallback
successCallback, ErrorCallback errorCallback, optional DOMString
fragment, optional DOMString sourceFormat, optional DOMString
language);

void getOriginalMetadata (DOMString sourceFormat, MetadataCallback
successCallback, ErrorCallback errorCallback);


I actually think their API is too complicated and prefer your simple
approach. Returning a JSON object also allows hierarchical tags to be
returned in a structured way, which is nice. You lose the
normalisation that the W3C media ann WG has worked on across different
media resources, but that normalisation can always be done on top of
the JSON objects that your API returns.


Cheers,
Silvia.