I think not. One of the features of mp3 is the bit reservoir, wich is in
a shortly explanation a way of expanding bits in a frame to another ...
let me try to put this is simple words (has i'm not a n mp3 expert) ...
In cbr, lame (an others encoders) compute the nessecary information
to compacta audio frame in mp3, but sometimes the nessecery bits are
bigger then what you get, so if say another frame after need less bits
to be encoded you can put the extra info on that frame.
so let's say that this frame needs 192Kb/s to be correctly encoded but
you are encoding a cbr mp3 in 160kb/s. without bit reservoir this frame
would be cutted and compacted to 160kb/s.
But with bit reservoir another future frame may need only 128kb/s so
that leaves space free and you can put the extra 32kb/s of the previous
frame in this one, provided that you mark
in this frame where did you put the extra 32kb/s. So it's something
similar to a second pass in the data to know where you can put the extra
bit's.
Well, does it sound familiar? ABR is similar to cbr with bit reservoir,
in the way that they produce a constante bitrate, but cbr uses bit
reservoir and ABR just balances bettewn VBR and the need of producing a
constante ratio bettwen compression and quality, say ABR also choose if
one can compact a frame with only 128Kb/s and in the future you need to
compact another with 256kb/s and so on, in order to obtain a constante
bitrate (if you sum all of the
bitrates choosen).
If you want to see ABR in work, make one with lame and see them with
encspot, you can see diferent rates but in the average they are like cbr.
So wich ones get more quality? well ABR got a few bugs but i think
they'r gone.
So abr can i my opinion be better then cbr, provided a good algorhythm
to choose the bitrates. That was one of the bad points of ABR, but it's
off now (I THINK).
So if space is a concern, choose ABR as it work like a VBR in CBR mode.
If space is not a concern, do something like i do, my switch is over
kill but guarentees enougth quality.
lame -b 192 --vbr-new -q 0 -B 320 -m s -F --lowpass-width 19.5 --athtype 3
Way?
well, -b 192 never drop under 192, so you get only 4 bitrates to choose from
-q 0 why should one uses a less quality alghorhythm even if it takes
less time when you do have time? only lower this if you got a slow CPU
-m s same people say that joint stereo encodes really good, and when
lame can't use joint mode because it produces bad results it switchs to
stereo mode, well, why should't i use true stereo mode(it's ver kill but
it guarantees the trully separation of chanel data and dosen't use any
kind of correlation bettwen chanels)
-F it's need becuse LAME makes the very few seconds on the end of a
music being 32Kb/s
so if you rip a mix album on the end of the tracks a few seconds get out
in 32kb/s really weird behaviour ...
--athtype 3 is the only parameter that i don't got sure that im' using
that in my command line. (i read email on college and work at home so i
don't have LAME in my front rigth now) But i remember to read something
about athtype 3 as a good curve for --vbr-new. Need to confirm this, as
i this point i can be wrong.
I hope that same of your doubts could be gone with this. Hope also not
to introduce new ones. And if you got questins concerning it drop a line
or two of email.
Ps: there are loads of undocumented features in LAME. ATH type curves
are a few of them.
I'm going to see where did if find same info on that. Will point that to
you latter.
Best regards.
Filipe
Michel SUCH wrote:
>On Fri, 26 Apr 2002 15:47:39 +0100, Filipe Arnaldo de Carvalho Valpereiro
>wrote:
>
>>That also happend to me when i've switched from 3.89 to 3.91
>>but i think it's probably 'natural' for that to happend has if you touch
>>the algorythm then it's normal that the size of the files will go
>>different.
>>
>>Has off getting smaller i can only think that it's probably a question
>>of the algorithm choosing the bitrate, and you can't expect that given
>>a heuristic the result will be the same.
>>
>>Has of LAME get files smaller and smaller it's not a think that i
>>personaly like.
>>But that's a compromise that one mustt choose for they personal
>>purposes. Mp3PRO cut's loads of frequencies and the result can be
>>audible, but is it near by the original one? no it can't. So with LAME
>>going this way i think i'll stick with this version (3.91) for long term.
>>
>>Reason:
>>I'm expecting that LAME reproduces as cloose to the original it can get.
>>So if you start to cut's to mutch frequencies it will resemble Mp3PRO
>>... and that's :=(
>>
>>So why not improve better compressing times and better cut's curves and
>>better quantitization algorythms instead of cutting more bit's...
>>
>>
>Well, you are right in my opinion.
>As an audiophile, I expect an mp3 encoder to produice result as close as
>possible of the original which, at a reasonable bit rate, is the case of
>lame.
>I have no way other than my hears to evaluate the result and, with the
>flags I used, I don't hear noticeable difference between previous results
>and the one I get with 3.93 alpha.
>So I guess there must be something *wrong*.
>But someone having tools to make some more acurate analysis could as well
>find something different.
>
>I intensively use lame, not essentially to encode music, but to save radio
>broadcasts (theatre and thing like this) I recorded along years and am
>very happy with waht it produices.
>
>One question could be:
>If, using variable bit rate, you need more space, does it imply that,
>using cbr, afile produiced with the current version would be of worst
>quality than previously.
>
>
>>Robert Hegemann wrote:
>>
>>>Hi Michel,
>>>
>>>no, it's not a wanted behaviour, current lame seems to be broken.
>>>I think Takehiro has some more pending committs.
>>>
>>>Ciao Robert
>>>
>>>Am Mittwoch, 24. April 2002 20:13 schrieb Michel SUCH:
>>>
>>>>Hi all,
>>>>
>>>>I don't know if it is normal since, in my opinion, the aim is not
>>>>necesarilly to produice the smallest files, but I have a test wave file
>>>>that I use to encode each time a change is applied to lame.
>>>>With the latest version, I get this result:
>>>>
>>>>average: 212.7 kbps LR: 2028 (32.49%) MS: 4214 (67.51%)
>>>>
>>>>With 3.92 I got:
>>>>average: 182.9 kbps LR: 2028 (32.49%) MS: 4214 (67.51%
>>>>
>>>>I encode it with following flags:
>>>>--vbr-new --preset hifi
>>>>
>>>>I don't know if this is the expected behaviour, just wanted to let you
>>>>know.
>>>>
>>>>
>>>>----------------------------
>>>>Michel SUCH TEAM OS/2 FRANCE
>>>>ICQ # 51654489
>>>>
>>>>_______________________________________________
>>>>mp3encoder mailing list
>>>>[EMAIL PROTECTED]
>>>>http://minnie.tuhs.org/mailman/listinfo/mp3encoder
>>>>
>>>_______________________________________________
>>>mp3encoder mailing list
>>>[EMAIL PROTECTED]
>>>http://minnie.tuhs.org/mailman/listinfo/mp3encoder
>>>
>>>
>>
>>
>>_______________________________________________
>>mp3encoder mailing list
>>[EMAIL PROTECTED]
>>http://minnie.tuhs.org/mailman/listinfo/mp3encoder
>>
>
>----------------------------
>Michel SUCH TEAM OS/2 FRANCE
>ICQ # 51654489
>
>_______________________________________________
>mp3encoder mailing list
>[EMAIL PROTECTED]
>http://minnie.tuhs.org/mailman/listinfo/mp3encoder
>
>
_______________________________________________
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder
