[ID3 Dev] ID3v2.4 Unsynchronisation

[Jud White]

That's my interpretation.  I would certainly say these 3 scenarios are valid.

If an unsync tag header bit is set, I would read all tags as unsync since most likely the writer just ignored setting the new bit in the frame header, but knew to set the tag header (a la 2.3).

This is good information to add to the clarification wikis.  Hope someone authoritative can chime in.  Jim's suggestion (which is probably implicitly required by the spec, or is at least a best practice) in another post about not writing footers to prepended tags, and hopefully some clarification to ATXT, CHAP, CTOC can be incorporated soon.

----- Original Message -----
From: Michal Vician [mailto:id3v2 at audiott.com]
To: id3v2 at id3.org
Sent: Fri, 12 Jan 2007 21:48:55 +0100
Subject: Re: [ID3 Dev] ID3v2.4 Unsynchronisation

So you say that there are only three situations as far as we talk about 
ID3v2.4 ? :

   1. no frame was affected by unsynchronisation (all sync bits are _not
      set_)
   2. only few frames were affected (only bits of affected frames are
      _set_, header sync bit is _not set_)
   3. all frames were affected (header sync bit and sync bits of all
      frames are _set_)



Jud White wrote:
> I would say no, it's not valid based on the following:
>
> a - Unsynchronisation
>
>      Bit 7 in the 'ID3v2 flags' indicates whether or not
>      unsynchronisation is applied on all frames (see section 6.1 for
>      details); a set bit indicates usage.
>
> and, from the quote below:
>
> "This bit MUST be set if the frame was altered by the unsynchronisation"
>
> For writing I would use both if all frames were subject to unsynchronisation.  My guess is that others readers are more likely to respect to unsync bit in the tag header than the frame header, so I would do all or nothing.  Just a guess based on the likeliness that most 2.4 implementations stemmed from 2.3.
>
> For reading I would take an extra cautious approach when reading unsync'd tags since sometimes they're really unsync'd and sometimes they're not.  For APIC this is easy - validate the image, if it's bad, try reading the frame normally.
>
> Jud
>
> ----- Original Message -----
> From: Michal Vician [mailto:id3v2 at audiott.com]
> To: id3v2 at id3.org
> Sent: Fri, 12 Jan 2007 20:12:26 +0100
> Subject: [ID3 Dev] ID3v2.4 Unsynchronisation
>
> Hi again,
>
> I have a question concerning the unsynchronisation of ID3v2.4 tag.
> In the specification is stated the following:
>
>    To indicate usage of the unsynchronisation, the unsynchronisation
>    flag in the frame header should be set. This bit MUST be set if the
>    frame was altered by the unsynchronisation and SHOULD NOT be set if
>    unaltered. If all frames in the tag are unsynchronised the
>    unsynchronisation flag in the tag header SHOULD be set. It MUST NOT
>    be set if the tag has a frame which is not unsynchronised.
>
> OK, I understand. This means, that if whole tag is unsynchronized, the 
> header "unsynchronization flag" is set and also "unsynchronization 
> flags" of all frames are set. But, I am not sure if the situation can 
> happen that header "unsynchronization flag" is set and 
> "unsynchronization flags" of all frames are NOT SET. Is such situation 
> valid in ID3v2.4?
>
> Regards,
> Miso


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