i have encoded a lot of my mp3s at 128 and fear I may have to re-rip and encode those. I have begun to encode using Variable Bit Rate (VBR) with the low of 160 and high of 256. I am using software called CDex. What is the difference btwn VBR0 and VBR1 and VBR 9 etc?

p.s. kds has hooked me up with an 48 gig empeg. i feel very lucky!

vbr0 is the highest qual vbr
I also use --vrb-new which seems to give me better results than the default --vbr-old

most people think quality 1 (lame is the encoder, we assume) is reasonably perfect, but 0 doesn't take much more space.

John

I, and many others use "--alt-preset standard"

If i recall correctly CDEX uses the Lame DLL, while still quite good it does not offer the same number of options as the Lame EXE.
willebear, ripping and encoding MP3s is a time consuming process, irrevelent as to how fast your CD rips and your CPU encodes. So take the time now to figure out what ripper and what encoder (and settings) suit you best, and don't forget about the ID tags - idealy your encoder should do them for you. Oh and also check what file naming convention suits.

A good read is the r3mix site.

Finally the personal bit - I am using AudioGrabber, but also recommend the freeware EAC. Enoding with the currect release of Lame.exe using the "--alt-preset standard" preset.

I'll reinforce Phoenix's point: It is no fun re-encoding your collection twice (as you are finding out first hand). So, take the time and do it right. AudioGrabber and EAC are both excellent and fast.

i got EAC and lame. does EAC rip as *.wav files? I would rather extract straight to *.mp3 if possible, CDex gives the option of both. Does EAC offer "extract to mp3"?

never mind previous post

i feel like an idiot....

Looks like you figured it out yourself, but in case anyone else was curious, no program rips straight to mp3. There are ones that look like they do (MusicMatch for example), but they are really just hiding the .wav process. I've found programs like this are more likely to get hung up on a less than perfect CD.

If anyone has IRC, pop into #myden on Dalnet and I can help you configure EAC... it takes a few minutes to setup, but if you are walked through it, it is painless. Also, there is a good tutorial here.

Audiograbber with Xing does that, doesn't it? If you switch off 'use intermediatery .wav file' then as it rips the audio from the CD it pipes it through to the MP3 encoder at the same time, so you get both the CD ripping and MP3 encoding progress bars increasing at the same rate.

You could argue that it is really being taken as a .wav format from the CD reader and then being piped in as .wav format data to the mp3 encoder, but it's close enough to direct ripping to mp3 for my dictionary.

Of course, all this is purely academic as nobody would actually *use* the Xing encoder...

A.

LOL, I thnk Tony does (or did), but at a high bit rate, it is okay.

I think what you're talking about only works with the Lame.dll and not with the lame.exe?

Hi.

i feel like an idiot....

Don't do that (feeling like an idiot as well as direct ripping to .mp3).

