I am in the process of the same. I read some interesting web pages where
guys did all this experimentation...some of it quite scientific...and some
of it very subjective. This is what I came down to in my own decision (as
of now):
1 - 128bit CBR is *NOT* good enough. You'll get about 1MB/min with that
mode, but I can
definitely hear a distinct difference between the MP3 and the WAV. It
does not
sound as "present". That means the midrange content is somehow
getting rolled off
a little in terms of sparkle. Now granted, that could also have been
because of
a 15k lowpass filter in effect, but notwithstanding, it was enough
motivation for me
to decide that 128bit CBR is not good enough.
2 - 192bit CBR sounds much better, but I still noticed the lack of
presence. Again,
possibily because of 15 lowpass filter. At the time, I was using the
Radium
encoder which does that. File size is more like 1.5MB/min at this bit
rate.
Some people say that they can't hear the difference between 128 and
192. Other
people say that they can. Some people say it depends on the content.
I say,
stick with at least 192 for CBR. Be on the safe side.
3 - I found lame. I read about VBR and I didn't even look back to CBR.
When you
look at the histograms, 99% of the content is 192bit. But sections
where the
algorithm thinks it needs to, it does 256bits or even higher. And
some of it is
at 160, and even a little at 128bit. It sounds great. Plays back
fine in Winamp
and I'm still waiting for my Aphex to arrive to try it there.
4 - With lame, I use the -k option to get rid of the lowpass filter.
Maybe the filesize
is bigger, but I don't care, I want the presence.
5 - This is the command line I'm currently using:
lame -b 128 -V1 -q -mj -F -p -k
with that command line my file sizes are about 1.5MB/min, give or
take. They
seem to sound pretty good. In my opinion, as good as an MP3 can
sound without
consuming too much space. Note, I'm still not entirely sure I need
all those
command line switches. For example, me thinks the -q flag is not
needed in
VBR mode. But I'm not entirely sure, so I use it anyway.
6 - On my 200 Mhz Pentium Linux machine, it takes about an hour to encode
a full
CD at these settings. But I use a Perl script I found on the web
called
"ripit" that utilizes "cdparanoia" to rip the wav and then lame in the
background
to encode the MP3. It rips all the wavs in about 10 minutes or so,
then it takes
longer to do the MP3's. I will usually just open 5 windows in
linux....take an
hour to get the CD's ripped to wav's with 5 sessions of lame going in
parallel.
then they go all day or night....takes about 6 hours or so...and all 5
CD's are
encoded at that point.
7 - I also found out that if you like to DJ, a lot of the DJ software that
works with
MP3's gets confused by VBR files. The DJ software is not able to
detect the timing
of the music or whatever. So when they try to mix or whatever it is
that DJ's do
then it skips and stutters and causes all kinds of grief. So DJ's I
know stick
strictly to 192 CBR. I don't DJ, so I'm trying VBR for a while and
hopefully the
players will all join the bandwagon and figure out how to correctly
read them back
without all those problems in the long run.
good luck.
-steve
> -----Original Message-----
> From: Charlton Harrison [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 31, 2000 11:19 PM
> To: Mark Taylor
> Cc: [EMAIL PROTECTED]
> Subject: Re: [MP3 ENCODER] What's Safe-VBR mode?
>
>
> On Wed, May 31, 2000 at 10:39:52PM -0500, Mark Taylor wrote:
> > There are now 3 VBR modes:
> >
> > 1. the current version (default)
> >
> > 2. -Y enables the true noise shaping VBR mode. It should give
> > similar results to #1, but be much faster. Faster because it
> > does not use the outer_loop() iterations scheme, but computes
> > each scalefactor directly and then does just one quantization
> > at the very end.
> >
> > I'm hoping #2 will replace #1 soon. But I still dont trust either
> > of these algorithms. Does anyone have examples of a
> 128kbs(average) VBR
> > sounding better than a 128kbs CBR?
> >
> > 3. "safe VBR". This mode is really CBR, but it keeps the bit
> > reservoir as small as possible and uses VBR to achieve
> > an unlimited bit reservoir. When the target bitrate is
> > (for example) 128kbs, it will produce files slightly larger
> > than 128kbs, but *always* sound better than 128kbs CBR.
> > it also runs just as fast as CBR :-)
> > if you want to try it out, change the #undef SAFE_VBR to
> > #define SAVE_VBR in quantize.c
>
>
> Mark,
>
> I am in the process of making MP3s of all of my CDs, and
> using lame3.83
> to do it. I want my files to be about 1MB/min in general and possibly
> larger if I can hear differences (that bother me) (most of
> the time I can't).
>
> Anyway, I've been doing extensive research and discovered
> that lame is
> the way to go (do you agree? - or should I wait until there's
> a finished
> more polished version?) but I cannot figure out what command line
> options I should use, or which of these modes you mention
> above is the
> best to encode my hundreds of CDs with...
>
> Also the note above about you not trusting 128kbps VBR to sound better
> than 128kbps CBR really bothers me. I thought VBR is the way to go.
>
> Can you make me some recommendations?
>
>
> Charlton
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
