There could be a couple of reasons for this. If you are getting bad wavs, like hybrid suggested, then try slowing down your cd drive. Go into the settings tab, and there will be options for the cd drive, drive speed, and rip method. First, try slowing down the cd drive. If you have it set for 20x, try 8X. If that doesnt work, try changing the rip method to dynamic sync width or one of the fixed sync width options.

Sean

Or, if it doesn't work (and work well) on "Buffered Burst" go out and buy a new CDROM drive. Because you'll be pulling your hair out trying to rip on a slow drive with questionable performance. As an aside: It takes me between 2 to 3 minutes to rip an entire CD with my Plextor. That's rip, not encode.

Bruno

I did notice that when using Lame externally it took quite a bit more time for the encoding. The ripping time was the same, about 5 to 6 mintues for an entire CD. It's a Samsung drive and was given to me since my other drive gave up. I would like to get a Plextor someday but can't afford it at the moment. I haven't had a chance to test a .wav file yet but will sometime today.

I think my ears are getting tired. I slowed down the rip speed since the .wav file didn't sound any better than the MP3. I have it set on dynamic synch width which did help out. I have tried --r3mix and --alt-preset standard internally and externally. The --r3mix sounds better to me at least through AudioGrabber using Lame externally. But it doesn't sound any better than it did using the settings I used to use internally, VBR, high quality and joint stereo. I'll try again later after my ears have rested.

Guess I'll buy a better CD-ROM drive when I can.

You should try ripping the wav twice, while noting the checksum after the first run...if the checksum of the second rip is the same, you can be pretty sure you have a perfect rip. In that case, if sound-quality isn't good, it's still the best you can get from that CD...
I always do a 'grab', and then a 'test': that way i get two checksums to compare and only one wav-file.
Could use EAC instead, but I don't like it...

The internal encoder is seperate from the executable, and regardless of whether you use the lame.exe from audiograbber, eac, or directly it will take the same amount of time. As discussed earlier, the executable has more to do.

Is this correct? I edited audiograbber.ini and changed MP3QualityMode=R3MIX. I'm using the internal LameEnc DLL v3.91and had it set to CBR 160; Quality stereo, high. I did not change these settings. I then ripped the only audio CD I have here in the office (GBH; very unaudiophile ). The resulting mp3 file played in winamp starts at 160 bitrate and goes up to >230 slowly. Winamp track details show 160kbit rate. The audiograbber.ini file was changed such that CodecMode=160 Kbit/s, Stereo, R3Mix quality. File size = 6.86MB.

Went back into the internal encoder settings and changed it to VBR, MTRH, slider set to VBR 1. Reripped one of the tracks and now winamp reports it as a VBR mp3 (232kb). File size is 6.83MB. Sound quality difference is impossable to tell; it's GBH and I stuck with laptop speakers right now.

Am I fubar'ing the settings or just missing more info? I'd prefer to know how to set up the internal encoder LAME settings for AG to take advantage of the r3mix settings (is this what the original poster implied for this tread?)

Thanks for any help you can offer. Cheers!
Dave

There are "exact" instructions on the audiograbber forum. I remember reading the original thread on the subject.

BUT. Just use the command-line lame.exe as an external encoder. You just need to set it up once and then forget about it.

Bruno

It's possible that in your first case all the settings were fine, except for some reason the VBR header didn't get written to the file. The symptoms you describe sound a lot like what WinAmp does on a VBR file that doesn't have the appropriate header. I'd use some tool like VBR fix to fix the header, and then see what WinAmp says when you play it.

Thanks, I spent a hour or two searching for the "exact" instructions in the AG fourm, but came up empty handed. I did however Bruno find some of your posts on the subject and you convinced me that it was time after using AG for years now to stop using the internal encoders and start feeding CL instructions to lame. I started investigating the --r3mix options to understand what they do better. The lame documentation is missing a lot of the parameters (It is fine however for your average users). After spending too much time on r3mix.net, I understand why to use the string Bruno lists above and I tried using it, only I used the -V1 setting instead of -V0. I didn't want to blindly use --r3mix or --alt-preset; if I'm going to figure this stuff out, I'll type it all out and ensure it's what I want thank you!

The resulting file sizes as compared to the 160CBR files are a 1.25x bigger and sound the same, but then again my source material is still GBH (I have good headphones this time). I'm about to rip my 700+ CD collection and I want to do this only once. I'm just going to trust others on these settings since I don't currently have the right equipment right now to do a proper evaluation.

FWIW, winamp 2.78 still has no clue as to whether the file is a CBR or VBR. Doesn't matter though as it plays it fine.

Regarding AG external encoder setup, I enabled the options for using stdin/stdout and for use encoder as internal encoder so I can do direct rip and encode. It works; is there any reason I should not configure it this way?

Thanks again for all of your help.
Cheers!
Dave

Glad you got some info.

Don't use STDIn/Out in AG. If there's still a bug in the current release (that I found while beta-testing 1.81) then you will probably end up with bad headers. I'm only using WinAmp 2.77 but it identifies the tracks properly for me using LAME 3.90 with the options I posted.

My MP3 tab is set simply to use external encoder, path to LAME specified, User Defined Arguments selected, and then the options to pass to LAME. I also set the option to minimize the launched console window.

Bruno