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