Hello Monty,
I tried to complile vorbis under win32 (using MS Visual C 5.0)
I found some things:
1.)
In bitvise.c there must be buffer cleared after malloc:
void _oggpack_writeinit(oggpack_buffer *b){
memset(b,0,sizeof(oggpack_buffer));
b->ptr=b->buffer=malloc(BUFFER_INCREMENT);
+ memset(b->ptr,0,BUFFER_INCREMENT);
b->storage=BUFFER_INCREMENT;
}
void _oggpack_write(oggpack_buffer *b,unsigned long value,int bits){
if(b->endbyte+4>=b->storage){
b->buffer=realloc(b->buffer,b->storage+BUFFER_INCREMENT);
+ memset(b->buffer+b->storage,0,BUFFER_INCREMENT);
b->storage+=BUFFER_INCREMENT;
b->ptr=b->buffer+b->endbyte;
}
value&=mask[bits];
bits+=b->endbit;
////////////////////////////////////////////////////
// { because of this
b->ptr[0]|=value<<b->endbit;
// }
////////////////////////////////////////////////////
2.)
undefined under win32 so define them:
#define M_PI (3.14159265359)
#define rint(x) (floor((x)+0.5)) // is this correct?
3.)
thousands of tons things like that had become
double out[winsize/2];
to
double *out=(double *) _alloca((winsize/2)*sizeof(double));
4.)
I found different behaviour between gcc and msvc when dividing very small
doubles (like 2.13e-312)
void _vs_residue_quantize(double *data,double *curve,
vorbis_info *vi,int n){
/* The following is temporary, hardwired bullshit */
int i;
for(i=0;i<n;i++){
int val=rint(data[i]/curve[i]);
if curve[i] is too small (zero?), under gcc val==-2147483648 (-INF?), under msvc
val==0
That's all.
macik
__________________________________________________
FREE Email for ALL! Sign up at http://www.mail.com
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
1.)>> This should just be b->buffer[0]='\0'; as is done in _oggpack_reset();Right, I was too lazy to look at it deeply. 2.)> There's really no rint() in MSVC?No rint(). At least in version 5.0 3.)> _alloca() instead of alloca()? I would expect MSVC++ to have the standard alloca() call.Same as 2.) There is only _alloca() in malloc.c> 4.) >> I found different behaviour between gcc and msvc when dividing very small doubles (like 2.13e-312)> What are the values in amp[] at that point (these are also doubles)?> if the amp[] isn't zero, could you make a quick dump of the data values into a > text file (as doubles) and mail them along to me?I assume it was zeros in amp[], because decoded streams were bit by bit same under win and linux although encoded streams were different due to this behaviour. I'll check it later this week(end), you can count on that. For now I'm too busy. bye macik (eof) __________________________________________________ FREE Email for ALL! Sign up at http://www.mail.com --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/
> 4.) >> I found different behaviour between gcc and msvc when dividing very small doubles (like 2.13e-312)My fault, there was something I missed. I can't see "very small doubles (like 2.13e-312)" anymore. These "small doubles" are really true zeros. So different behaviour is: int val=rint(data[i]/curve[i]); when curve[i] is zero then in gcc: val will become -(2^15) in MSVC: val will become 0 I'm surprised of this un-catched division by zero. to avoid of this we can simply check int val; if (curve[i]==0) { val=-16; // emulate gcc behaviour or // val=0; // emulate msvc behaviour } else { val=rint(data[i]/curve[i]); if(val>16)val=16; if(val<-16)val=-16; }; For now all inconsistencies are solved and win32 code produces exactly the same bitstreams like linux code (I’m curious of VQ code). bye macik (eof) __________________________________________________ FREE Email for ALL! Sign up at http://www.mail.com --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/