Re: [whatwg] <audio> metadata (re-mapping)

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 

People at Hydrogen audio have tried to remap these into something common
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
(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 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.

Received on Monday, 17 April 2017 12:21:12 UTC