[ID3 Dev] Unsynchronization for Dummies

Mathias Kunter mathiaskunter at yahoo.de
Thu Aug 12 06:47:56 PDT 2010


> What confused me was that the spec of 2.4 states that
> the frame header includes the size after unsynchronization.

Yes, that's correct. The frame size is always meant as "frame size within the 
source data stream" - otherwise you couldn't skip a frame without decoding it.

> So if a tag has unsynchronization
> turned off, but the tag turned on, the frame size includes the size
> after unsynchronization.

I guess you meant "but the FRAME turned on". Well, if a frame has been 
unsynchronisated, then the frame size *always* is the size after the 
unsynchronisation.

Regarding the unsynchronisation flags:

Set the FRAME unsynchronisation flag ONLY if the frame data has been altered by 
the unsynchronisation. The frame data often isn't changed by the 
unsynchronisation. Don't set the flag in this case, your tags will be more 
compatible with other ID3 implementations.

Set the TAG unsynchronisation flag ONLY if ALL of your frames have a set 
unsynchronisation flag. This should happen rarely, at least when using the 
default ISO-8859-1 text encoding (Unicode BOM's can require unsynchronisation 
more often, but that's a different story).

I hope this helps.

Mathias Kunter





________________________________
Von: Matthias Mayrock <mail at mroc.de>
An: id3v2 at id3.org
Gesendet: Montag, den 9. August 2010, 19:14:06 Uhr
Betreff: Re: [ID3 Dev] Unsynchronization for Dummies

  Hi Peter,

thank you for your reply. I will follow your advice and try to
not write synchronized tags at all.

Nevertheless I'll want to support the feature and I think I got
it now. What confused me was that the spec of 2.4 states that
the frame header includes the size after unsynchronization.

If I understand this correctly it is only the case if the whole tag
has unsynchronization turned off but a frame turned it on. This
would at least make sense to me. So if a tag has unsynchronization
turned off, but the tag turned on, the frame size includes the size
after unsynchronization.

thank you very much and best wishes,

matthias mayrock



Am 8/8/2010 5:34 PM, schrieb Peter Bennett:
> Hi Matthias
>
> I recommend against writing Unsynchronized  frames. Players do not 
> need them these days, and one version of Windows media player would 
> not play an mp3 file file if the tag had unsynchronized frames. My 
> method is to be able to read unsynchronized frames but not to write them.
>
> Peter Bennett
>
> On 8/6/2010 1:56 PM, Matthias Mayrock wrote:
>>  Hi There,
>>
>> Sorry I ask this dumb question but the unchronization,
>> to get it right, when writing v2.0-2.4, works like this:
>>
>> 1) Write frame data
>> 2) Insert unsynchronization zeros into frame data
>> 3) Take new frame data length and put into frame header
>>
>> So the frame header contains the size of frame content
>> after inserted zeros, right?
>>
>> Thanks for any answer and best wishes,
>>
>> matthias mayrock
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> For additional commands, e-mail: id3v2-help at id3.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20100812/d8fd0af5/attachment.html>


More information about the ID3v2 mailing list