> 
> pretty much the best I could get but I know for example that
> --nspsytune normally enables -X1, but -X3 sounds quite a bit better
> although it is significantly slower... which isn't too big of a deal
> to me.  Also, I know that from earlier conversations --athlower isn't
> perhaps the greatest way to control file size (which is what I am
> using it for)... however without it the files average 270kbps or more
> usually which is a bit too big... using --athlower they come down to
> around 230kbps average, although I have had files which reached all
> the way up to 290kbps.  It also seems that these particular settings
> allow a larger bitrate range (ive seen from ~150 to ~290kbps), while
> the older settings seemed limited to around ~170 to ~230kbps..  I plan
> on posting some information about all of the tests and stuff that I
> have done on a website soon.. I would like to hear some opinions on
> these settings and my findings.  Oh... and about that possible
> bug... when using these settings, ocassion!
> 
> 

At these types of average bitrates, I think you might be better off
with CBR instead of VBR.   This is because with an average bitrate
230kbs, you only need an extra 90kbs to go up to 320kbs.  90kbs
is only 40% of the average frame size - these types of fluctuations
are easily handled by the bitreservoir in CBR mode.  
(it can handle such a fluctuation in 25% of the frames)

VBR is more usefull at lower bitrates: take an average bitrate of
128kbs, where you need an extra 250% of the average frame size to make
it up to 320kbs.  CBR mode can handle such a fluctuation, but for only
about 4% of the frames.

> aly (about 1 in 10 times or a bit less) while encoding lame will start
> giving an error saying:
> 
> ERROR: MAX_HEADER_BUF too small in bitstream.c
> 

The last time I saw this error, it turned out to be because
the user was overclocking his system and it was unstable. 
If that is not the problem, then you need a version of LAME
compiled with debugging information turned on.  LAME will
then probably stop before MAX_HEADER_BUF overflows, with a different,
more informative message.  Did you compile lame yourself?

Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Reply via email to