OK, here is a patch:
*** lame/lame.c Sat Feb 5 13:28:16 2000
--- lame-2000-02-06/lame.c Mon Feb 7 20:04:24 2000
***************
*** 288,293 ****
--- 288,294 ----
/* we do not normally allow 320bps frams with VBR, unless: */
if (gf.VBR_min_bitrate_kbps>=256) gf.VBR_max_bitrate=14;
if (gf.VBR_q == 0) gf.VBR_max_bitrate=14; /* allow 320kbs */
+ if (gf.VBR_q >= 1) gf.VBR_max_bitrate=13; /* allow 256kbs */
if (gf.VBR_q >= 4) gf.VBR_max_bitrate=12; /* max = 224kbs */
if (gf.VBR_q >= 8) gf.VBR_max_bitrate=9; /* low quality, max = 128kbs */
}else{
Robert
Mark Taylor schrieb am Mon, 07 Feb 2000:
> > Hi all,
> >
> > Found this while running some performance tests. The above command fails
> > with an assertion failure, or a crash with NDEBUG defined.
> >
> > Any ideas? -V 4 and upwards are fine.
> >
> > D:\Source\lame>lame -h --nores -V 3 fools.wav fools.mp3
> > LAME version 3.62 (www.sulaco.org/mp3)
> > GPSYCHO: GPL psycho-acoustic and noise shaping model version 0.75.
> > Encoding fools.wav to fools.mp3
> > Encoding as 44.1kHz VBR(q=3) stereo MPEG1 LayerIII qual=2
> > Frame | CPU/estimated | time/estimated | play/CPU | ETA
> > 60/ 1185( 5%)| 0:00:02/ 0:00:33| 0:00:02/ 0:00:40| 0.9521| 0:00:38
> > Assertion failed: used_bits <= bits, file quantize.c, line 419
> >
> > abnormal program termination
> >
> > -- Mat.
> >
> >
>
> The latest version in CVS has some problems - it also seg faults under
> CBR for me and fails even the 6 frame testcase.wav test. Can people
> hold off commiting any more changes for a day or two until this is
> straightened out?
>
> Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
