When I encode using lame 3.92 with the following cmd line opts:

--abr 256 -m s -h --nogap

I get an additional mp3 file in the target directory named somthing like "tmp4(mp3.mp3". The intended mp3 file is created ok, and sounds fine. The additional file sounds like pink or white noise and seems to always be a small fraction of the intended file. I have the same results with EAC 0.9pb11 and EAC 0.9b4 with WinXP Pro Corp, native SCSI interface (although the ripper shouldn't matter).

Anyone have this experience?

Also, I cannot find the --nogap defined in the usage.txt for 3.92 but everyone discusses it's use. I haven't noticed any errors or warnings in the command window, although I haven't explicitly looked for any either.

Cory

--nogap is what is causing the extra "tmp" mp3 files. In my experience, this happened when another program (for example, EAC) called LAME to encode a WAV file that it had just extracted. This only happened to me when I was using EAC to call LAME and only when --nogap was enabled.

As for why there is no information on the --nogap parameter in the LAME documentation... I couldn't tell ya.

Well, that... that.... that just sucks.

Anyone know of a EAC/lame combo that doesn't create/leave this file around? If not, I will start trying different combos and report back...

Cory

You can just not use --nogap. I know that will take care of the problem. But it was never an option for me. But, since I haven't many CDs left to rip and encode, I'm simply running LAME manually for each CD after it has finished ripping. I don't mind the extra time to make sure it comes out right.

When I encode using [EAC and] lame 3.92 with the following cmd line opts:

--abr 256 -m s -h --nogap

I get an additional mp3 file

That's because using --nogap changes the interpretation of the rest of the command line. That is, with --nogap all filenames on the command line are assumed to be input files (as opposed to one input, and one output file).

This confuses EAC something chronic; the additional mp3 file is likely to be the result of "re-encoding" the first mp3 file under the mistaken impression that it's a wav file.

If you want to use --nogap, you must do so by running Lame from the command-line yourself, not from EAC. Read that whole thread I linked to for more gruesome details. Edit: Also read this.

Peter

Not only that, but since EAC calls LAME on each file individually rather than doing it an album at a time, --nogap does nothing at all to remove gaps. --nogap depends on having the whole album available so it can figure out the best placement of the frame boundaries, and EAC won't wait until it's all done to do the encoding step. Much to my chagrin.

There must be some front ends that can call lame without leaving this !@$&@? (translated: most irritating) file behind. Anyone out there batching with the --pregap option? What front end are you using?

Cory