When I try using --alt-preset standard under LAME it just skips the compression and rips the next track. But If I use a CBR or ABR code it works fine. Am I doing anything wrong?

Using LAME 3.90.3 from the Hydro forums with Audiograbber.

Are you positive your parameters are in the correct syntax?

Here's mine that I use w/ EAC...

--alt-preset standard --id3v2-only --pad-id3v2 --tt "%t" --ta "%a" --tl "%g" --ty %y --tc "EAC: Lame 3.92 @ alt pre std" --tn %n --tg "%m" %s %d

Yours looks good...

(things that make you go hmmmm)

xen-uno

Get the same problem using EAC aswell (which I have just spent 30 minutes setting up using the toutorial)

It will compress if I use --alt-preset standard %s %d but that's at 128 kps.

My configuration in the Compression options is:

Parameter Passing Scheme: User Defined Encoder

Use file extension: .mp3

Program, including path, used for compression: C:\Program Files\Lame\lame.exe

Additional command line options: --alt-preset standard --verbose %s %d

The rest choose what you like, except Use CRC, that should be left unchecked.

EAC extraction logfile from 28. May 2003, 21:09 for CD
Machine Head / The Burning Red

Used drive : PIONEER DVD-ROM DVD-106 Adapter: 0 ID: 0
Read mode : Secure with NO C2, accurate stream, disable cache
Combined read/write offset correction : 0
Overread into Lead-In and Lead-Out : No

Used output format : C:\Program Files\Audiograbber\lame-3.90.3\LAME.EXE (User Defined Encoder)
192 kBit/s
Additional command line options : --alt-preset standard

Other options :
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Native Win32 interface for Win NT & 2000


Track 1
Filename C:\Documents and Settings\Trash Man\My Documents\Machine Head - Enter The Phoenix.wav

Peak level 52.0 %
Track quality 100.0 %
Copy CRC 36715389
Copy OK

No errors occured


End of status report

That's the info but still no compression

Additional command line options: --alt-preset standard --verbose %s %d


When I use that it compresses to 128kps, is that right?

Also if I try and use --alt -preset insane I still get no compression

--alt-preset cbr 256 works fine as do all the abr codes. Is --alt-preset cbr 256 better than --alt-preset standard? and do I need to add the -Z after it?

Using --alt-preset standard %s %d it works fine, I thought it was only encoding in 128kps but that was just the average for the test track I was doing.

Is there anything else I need to add to the command line before I start ripping my entire CD collection?

I did try a few of the other quality rips, and tbh I could not tell the difference between --alt-preset standard %s %d and --alt-preset extreme %s %d or --alt-preset insane %s %d so I think I will just stick to the standard one.

What does the --verbose do?

And should I use normalzie? or should I use MP3gain afterwards?

Many thanks for any help and thanks for helping me find EAC

--verbose shows you in the DOS (Command Prompt) window exactly what it's doing. Has nothing to do with compression.

MP3Gain is a MUCH better solution than normalizing. Do a forum search on it for more info.

Maybe your LAME compile is corrupt. Download ver 3.92 and try it (as good as any LAME version...though not tested as thoroughly as 3.90.3, for instance). I'll bet it will solve your problem.

xen-uno

Thanks again Xenno, I will give it ago.

Has anyone else had this problem? because I got my version of LAME 3.90.3 from these forums.

Just tried using 3.92 with --alt-preset standard and I still get the same problem. Just reading through the EAC toutorial for using with LAME and it says...

Now what's the use of the %s and %d parameters in the command lines? They were not present in older versions of EAC and are nowhere described in the LAME manual. The %s and %d stand for source and destination file respectively. Since we use the User Defined Encoder Parameter passing scheme in EAC instead of the LAME MP Encoder, it's necessary for EAC to know where LAME accepts the source and destination file in the command line. If you select LAME MP Encoder from the Parameter passing scheme dropdown box you may omit the %s and %d.

So how come it works for everyone else without the %s %d

Also is it ok to use my computer while I am ripping or should I leave it alone? I don't mean anything like listening to music or playing games but just surfing the web.

A few ideas (sorry if some of them appear too simple/basic, but everything else seems to be OK):

- Are you sure your files are 128kbps? Who says so? To be sure I'd recommend using Encspot or do a calculation like this:
(Song length [seconds])*16KB/s=(File Size[KB]). This should be roughly correct for 128kbps (not taking into account headers, tagging...), so if you get other numbers, your player shows wrong bitrate values.

