> > Oops, not quite as bad as I thought. WinCvs was performing newline > conversions/keyword substitutions on the files. Were they added as binary > files? I used cvs update -kb <file> to get them manually in the end. > > So now the files are the same size. No differences in the first half of the > mp3, then plenty afterwards (from offset 0x68f). Should there be switch in > stereo mode or block type or something about half way through? I don't have > mp3x to look at the files closely. > > I've put this new mp3 on sulaco for inspection. /incoming/testcase.new.mp3 > > -- Mat. > > I just took a look: The first difference I could see is frame 4. Blocktypes and modes are all the same, you have the first scalefac=0, and my version has it nonzero. Kind of suspicious that it is the first scalefactor - could be some kind of buffer overflow problem :-( I dont think it could be due to roundoff error differences. Also, another bug in the frame analyzer: the test case is really only 6 frames - frame analyer shows incorrect data for ficticous frames 7 and 8 (and the last half of frame 6) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
