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

<div> </div>

<div>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.</div>

<div> </div>

<div>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).</div>

<div> </div>

<div>Regards,</div>

<div>Pyt.<br><br> </div>

<div><span class="gmail_quote">On 1/15/06, <b class="gmail_sendername">Jonathan del Strother</b> <<a href="mailto:maillist@steelskies.com">maillist@steelskies.com</a>> wrote:</span>

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">I'm seeing a couple of MP3s that don't have synch-safe frame sizes,<br>and wanted to check that I'm reading the specification right.  For

<br>v2.4, all frame sizes should have a 0 at the start of each byte, right?<br><br>I'm pretty sure that's correct, but I tried persuading iTunes to<br>convert the tag to 2.3 and then back to 2.4, and the frame size<br>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?

<br><br>Thanks,<br>Jon<br><br></blockquote></div><br>