>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.
>
Well I actually have thought of using just straight CBR but in most of the cases that
I have tested these particular VBR settings seem to perform better. For example, when
encoding fatboy.wav with these vbr settings the file size is around 224kbps or
something, i dont recall exactly.... now when I encode fatboy.wav with lame -b256 -mj
-q2 --nspsytune -X3 (and also without --nspsytune) the CBR file clearly has more noise
in the background than VBR file... for me to get a CBR that sounds as good I have to
bump up the bitrate to 256kbps. Granted, 224 to 256 isnt that big of a difference,
but if it sounds better at a lower bitrate then why not use it? Earlier I remember
there being some talk about --nspsytune spending too many bits on tonal parts of audio
clips... i think that if this hasnt been resolved, that when it is, it should probably
result in even smaller files with possibly the same level of quality. I have noticed
that on most of my music, the more melodic stuff is us!
ually what ends up being encoded at bitrates of 250kbps and above. If the effeciency
of --nspsytune in those cases can be improved them filesize should become less of an
issue, and will make these particular VBR settings more appealing.
>
>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/ )
>
I am 100% sure this is not the case. Although I will admit that my system is
overclocked I have run extremely extensive tests (prime95 for days, etc) and I usually
have uptimes of several weeks, while running graphics programs, games, running an ftp
server, encoding mp3s, etc. Lame is the only thing affected, and only when using
these settings. As for the version I am using, it is here:
http://www.chat.ru/~dkutsanov/lame387mmx.zip
It seems to work great other than that particular error every once in awhile...
usually if I go back and reencode the song it will work ok, although there was one
particular song (I'll try to find which one it was) where it took 5 tried before it
would fully encode. Thats about it... although I am kinda hoping to get some more
comments on the particular settings themselves... One thing I am kinda wondering about
is how the whole -X switch fits into the equation... I have tried every -X switch with
those settings and -X2 and -X3 are the only ones which seemed to encode various test
files without errors... is there something special about how those relate to the other
settings? Also, the reason I use --nspsytune is because it usually seems to further
reduce filesize (at least in the case of fatboy.wav... the bitrate drops from around
270 to 220kbps)... can anyone explain how or why this happens? Is it a bad idea to
use it in most situations? I have tried using -q1 in combina!
tion with --nspsytune because of earlier discussions saying they could be
complimentary, but it seems to either have no effect (most of the time) except being
significantly slower, or it actually makes the file sound worse. I am wondering again
if -X3 maybe has something to do with that. Any ideas?
Dibrom
Get your FREE Email and Voicemail at Lycos Communications at
http://comm.lycos.com
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
