Hi,

I'm trying LAME encoding for the first time. (with EAC)
Before it, I was using MusicMatch JukeBox (MMJ) v6 then 7? Will I hear a
real difference between two files compared one with MMJ and one with LAME ?

I used to read and compress one track in one minute with MMJ, now it takes
me 1 min. to rip the track and then 7 min. to compress it (command line
: --alt-preset standard %s %d ; which is hi-q VBR).
is it normal ? (the track was 4:35 and my CPU is a 1,6GHz Pentium IV with
512 MB RAM)

Thanks for your help

PiKs'L (yes, it's me again)

"PiKs'L 58 An202" <yurk@yaourt.fr> wrote in
news:bqj5v8$64c$1@news-reader5.wanadoo.fr:

MMJB uses a special *fast* encoder that takes all kinds of shortcuts to
increase the encode speed. The --alt preset standard Lame encode is
optimised to give the highest quality. Whether you will hear the
difference depends on the quality of your equipment (soundcard, amp,
speakers) and how skilled you are in detecting artefacts (sounds produced
by the encoding process). If you are encoding for others you should
consider that they may have better gear.

If you want to speed up the Lame encode try
--alt-preset fast standard

--
fred

I read online somewhere that Lame 3.93 had some problems, and some people went
back to 3.92. So how much audible difference is there between Lame 3.92 and
3.93, or is this just a subtlety?

"Bill in Co." <nowhere@earthlink.net> wrote:

There was a bug-fix release soon after, called 3.93.1. Even with the
initial release, the problems were specifically with the ABR and CBR
presets, and the -q0 switch. However, the actual improvements over
3.92 in either 3.93 release are unlikely to be noticed by most people.

--
Joel Crump

OK, thanks Joel. For me that would have been a "sublety", as I end up using
the normal quality settings (q=5, I believe) most of the time. (Although I
always use CBR - never VBR).

Joel wrote:

"Bill in Co." <nowhere@earthlink.net> wrote:

Indeed, for most people, those bugs were insignificant. ABR is sort
of a strange thing to use (although it's nice that LAME put it in for
those who want it), and the CBR presets are questionably any better
than -q2 with Joint Stereo (particularly since they add a good bit of
time to the encoding).

--
Joel Crump

Joel wrote:
Which reminds me....I've read that JS is probably better for 128 kbps and under
(as a tradeoff between channel separation and more faithful rendition of the
music during the encoding). Have you ever done any A-B tests at the 128 kbps
rate on the same music samples (between JS and Stereo), and heard the
difference?

"Bill in Co." <nowhere@earthlink.net> wrote:

There generally is a clear difference, yes; one problem there is that
LAME seems to do pretty poorly at 128 Kbps, even with JS. FastEnc
(i.e. MMJB and Nero), for example, which apparently only uses normal
Stereo frames even if it labels a file as JS, pretty clearly sounds
better than LAME at 128. The best 128 Kbps files I've heard were made
with one of the full-fledged Fraunhofer codecs using JS. At 160 and
higher, though, LAME is as good as any; and for VBR, LAME simply can't
be beat, whether one uses the presets with JS, or manually configures
the settings.

--
Joel Crump

what is the difference between JS and stereo ?

"PiKs'L 58 An202" <yurk@yaourt.fr> wrote:

JS can encode a frame partially in mono. Sound which doesn't require
stereo separation is put in the "mid" channel in such a frame, hence
the term "mid/side frame" (the two side channels are not unlike how
they would be in a normal frame, although requiring the mid channel to
fully reproduce the sound). This allows more bits to be used for
unique information, greatly increasing fidelity, but probably does
have a minor effect on stereo imaging (particularly for encoders where
it isn't as well implemented as it could be).

--
Joel Crump

thanx,
you're a real encyclopedia about mp3 compression.....!

"Joel" <joelc999@hotmail.com> a écrit dans le message de
news:gf7ssvciocdstbvo7394fr7usuv99embnn@4ax.com...

"PiKs'L 58 An202" <yurk@yaourt.fr> wrote:

When I first came to this newsgroup, I only had half a clue. I have
to give a lot of credit to others' posts, and the Web documents on MP3
technology.

--
Joel Crump

Stereo encodes each channel separately. Joint Stereo encodes a main channel with both channels added together, and a side channel with the difference between the channels. The side channel is what gives you the stereo effect. The biggest advantage of JS is that tracks that are in mono or have very little separation between channels require very little data in the side channel and thus reduce file size significantly (using VBR, of course).

PiKs'L 58 An202 wrote:
--
Mike Walsh
West Palm Beach, Florida, U.S.A.

Mike Walsh <mikew137@sbcglobal.net> wrote:


I got some bad info somewhere along the line. I see that Mike's
description is accurate. My apologies to the original poster.

--
Joel Crump

Then how do they get separate L and R channels when it's all said and done?
Do they basically add the L+R information to the L-R to get L, and subtract the
two to get R? Does the mp3 *decoder* do this automatically if it's smart
enough to sense that the original *encoding* was made using Joint Stereo?

Mike Walsh wrote:

"Bill in Co." <nowhere@earthlink.net> wrote:

The (L - R) / 2 would indicate the relative volume in each channel,
such as:

In the encoder: L = 5, R = 2; (L + R) / 2 = 3.5 [mid channel]; (L -
R) / 2 = 1.5 [side channel]

In the decoder: 3.5 + 1.5 = 5 [left channel]; 3.5 - 1.5 = 2 [right
channel]

If you're asking whether a file which isn't tagged as JS but has m/s
frames would still be played back correctly, I'm not sure (presumably
depends on the software). Otherwise, my answer would be that the
decoder would have to be able to handle m/s frames to play back JS
files, since they're inherently different from normal Stereo frames.

--
Joel Crump