[Bug 25354] [DataCue] data attribute should be ArrayBuffer?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25354

--- Comment #6 from Eric Carlson <eric.carlson@apple.com> ---
(In reply to Aaron Colwell from comment #5)
> (In reply to Eric Carlson from comment #4)
> > (In reply to Aaron Colwell from comment #3)
> > > (In reply to Brendan Long from comment #2)
> > > > I think the idea is that we would generally provide either .data or .value,
> > > > but if a UA gains the ability to parse the data and adds .value, it should
> > > > continue providing .data if possible to avoid breaking existing applications.
> > > > 
> > > > I'm not opposed to splitting this into two different cue types if the
> > > > consensus is that that's better though. For Apple's use-cases, we might want
> > > > to start by defining an ID3Cue (or maybe more generically named, since
> > > > name/value pairs are a common kind of metadata).
> > > 
> > > For known well defined things like ID3 I think it is better to define and
> > > expose an ID3Cue instead of using something generic like DataCue. I would be
> > > interested in participating in the discussion around exposing ID3 data via
> > > an ID3Cue.
> > 
> > I wouldn't necessarily call ID3 a "well defined" format. An ID3 metadata
> > item has a key and a value, and while you can infer the value's data type
> > from the key in reality it can be anything at all.
> 
> Fair enough, but certain keys have particular meanings when considered in
> the ID3 context. It is pretty straightforward to define what an ID3Cue would
> look like and applications would know how to handle these key/value pairs
> when it received an ID3Cue.
>  

ID3 metadata values can be text, an image ("APIC") with optional MIME type, a
defined structure (eg. "POPM", "AENC", etc), a number (eg. "PCNT"), or
arbitrary binary data (GEOB) with optional MIME type. 

It seems to me that will require an ID3Cue attribute(s) to provide at least
String, Object, and ArrayBuffer values. This is exactly what Ted is suggesting.

> > 
> > ID3 is not the only metadata format with *exactly* these characteristics
> > (eg. QuickTime, MPEG-4, MPEG-7, etc). Are you really suggesting that we
> > create different Cue types for every one?
> 
> It depends on which problem we are trying to solve. 

I think we are trying to provide script access to arbitrary metadata carried in
media files. Nothing more.

If we are trying to
> solve the "How do I get song title, track, album data out for any media
> type?", then it would probably make sense to have a specific cue type for
> this and define mappings from all those formats into specific attributes. If
> we are trying to solve the "Just expose the raw metadata in the underlying
> format" then I think something like format specific cues or the combination
> of TextTrack.inBandMetadataTrackDispatchType and DataCue w/ nothing but a
> .data attribute is sufficient. I think any of these paths are easier to
> reason about than sequences of DataCue<type, data>, DataCue<type, data,
> value>, or DataCue<type, value>.

http://id3.org/id3v2.4.0-frames defines more than 40 keys for "text" values
alone. Do you suggest we define key names for all of them? 

We will have to have an escape mechanism for unknown keys, why not just use the
ID3 keys as-is?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 16 April 2014 18:44:53 UTC