[ID3 Dev] Accessibilty extension draft is posted

[Scott Wheeler]

On Thursday 22 June 2006 11:07, you wrote:
> The original proposal was really intended for frames that carry human
> readable text strings as I didn't think it would be very useful to read out
> things like URLs.

Say it's a newscast from the BBC, would it not be useful to say, "news dot 
b-b-c dot home dot u-k"?

I'm just trying to think of this in systematic terms, not so much common-sense 
ones.  For the spec there would need to be, "Here are the places you can use 
this and here are the places you can't."  Ambiguity tends to come back to 
bite you...

> I see your point, although you can break most things with an authoring tool
> if you try hard enough!

Well, but this is just normal usage.  A user downloads a file, they decide 
that some part of the description is wrong and proceed to change it in their 
player of choice.

> I'm warming to the idea of a lookup table mapping strings to audio clips,
> since this would support any frame type and solves the multiple instance
> problem neatly. How about using a hash code approach to map strings to
> audio clips?

What would the hash be for?

If you mean to avoid string duplication, I think just duplicating the text 
would be easier to implement and easier to spec.  In terms of sizes, the text 
"Rolling Stones" including null termination is 15 bytes.  A two second, 96 
kb/s, 22050 kHz, mono mp3 is going to take around 5000 bytes.  Saving 7 bytes 
by using an 8 byte hash instead probably wouldn't be worth it, plus it'd make 
the files harder to read with a hex editor.  :-)

Cheers,

-Scott

-- 
We should forget about small efficiencies, say about 97% of the time: 
premature optimization is the root of all evil.
-Donald Knuth


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org