[ID3 Dev] Moving forward on Chapter Frames

Chris Newell chris.newell at rd.bbc.co.uk
Fri Nov 25 08:11:37 PST 2005

At 06:12 22/11/2005, Pyt wrote:
>I've had initially the same problem with the new frames, but a very small modification of my library (which in not able to fully parse all frames, anyway) allowed me to take them in as binary (unparsed) frames, as long as the header is well-formed. 
>As far as the "sync" goes, in case of a corrupt frame, you can always:
>1. Check that the size of the frame is correct (there is another valid frame header or padding right after the frame)
>2. If not, go into detailed analysis of the file right after the corrupt frame, looking for a valid header pattern.
>It's not fool-proof, but it will work in most cases.
>On 11/22/05, Shiv Charan Panjeta <<mailto:shivcharan.p at samsung.com>shivcharan.p at samsung.com> wrote: 
>I am also facing the similar problem . if any of the frame is not understood
>.. I have to quite parsing. 
>Is it make sense to introduce  some sync mechanism like (MP3 frame) in
>future specs to recover the corrupted  frames.?

I think that any future version of the specification should include a statement that frames with an unrecognised Frame ID should ignored and skipped using the Size field. This would allow new frame types to be introduced in a backwards compatible manner.


Dr J.C. Newell
Digital Media Group, BBC Research & Development
Kingswood Warren, Woodland Way, Tadworth, Surrey 
KT20 6NP  UK
mailto:chris.newell at rd.bbc.co.uk      http://www.bbc.co.uk/rd
Tel:   +44 (0)1737 839659
Switchboard:   +44 1737 839500
Fax:  +44 (0)1737 839665

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