flac dev - Jul 2005 - [BUG] --sector-align zero padding is not entirely zero

Hi,

A user at the www.thetradersden.org website reported a difference when
fixing "sector boundary errors" in CD-quality WAV files with shntool
and
flac.  As as result of investigating this, I think I've found a bug in
the zero-ising of the buffer used to zero-pad the last file when
encoding with the --sector-align option.

My test consisted of the creation of four "non-aligned" CD quality WAV
files.  I then "fixed" these files using both the "shntool
fix" command
and the "flac --sector-align" command.

I then compared the WAV files created by shntool and the WAV files
created by uncompressing the FLAC files, and the MD5 checksums did not
match for the final track.

On comparing the contents of the WAV files, the "shntool" fixed
version
correctly contained 448 zero bytes at the end (112 samples).  However,
the FLAC version contained 224 zero bytes, followed by 224 non-zero bytes.

I've tracked the bug to the calculation of the number of bytes to fill
the input_ buffer with, which is calculated in line 778 of encode.c as
follows:

data_bytes = wide_samples * (bps >> 3);

However, my understanding is that the input_buffer is always an array of
32-bit integers, and therefore the calculation should always be:

data_bytes = wide_samples * 4;

The expression (bps >> 3) is also used elsewhere in encode.c so you may
wish to examine those instances as well for similar bugs.

Best wishes, and thanks for FLAC.

Dave

thanks, will take a look.

Josh

--- Dave Chapman <dave@dchapman.com> wrote:
> Hi,
> 
> A user at the www.thetradersden.org website reported a difference
> when
> fixing "sector boundary errors" in CD-quality WAV files with
shntool
> and
> flac.  As as result of investigating this, I think I've found a bug
> in
> the zero-ising of the buffer used to zero-pad the last file when
> encoding with the --sector-align option.
> 
> My test consisted of the creation of four "non-aligned" CD
quality
> WAV
> files.  I then "fixed" these files using both the "shntool
fix"
> command
> and the "flac --sector-align" command.
> 
> I then compared the WAV files created by shntool and the WAV files
> created by uncompressing the FLAC files, and the MD5 checksums did
> not
> match for the final track.
> 
> On comparing the contents of the WAV files, the "shntool" fixed
> version
> correctly contained 448 zero bytes at the end (112 samples). 
> However,
> the FLAC version contained 224 zero bytes, followed by 224 non-zero
> bytes.
> 
> I've tracked the bug to the calculation of the number of bytes to
> fill
> the input_ buffer with, which is calculated in line 778 of encode.c
> as
> follows:
> 
> data_bytes = wide_samples * (bps >> 3);
> 
> However, my understanding is that the input_buffer is always an array
> of
> 32-bit integers, and therefore the calculation should always be:
> 
> data_bytes = wide_samples * 4;
> 
> The expression (bps >> 3) is also used elsewhere in encode.c so you
> may
> wish to examine those instances as well for similar bugs.
> 
> Best wishes, and thanks for FLAC.
> 
> Dave

		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs

ok, this is fixed in CVS.  also fixed is --sector-align on
raw input files.

--- Josh Coalson <xflac@yahoo.com> wrote:
> thanks, will take a look.
> 
> Josh
> 
> --- Dave Chapman <dave@dchapman.com> wrote:
> 
> > Hi,
> > 
> > A user at the www.thetradersden.org website reported a difference
> > when
> > fixing "sector boundary errors" in CD-quality WAV files with
> shntool
> > and
> > flac.  As as result of investigating this, I think I've found a
bug
> > in
> > the zero-ising of the buffer used to zero-pad the last file when
> > encoding with the --sector-align option.
> > 
> > My test consisted of the creation of four "non-aligned" CD
quality
> > WAV
> > files.  I then "fixed" these files using both the
"shntool fix"
> > command
> > and the "flac --sector-align" command.
> > 
> > I then compared the WAV files created by shntool and the WAV files
> > created by uncompressing the FLAC files, and the MD5 checksums did
> > not
> > match for the final track.
> > 
> > On comparing the contents of the WAV files, the "shntool"
fixed
> > version
> > correctly contained 448 zero bytes at the end (112 samples). 
> > However,
> > the FLAC version contained 224 zero bytes, followed by 224 non-zero
> > bytes.
> > 
> > I've tracked the bug to the calculation of the number of bytes to
> > fill
> > the input_ buffer with, which is calculated in line 778 of encode.c
> > as
> > follows:
> > 
> > data_bytes = wide_samples * (bps >> 3);
> > 
> > However, my understanding is that the input_buffer is always an
> array
> > of
> > 32-bit integers, and therefore the calculation should always be:
> > 
> > data_bytes = wide_samples * 4;
> > 
> > The expression (bps >> 3) is also used elsewhere in encode.c so
you
> > may
> > wish to examine those instances as well for similar bugs.
> > 
> > Best wishes, and thanks for FLAC.
> > 
> > Dave
> 
> 
> 		
> ____________________________________________________
> Start your day with Yahoo! - make it your home page 
> http://www.yahoo.com/r/hs 
>  
> _______________________________________________
> Flac-dev mailing list
> Flac-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
> 


	
		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - You care about security. So do we. 
http://promotions.yahoo.com/new_mail