> From: Holger Dors [mailto:[EMAIL PROTECTED]]
>
> > [...] but it breaks my validation tests.
>
> speaking of validation: is there any simple test available that a
> (Win32) user can check that his version of Lame is working as
> supposed?
I think the best you can do at the moment is disable any system-specific
optimisations and force it to use the "generic" versions of the functions.
e.g. you may see
#ifdef _MSC_VER
/* ... MSVC-specific code ... */
#else
/* ... generic code ... */
#endif
which you can temporarily change to
/*#ifdef _MSC_VER*/
#if 0
/* ... MSVC-specific code ... */
#else
/* ... generic code ... */
#endif
(obviously BCB will use different #defines, but I don't know them :)
Then compare mp3s produced by this with those produced by a system-specific
version. I use fc.exe, which I think is supplied as standard with Windows
fc /b generic.mp3 modified.mp3
When making changes to quantize_xrpow, I've been running tests like this,
and the current (per CVS) version produces identical results across versions
under MSVC. I tested "generic" (pure C), "partial asm" (asm only for
XRPOW_FTOI) and "full asm" (Acy's code with modifications) implementations,
both normal (quantize_xrpow_ISO) and high quality (quantize_xrpow).
> I find this quite important as there's no "offical" release,
> and I found
> that the files created with a LAME version I downloaded
> weren't bit compatible
> with a version I compiled using BCB. Shouldn't this be the case?
I think there have been several changes since 3.57 that will change output.
The new -h quantization, for one.
Some reference mp3s on sulaco.org, updated periodically, would be handy for
keeping track of this.
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
