[ID3 Dev] id3v2.4 & frame sizes?

[Pyt]

Yes your description of what the synch-safe size should look like is
correct.

However, I remember seeing a discussion on this very list about how bad the
ITunes v2.4 implementation was, and in particular, that it did *not*
implement synch-safe frame sizes... And also somebody mentioning the exact
same algorithm that you describe: first try the synch-safe size and see if
it makes sense (e.g., if the following data looks like a new frame), then
try the non synch-safe size, then declare the frame corrupt.

The problem is that even if a synch-safe integer as 0 as most significant
bit for each bytes, not everything that exhibits this pattern is a
synch-safe integer. So trial and error is the only thing that's got a chance
to work, although in some rare cases it might fail (e.g., false detection of
a valid frame).

Regards,
Pyt.


On 1/15/06, Jonathan del Strother <maillist at steelskies.com> wrote:
>
> I'm seeing a couple of MP3s that don't have synch-safe frame sizes,
> and wanted to check that I'm reading the specification right.  For
> v2.4, all frame sizes should have a 0 at the start of each byte, right?
>
> I'm pretty sure that's correct, but I tried persuading iTunes to
> convert the tag to 2.3 and then back to 2.4, and the frame size
> remains non-synch-safe - I'm a little surprised that iTunes doesn't
> fix it.
>
>
> Any idea how common a problem this is?  I'm tempted to read the size
> as a non-synch-safe integer, and see if that offset then lands me on
> what looks like a new frame id.  Or is that a horribly bad idea?
>
> Thanks,
> Jon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20060116/1bf15690/attachment.html>