<html>
<body>
Hi Scott,<br><br>
Many thanks for your comments.<br><br>
<blockquote type=cite class=cite cite="">On Monday 12 June 2006 4:09, Dan
O'Neill wrote:<br>
> Chris Newell's proposal for an Accessibility frame has been
posted.</blockquote><br>
snip...<br><br>
<blockquote type=cite class=cite cite="">Two things that jump out to me
as bits that won't work:<br><br>
- You can't embed arbitrary audio into an ID3 tag and expect for it to be
<br>
decoded properly since it messes up synching. For instance, with
MPEG audio, <br>
when you hit an MPEG synch frame, the audio player will just play the
stuff <br>
there like it's the first bit of audio content. The rest of the tag
will be <br>
ignored.</blockquote><br>
I discovered this to my cost when trying out a prototype:-) However,
using the ID3v2 unsynchronisation scheme appeared to solve this.<br><br>
The draft proposal recommends that unsynchronisation is applied but
perhaps this should be a mandatory if AudioText frames are
present.<br><br>
<blockquote type=cite class=cite cite="">- Equivalent Frame ID doesn't
work for frames that allow multiple instances of <br>
the same frame.</blockquote><br>
Couldn't you use multiple instances of AudioText frame with the same
Equivalent Frame ID?<br><br>
It's true that in the current proposal you cannot assume a one-to-one
relationship between a specific text frame and a specific AudioText frame
if there are multiple instances with the same Equivalent Frame ID and
language code.<br><br>
Would a satisfactory solution be to imply this relationship (if required)
from the order in which they are found within the frame?<br><br>
<blockquote type=cite class=cite cite="">You also might want to consider
if you want to do anything <br>
special for frames that contain multiple, distinct
strings.</blockquote><br>
I had a hard think about this before coming up with the simple solution
provided for frames like the COMM frame. My conclusion was that multiple
audio clips were not necessarily helpful to the client user interface so
the additional complexity might not be worthwhile.<br><br>
<blockquote type=cite class=cite cite="">(I must say that I'm somewhat
sceptical of the uses of the extension in <br>
general, vs., say, screen readers, but I'll take the time to read the
paper <br>
you just sent later on.)</blockquote><br>
The paper does give a rationale for the proposed approach compared to the
use of Computer Generated Speech.<br><br>
My view (and I'd be happy to be proved wrong) is that producing good
Computer Generated Speech on low profile devices like MP3 players is
quite hard whereas the implementation of AudioText frames is really
simple.<br><br>
Chris<br>
</body>
<br>
<body>
<font face="Times New Roman, Times">
____________________________________________</font> <br><br>
<font face="Verdana" size=2><b>Chris Newell</b></font> <br>
<font face="Verdana" size=1 color="#808080"><b>Lead
Technologist</b></font><font color="#808080"> <br>
</font><font face="Verdana" size=1 color="#808080"><b>Technology
Group<br>
BBC New Media & Technology<br>
Kingswood Warren, Woodland Way, Tadworth<br>
Surrey<x-tab> </x-tab>KT20 6NP UK<br><br>
Tel:<x-tab> </x-tab>+44 (0)1737 839659<br>
Fax:<x-tab> </x-tab>+44 (0)1737 839665<br>
<a href="mailto:chris.newell@rd.bbc.co.uk" eudora="autourl">
mailto:chris.newell@rd.bbc.co.uk<br>
</a></font><font size=2> </b></font> </body>
</html>