Speex dev - Feb 2008 - Quick bug in speexenc

Good day, a quick bug while encoding speexes in speexenc.

 

While reading a .wav in function read_samples, size can get to negative
values, as long as fread is able to go forward with reading the file. This
can happen with Protools-generated wavs, where they put additional
information after the "data" fourcc.

 

I created a very quick hack by adding:

 

         int tentative_read = bits/8*channels* frame_size;

         if (*size < 0) {

               tentative_read = tentative_read + *size;    /* Size is
negative, don't forget ;) */

         }

      nb_read = fread(in,1,tentative_read, fin);

 

instead of the original fread.

 

This is a very dirty hack, but it works well using my strange .wavs. Cleanup
more than required ;)

 

 

Thanks

Michel

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/speex-dev/attachments/20080208/cca68d04/attachment-0001.htm

Can you explain a bit what you mean by a negative size and how you'd get
that?

	Jean-Marc

Michel Donais a ?crit :
> Good day, a quick bug while encoding speexes in speexenc.
> 
>  
> 
> While reading a .wav in function read_samples, size can get to negative
> values, as long as fread is able to go forward with reading the file.
> This can happen with Protools-generated wavs, where they put additional
> information after the ?data? fourcc.
> 
>  
> 
> I created a very quick hack by adding:
> 
>  
> 
>          int tentative_read = bits/8*channels* frame_size;
> 
>          if (*size < 0) {
> 
>                tentative_read = tentative_read + *size;    /* Size is
> negative, don't forget ;) */
> 
>          }
> 
>       nb_read = fread(in,1,tentative_read, fin);
> 
>  
> 
> instead of the original fread.
> 
>  
> 
> This is a very dirty hack, but it works well using my strange .wavs.
> Cleanup more than required ;)
> 
>  
> 
>  
> 
> Thanks
> 
> Michel
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Speex-dev mailing list
> Speex-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev

Yes of course,

WAV files are separated in chunks. _Usually_, the last chunk is
"data", and
after the data, the file ends. However, that's not _always_ true.

In the case of ProTools, they are adding a "extZ", "minf",
"elml", "regn"
and "ovwf" chunk after that one.

Speexenc would determine in variable size the "data" chunk size, then
every
loop would reduce remaining "size" by the frame size (getting a
negative
value at the last frame). The fread would read the full frame size, and then
it would succeed in reading that frame (because of additional chunks), hence
it would get extraneous data.

I cannot send to the list an example wav due to copyright constraints,
however to reproduce the behavior, you can always take a normal wav, write
"TEST" followed by 80 00 00 00 and 128 bytes of garbage using a binary
editor.


Thanks
Michel




-----Message d'origine-----
De?: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] 
Envoy??: 13 f?vrier 2008 05:19
??: Michel Donais
Cc?: speex-dev@xiph.org
Objet?: Re: [Speex-dev] Quick bug in speexenc

Can you explain a bit what you mean by a negative size and how you'd get
that?

	Jean-Marc

Michel Donais a ?crit :
> Good day, a quick bug while encoding speexes in speexenc.
> 
>  
> 
> While reading a .wav in function read_samples, size can get to negative
> values, as long as fread is able to go forward with reading the file.
> This can happen with Protools-generated wavs, where they put additional
> information after the ?data? fourcc.
> 
>  
> 
> I created a very quick hack by adding:
> 
>  
> 
>          int tentative_read = bits/8*channels* frame_size;
> 
>          if (*size < 0) {
> 
>                tentative_read = tentative_read + *size;    /* Size is
> negative, don't forget ;) */
> 
>          }
> 
>       nb_read = fread(in,1,tentative_read, fin);
> 
>  
> 
> instead of the original fread.
> 
>  
> 
> This is a very dirty hack, but it works well using my strange .wavs.
> Cleanup more than required ;)
> 
>  
> 
>  
> 
> Thanks
> 
> Michel
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Speex-dev mailing list
> Speex-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev