AW: AW: [ID3 Dev] Purpose of Unsynchronization flag on ID3v24 tag header ?

[Paul Taylor]

Mathias Kunter wrote:
>> Is a frame unsynchronized IF it  doesnt contain FF FE patterns
>>     
>
> No. I don't know why you keep talking about the FF FE pattern, this has
> nothing to do with the unsync scheme. As Ben said, unsync is only relevant
> to a bit sequence of
>   
Sorry for the confusion I mean E0 I was just on autopilot, In understand 
the unsynchronization algorithm works
I have implemented it very successful for v22 and v23 tags quite some 
time ago.
> %11111111  (which is  ==  FF)
> %111xxxxx  (which is  >= E0)
>
> So, if you encounter this bit sequence within the data of a frame AND you
> decide to unsyc the frame, you HAVE to insert a 00 byte after the FF
> byte. You HAVE to set the frame header flag now.
>
> If you decide to don't unsync the frame content, do nothing. You MUST
> NOT set the frame header flag. This also implies that the tag header flag
> MUST NOT be set.
>
> If you don't detect the mentioned bit sequence, you can still decide to
> unsync the frame and set the flag in the frame header. However, this
> would be silly as the unsync would have no effect for this frame. It is
> just allowed from the specs point of view, but you shouldn't do that.
>
> It is safe to insert a 00 byte after every FF byte WHEN applying the
> unsync scheme. As Ben said, this may also inserts a 00 byte where
> not really nescessary, but it is easier to implement and also works
> fine because a decoder has to replace EVERY $FF $00 byte sequence.
>
>
>   
>> if you had a frame with a $FF $00 combination and you didnt unsynchronize
>> the frame, [...], and then a decoder tried to de-unsync the frame it would
>> remove the 00, and your data will be modified
>>     
>
> The point is, if I didn't unsync the frame, the flag is NOT set. Therefore, a
> decoder MUST NOT de-unsync the frame, of course. Therefore, it doesn't
> matter from the decoder point of view.
>
>   
Thanks for your help but we are still at cross purposes here though, 
this is what you said earlier

'Note that if a frame has been unsynced this doesn't mean that this frame actually got
modified. (Well, the specs say that the flag SHOULD only be set if the frame became
actually modified because of a false sync, but you can't rely on that).
So if the frame header flag is set it is guaranteed that this frame (or all frames, if the
tag header flag is set) contain no false sync signal in it. It does NOT mean that the
frame content actually became modified, as mentioned before. From the decoder
point of view, this doesn't matter anyway. Just de-unsync the frame by replacing all
$FF $00 byte sequences with $FF bytes.'

You say above the frame flag being set means 'it contains no false sync signal. It does NOT mean that the
frame content actually became modified'
 whereas in your latest post you say 'If you decide to don't unsync the frame content, do nothing. You MUST
NOT set the frame header flag.'

These two statements seem to be the opposite of each other
 
You also say
'If you don't detect the mentioned bit sequence, you can still decide to
unsync the frame and set the flag in the frame header. However, this
would be silly as the unsync would have no effect for this frame. It is
just allowed from the specs point of view, but you shouldn't do that.'

Wouldnt it? if  there were any FF 00 patterns there would be an effect. Replacing FF 00 with FF 00 00 is part of unsynchronization
(it is not optional)

> Hope it is clear now.
>
> Mathias
>
>
>
>
>
>
>
>
> 	
> 		
> ___________________________________________________________ 
> Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
>
> ---------------------------------------------------------------------
> 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