EAC (IIRC) does not support direct ripping to mp3, but has everything integrated to automatically encode to mp3 after ripping and deleting the .wav after encoding finished.
There are reasons why I say you shouldn't rip to mp3 directly, the best reason not to do that is simply time: If you rip directly to mp3, you have to wait for the encoding of a CD (resp. CD-track) before you can switch to the next CD (track). With EAC, you rip each disc as fast as the drive and CD allow, and switch to the next disc immediately (as long as you have enough space left on your HD). This way, I have been ripping litterally 2 dozens CDs in 2 hours after work, and left my PC encoding them during the night (with some already finished while still ripping). If I did rip and encode in one go, I wouldn't have done more than 4-6 CDs in that time.
One other reason are possible read errors. EAC does its best to detect these, and also compares CRCs with those CRCs it knows (from the TOC) AFAIK. These detections work best when you rip to WAV first.
Third reason: normalization. If you want EAC to normalize the WAV before encoding (a thing I won't do), you need to rip to WAV first. The reason why I won't let EAC do the normalization is twofold: First, EAC only normalizes so that the highest peak is within 99% of the maximum peak (or whatever value you configure EAC to), but it does not normalize to a given average volume/power. The other reason is that MP3 supports floating point arithmetics by default (even though the ARM implementation is fixed point/integer only) , and it allows for a floating point correction factor to be applied to each block/segment/<whateveritiscalled>. This does (in theory at least) allow for a better resolution in the amplification of the waveform. Well, at least in theory. But as I apply a volume based normalization to my MP3s anyway, I would do double normalization if I let EAC do its normalization, and that would be a bad thing to do.

cu,
sven

thanks for all of the guidance. i may try the rip only for the eac. EAC seems to be somewhat of a RAM hog and a little unstable on my xp box.

i think that CDex with lame 3.88 with VBR0 - min bitrate 192 / max 320 will be good.

do you think this will be equivalent to the EAC / lame 3.9 combo?

the EAC with lame encoding concurrently is very slow compared to CDex. I also like the way CDex creates a folder for the artist, album, and puts the appropriate songs in along with a playlist.

BTW, will extraneuos files like a playlist screw up the empeg in any way?

thanks again

Play with it.
It will creat what ever File / Directory structure you want.
As for taking longer - yes it can, again play with it, maybe you have some very rigrious ripping settings - EAC can be set up to try it best to ensure a perfect[/] rip. Also the Lame setting provided is a High Quality one which will take time (~2x-3x on my P3-700),

Again spend time on research before you rip your CD collection - nothing worse then having to redo it all.

Many will consider this way excessive, but I use

-b 320 -k -q 0 -m S .

Basically the top quality possible. Quite large mp3 files. Problem is, for me, I can hear the difference, or maybe I THINK I can hear the difference. Still, form my personal pnt of view, that does not make any difference right?

Forgot to mention that I use Lame as you could guess, with Audiograbber. I found it very very good, and ended up registering it. Hope this helps.

LOL, I thnk Tony does (or did), but at a high bit rate, it is okay.

More importantly, at a high VBR bitrate with the high-frequency rolloff turned off. I still can't tell the difference between files encoded this way with Xing and encoded with LAME.

Xing has gotten a lot of bad press for the earlier releases of its encoder, but the one included with AudioCatalyst is much improved from the ones that got all the complaints (as long as you turn off the rolloff).

Lately the Jupiter has been handling all my ripping chores, I'm doing 256kbps fixed. It uses a variant of Fraunhofer to do its job.

Many will consider this way excessive, but I use
-b 320 -k -q 0 -m S .

uh, don't forget -F
this Forces LAME to use 320 even when it is not absolutely necessary,
like during silent parts of a song.
This might only be necessary when using VBR like I do with :
-k -q0 -v --vbr-new -V0 -b192 -B320 -F -ms
but check the doc

Yes, AFAIK that's needed only in VBR. In the "--longhelp" it is mentioned only among VBR options. After all if you encode CBR there's no reason why lame should bother changing BR at all. Thanks for your suggestion anyway!

EAC will do folders.. for example, I use: %A\%C\%A - %C - (%N) - %T for the file name scheme...

If you are running Win2000 or WinXP, you need to download the 4.70 ASPI drivers from www.adaptec.com.

EAC seems to be somewhat of a RAM hog and a little unstable on my xp box.

If I remember the EAC mailinglist correctly, there are known instabilities under XP in certain situations. IIRC, they can get worked around by installing ASAPI and using that instead of the built-in ASPI or Win2K/XP native interface.

i think that CDex with lame 3.88 with VBR0 - min bitrate 192 / max 320 will be good.
do you think this will be equivalent to the EAC / lame 3.9 combo?

I can't comment much on this either. VBR0 with a min. of 192 sounds pretty high for my taste. VBR0 with a minimum of 128 should be good in any situation. Leave the max at the highest possible value (was ist 320k or 384k?) though, to encode with the best possible representation. I can't say anything about the lame 3.88/3.9 differences though.

the EAC with lame encoding concurrently is very slow compared to CDex.
Well, this is probably because EAC makes sure that it always does _exact_ audio copies, just like its name says. CDex is ripping a disc once, EAC usually rips it twice to make sure he got the right result. Make sure your drive is set up correctly. If your drive does not cache audio data (EAC can test this for you), make sure the relevant checkmark is not set in the drive setup, because audio caching slows down EAC significantly. Also, if your drive supports C2 error detection, make sure the relevant checkmark is set. Again, EAC can test this for you, though this test is tricky: You need a scratched disc to do this test, so that read errors occure, but it must not be scratched so badly that you can't read it at all. Third one is "accurate stream". This one should be set if you are sure your drive supports it (most modern drives do), because if your drive does accurate streaming, EAC can skip jitter correction. So, to sum this all up, here are the most secure settings for the drive options, sorted by the impact they have on EAC ripping speed:
Drive caches audio: Unset only if you are sure your drive does NOT cache audio.
Supports C2 error correction: Set only if you are sure your drive supports it.
Does accurate stream: Set only if you are sure your drive supports it.
If you do not want to make sure to get perfect rips, but want to rip as fast as possible, just set the extraction method to fast mode or burst mode. The former does jitter correction if needed, the later doesn't IIRC.

I also like the way CDex creates a folder for the artist, album, and puts the appropriate songs in along with a playlist.

EAC can create folders based of artist, album, year and any other id3 information it supports. Under EAC options, Filename, construction of SAVE filenames , just set a filename like
%D\%C\%N - %A - %T
To create directories/files like
\Various Artists\Rock Symphonies\01 - Some Artist - Some Title.mp3, or
\Elton John\Best of\02 - Elton John - Some Title.mp3
Note the backslashes between the different tags to delimit directories.
It is also able to create .m3u playlists, at least one for each ripping process (so usually a whole CD).
Regarding the question about extraneous files: All non-audio files are ignored by emplode and AFAIK also by jEmplode. With one exception: .m3u playlists are not ignored by default, IIRC. But this is settable in the options, so they can also be ignored. Note however that jEmplode has a very powerful feature: It supports nested .m3u playlists, so you can "include" CD playlist files in an artist playlist. This way, you can mimic the complete playlist structure of your empeg by creating the right m3u playlists. To "include" a sub-playlist, just specify its pathname in the "parent" playlist, just like you would normally specify an audio filename. Like this:

test1.wav

test2.mp3

test3\test3.m3u

test4.mp3

This playlist would play the test1.wav, followed by test2.mp3, followed by whatever the test3\test3.m3u playlist specifies, followed by test4.mp3.

cu,
sven