On Tue, 30 Jan 2018 13:43:25 +0100
wm4 wrote:
> The ID3v2 "unsynchronization scheme" requires replacing any 0xFF 0x00
> sequences with 0xFF. This has to be done on every byte of the source
> data, while the current code skipped a byte after a replacement. This
> meant 0xFF 0x00 0xFF 00 was transl
On Wed, 31 Jan 2018 11:34:27 +0100
Michael Niedermayer wrote:
> On Tue, Jan 30, 2018 at 01:43:25PM +0100, wm4 wrote:
> > The ID3v2 "unsynchronization scheme" requires replacing any 0xFF 0x00
> > sequences with 0xFF. This has to be done on every byte of the source
> > data, while the current code
On Tue, Jan 30, 2018 at 01:43:25PM +0100, wm4 wrote:
> The ID3v2 "unsynchronization scheme" requires replacing any 0xFF 0x00
> sequences with 0xFF. This has to be done on every byte of the source
> data, while the current code skipped a byte after a replacement. This
> meant 0xFF 0x00 0xFF 00 was t
LGTM, for whatever my opinion is worth.
Also easier to follow than the old code.
-Richard
On Tue, Jan 30, 2018 at 4:47 AM, wm4 wrote:
> On Tue, 30 Jan 2018 13:43:25 +0100
> wm4 wrote:
>
>> The ID3v2 "unsynchronization scheme" requires replacing any 0xFF 0x00
>> sequences with 0xFF. This has to
On Tue, 30 Jan 2018 13:43:25 +0100
wm4 wrote:
> The ID3v2 "unsynchronization scheme" requires replacing any 0xFF 0x00
> sequences with 0xFF. This has to be done on every byte of the source
> data, while the current code skipped a byte after a replacement. This
> meant 0xFF 0x00 0xFF 00 was transl
The ID3v2 "unsynchronization scheme" requires replacing any 0xFF 0x00
sequences with 0xFF. This has to be done on every byte of the source
data, while the current code skipped a byte after a replacement. This
meant 0xFF 0x00 0xFF 00 was translated to 0xFF 0xFF 0x00 instead of 0xFF
0xFF. It feels a