- Your EAC log shows a peak level of 52.0%. So the recording seems to be low volume which could cause low bitrates. Do you get 128kbps as well if you record recent charts music or if you use --alt-preset extreme %s %d or --alt-preset insane %s %d ?


It'll slow down encoding, but if your system is stable (no heat problems at full load etc.) it's no problem.

There not 128kps, the reason that was happening was because the track I was using was a intro track and not really a song as such, that was also the reason for 52% peak.

Everything is fine now, I just had to put %s %d afterwards for some reason to get it to work.

The quality of --alt-preset standard is excellent.
Mp3gain is also excellent, and especially accurate in Album Gain mode, so I'd say go forth and rip!

%s and %d are specific to EAC's user defined encoder functions. EAC has to tell the encoder which temporary WAV file to read and which temporary MP3 file to write. When the encoder has finished, EAC renames the MP3 file and deletes the WAV file.

EAC will actually replace %s with a bit of text representing the path and filename in question, such as c0123456.wav, when it sends the command to Lame

If you left off the %d, lame would write c0123456.wav.mp3, but EAC would expect to see c0123456.mp3 and then try to rename it, but couldn't find it.

Because %s and %d are not recognised by Lame itself, people don't specify them when saying how they encoded. If you used a ripper other than EAC, you'd use something other than %s and %d.

EAC can also pass other information to Lame, and although I normally use Musepack (mppenc) to encode MPC, not Lame to encode MP3, when I use Lame I also get it to tag my files with title, artist, album, tracknumber, year etc. (For that reason I turn OFF EAC's add id3 tag option, because Lame is doing it for me). It uses id3v1.1 tags when possible, but if any field are over 30 characters (28 for the comment), it'll use id3v2 header-tags instead (which go at the beginning of the file and causes problems for some players). I use Foobar2000 player which can read id3v2 header-tags, but won't write them (it writes ID3v1 and APEv2 tags instead).

In each case, EAC expands the %t or similar into a string of characters such as "Enter The Phoenix" and sends that text to Lame, so it will correctly tag the song.



I'd say this is great for ripping almost all your albums, so long as you've set up EAC for secure mode. If you plan on doing a big ripping session, it might be wise to look at the list of offset reference CDs and set your drive offsets, in case you're finicky enough to not be satisfied with tracks that start and ends a few milliseconds to early or too late and cause yourself to go back and re-rip everything. (Most CD pressing plants aren't even that finicky)

The exceptions are albums with no gaps between some of the tracks, such as live albums and DJ mix albums. For these you need gapless ripping. Formats like Musepack and Ogg Vorbis are intrinsically gapless, so there's no problem, but MP3 and MP4/AAC aren't gapless and you might be forced to use them for compatibility with a portable player.

If you absolutely need to use MP3 (e.g. to use on a portable MP3 player) this gets complicated. You can either rip the whole album as one giant MP3 with CUE sheet, but most portables won't then allow jumping or shufffling from track to track, because they don't recognise the CUEsheet so see the album as one long track. The other options involve a hack of some sort to split the MP3 without gaps. You either feed the giant MP3 plus CUEsheet through a program like musicutter, or you encode from a CD image plus CUEsheet using Lame 3.90.3 with cuesheet support, which encodes multiple files without gaps pretty darned well. I posted about this yesterday. With VBR this tends to break the correct track length display and seeking-within-track behaviour in most players. This might not be a problem for you, so it'll be fine.

If you only play on a PC, then mp3splice plugin for Winamp v2.x and foo_nogaps Gapkiller for Foobar2000 will allow albums ripped as standard individual files to play gaplessly with amazingly good quality - but that's not the case for portables.

My preference (because of the gapless problem and because I don't have an MP3 portable) is to use Musepack standard, plus --xlevel to prevent clipping in the encoding. It has proper taggging with built in replaygain tag support, it's gapless and it's even better than Lame APS at sounding identical to the original CD (audible artifacts are even rarer). As a bonus it's faster to encode than LAME APS and produces smaller files too! So I can simply rip all my CDs - live, mix or normal - in the same way:


The mppenc v1.14 encoder uses different switches to lame such as --artist instead of --ta, but EAC still uses the %a replacement variable to pass the information to the encoder. (I use Foobar2000 to scan each album for ReplayGain info after ripping). Also, for mppenc, it's not strictly necessary to specify %d, but it does no harm.

Although I use mppenc now, there are still albums I haven't re-ripped, and I enjoy them immensely as Lame --alt-preset standard MP3s.