>
> > Which version are you using? Such a bug was fixed a few months
> > ago, but I just checked our change log and the fix was never
> > recorded, so I dont know exactly which version. It was an overflow
> > in one of the counters.
>
> I ran into it a couple of weeks ago, with a (mildly) old CVS build. This is
> when I was first doing the forked encode processes that stayed up
> indefinitely. I tried updating my CVS and rebuilding then with the same
> results. 3.85 dies out on me with an error that sounds like it's not
> supposed to happen, but I don't think it's related. I still need to set up
> a test environment, so far I've been playing with my production radio
> station, so I haven't had much of a chance to dig deep into bombs, just
> restart and look through the logs.
>
I just ran a test using "lame /dev/zero /dev/null". Not a very thorough
test, but it should test all the frame and bit counters. I stopped it
after it had encoded over 20 million frames.
Can you compile LAME with the asserts turned on
(add -U NDEBUG to CC_OPTS in the Makefile) and
see if it displays any error messages before dying.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
