>
> Hello Mathew,
>
> > fc /b generic.mp3 modified.mp3
> that's exactly what I did! :-)
>
> > Some reference mp3s on sulaco.org, updated periodically, would be handy for
> > keeping track of this.
> This would be a good thing to start with.
>
> I don't know if this is possible, but could a switch be added that
> does some kind of self-check? That would probably be the most
> user-friendly version...
>
> Regards,
> Holger Dors mailto:[EMAIL PROTECTED]
>
this is a good idea, but I dont know how to do it.
My test cases require bit-for-bit identical mp3 files, but
it is sensitive to things like changing the optimization level,
math libraries and compilier versions. So if I posted the mp3 files,
I dont think it could be used by others not using RH5.2 & gcc 2.95.
The problem is that a change in round off error might result
in one extra bit of storage, which could force the bitrevoir to change by
1 byte, which will then change the bitreservoir by 1 byte, which will
then change *every* following frame.
It might be possible to turn off the bitreservoir
(always set main_data_begin=0) and then small errors would only
effect one frame and we could look for 90% agreement or something
like that.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
