[prev in list] [next in list] [prev in thread] [next in thread] 

List:       taglib-devel
Subject:    Re: [patch] fix zero length ID3v2 frames
From:       Sergey Vlasov <vsu () altlinux ! ru>
Date:       2007-01-22 14:09:48
Message-ID: 20070122140948.GA6955 () procyon ! home
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 04 Sep 2005 21:55, Scott Wheeler wrote:
> On Wednesday 31 August 2005 12:27, Andrew de Quincey wrote:
> > Hi, I had a couple of mp3 files that taglib just ignored the ID3 contents
> > of. Turns out they have several 0 length frames in them.

I also encountered several such files, and taglib-1.4 behavior is
still the same - it ignores all ID3 information after the first zero
length frame.

> > The attached patch makes taglib ignore any zero length frames completely,
> > while still parsing other frames correctly. I thought this would be more
> > fault tolerant than just attempting to parse them as normal frames - e.g.
> > in case we find a 0 length text frame, which would be quite invalid (no
> > text encoding information).

I have found the patch in the list archive:
http://lists.kde.org/?l=taglib-devel&m=112548404607073&w=2

The patch still applies to taglib-1.4 and works.

> I'm not quite sure on this one -- the frames will definitely need to
> be discarded since per the ID3v2 spec frames are required to contain
> at least one byte of information.
> 
> The remaining question is what to do when broken frames are
> encountered.  I'll probably apply some version of this,

Looks like the patch was forgotten...

> but there's still a case that worries me:
> 
> There's no offset table for frames in ID3v2, so you have to iterate
> through them when parsing.  When frames have invalid values they're
> often just wrong -- i.e. it might say "0" and then actual content
> follows.  That throws off the rest of the parsing and can cause some
> strange errors...

The same will happen if the length is not 0, but is corrupted - so
this should not be a problem for ignoring zero length frames.

Or did you really encounter some files which have zero length frames
with garbage after them?

["signature.asc" (application/pgp-signature)]

_______________________________________________
taglib-devel mailing list
taglib-devel@kde.org
https://mail.kde.org/mailman/listinfo/taglib-devel


[prev in list] [next in list] [prev in thread] [next in thread]