[ID3 Dev] Accessibilty extension draft is posted
Chris Newell
chris.newell at rd.bbc.co.uk
Wed Jun 21 08:06:53 PDT 2006
Scott,
At 15:23 16/06/2006, Scott Wheeler wrote:
>On Wednesday 14 June 2006 16:02, Chris Newell wrote:
>> >Two things that jump out to me as bits that won't work:
>> >
>> >- You can't embed arbitrary audio into an ID3 tag and expect for it to be
>> >decoded properly since it messes up synching. For instance, with MPEG
>> > audio, when you hit an MPEG synch frame, the audio player will just play
>> > the stuff there like it's the first bit of audio content. The rest of
>> > the tag will be ignored.
>>
>> I discovered this to my cost when trying out a prototype:-) However, using
>> the ID3v2 unsynchronisation scheme appeared to solve this.
>>
>> The draft proposal recommends that unsynchronisation is applied but perhaps
>> this should be a mandatory if AudioText frames are present.
>
>Unfortunately MPEG is the simple case. Granted, the primary target of ID3
>files is MPEG audio, but they are used for some other things (FLAC comes to
>mind). The absence of explicit unsynchronization for non-MPEG formats
>usually doesn't cause problems just because statistically it's not likely to
>accidentally have a properly formatted header. However, if you're
>intentionally putting them in there, it could be problematic.
I'd be happy for the proposal to state that it is only appropriate for file formats that are compatible with the ID3 unsynchronisation scheme. The problem space is too big otherwise.
>Also, speaking of synchs, the image in the draft shows a synch safe integer
>for the size, which would be really strange in an ID3v2.3 tag since they're
>not used there.
OK - as it's not explicitly stated to be an v2.4 tag it would be better to omit the "sync safe" label.
>> >- Equivalent Frame ID doesn't work for frames that allow multiple
>> > instances of the same frame.
>>
>> Couldn't you use multiple instances of AudioText frame with the same
>> Equivalent Frame ID?
>>
>> 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.
>>
>> Would a satisfactory solution be to imply this relationship (if required)
>> from the order in which they are found within the frame?
>
>There's no guarantee that external taggers don't reorder frames when they
>write tags, so a third party tool just updating the tag would break things.
OK. An alternative solution could be to include a "Description" field so that each AudioText frame is uniquely associated with an equivalent text frame by a combination of:
Frame ID
Language Code
Description
For frames where only one instance is permitted there is generally no "Description" field and therefore this would be set to $00.
>With all this I don't mean to be overly negative -- just kind of playing
>devil's advocate from an engineering perspective...
No problem, the scrutiny is appreciated.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org
More information about the ID3v2
mailing list