AW: [mawg] reviewing ID3v2

Dear Joakim, Pierre-Antoine, all,

we discussed at the Stockholm F2F about the technical properties to be included. There is some redundancy between the properties duration, bit rate and file size. We defined bit rate as the average bit rate, so you could get an approximate size in case of VBR.

One reasons for not including size were that it does not apply to fragments, while the other two properties do. I also believe that Dave was in favour of having bit rate instead of file size w.r.t. streaming media.

We can nonetheless decide to add file size, but looking at it more globally, there are many properties in many formats that might be useful in some cases but cannot be mapped to ma:* - that's inevitable when defining a small set of properties.

Best regards,
Werner


________________________________________
Von: public-media-annotation-request@w3.org [public-media-annotation-request@w3.org] im Auftrag von Pierre-Antoine [pierre-antoine.champin@liris.cnrs.fr]
Gesendet: Montag, 07. Dezember 2009 10:25
An: Joakim Söderberg
Cc: public-media-annotation@w3.org
Betreff: Re: [mawg]  reviewing ID3v2

Le 06/12/2009 19:47, Joakim Söderberg a écrit :
> Hello,
>
> While reviewing ID3v2 I couldn't find "samplingrate" in the spec (to
> match: ma: samplingrate). However there is “TSIZ” that contain the size
> of the audio file in number of bytes, but we don’t have an attribute for
> that.

Indeed, we don't. It was so obvious that it seems nobody noticed its
absence ;-)

+1 to add this property.

> So how do we deal with this?

Re dealing with the absence of ma: property for the file size, I suggest
adding it.

Re dealing with the absence of ID3 property for the samplingrate, well,
let it be... This information is not present in that format, so we can
not return it if the sole source of metadata is ID3.

> There is no way to get the size of an
> ID3 file! – Not directly or via the samplingrate and duration.

Since sampling rates can, in principle, be VBR, even this method can not
always give a result. The goal of the API is to provie unified access to
the *available* underlying metadata. Although implementors may choose to
be smart and try to infer additional information from what is available,
I think it is out of our scope to specify how this could be done.

  pa

Received on Monday, 7 December 2009 09:52:22 UTC