I've read all the recent threads, and about as many of the old threads as I can take, and I decided to go with the following for my Pink Floyd rips because it seems to be the easiest process:

- Extract all the tracks to wav files using Exact Audio Copy.
- Use WinLame with Lame v3.92.
- Choose all the wav files, and use the predefined preset "alt-preset: standard + nogap"
- Run all the resulting mp3 files through vbrtagger (http://www-public.tu-bs.de:8080/~y0010858/mp3lister/) to generate a Xing header.

After finishing these steps with "Dark Side of the Moon", I uploaded them to my empeg (without adding any ID3v2 tags). When I listen to two consecutive tracks, I still hear an extremely brief gap between them. It's nearly inconsequential, but it's there. Is this the best one can do? Can someone point me to some mp3 files that have been properly encoded using -nogap in Lame, so I can compare?

A few related questions: does the ID3v2 tag offset affect gapless playback? What is the most frequently used offset?

Although the tag should not affect gapless playback, I've heard rumors that VBR will screw it up.

Just as an experiment, take that set of wav files and encode them all on the same command line (all on the same command line simultaneously is one of the requirements for the nogap parameter to work) with NO OTHER PARAMETERS other than --nogap. Don't tag them, don't VBRfix them, don't do anything other than just run them through lame with nogap. Then squirt them into the player.

See if that works. The end result will be that lame uses all of its defaults which I think is 128kbps FBR.

If that works, then try changing one thing at a time in your procedure, re-encoding and re-testing each time, until you find the one thing that breaks it. Then report back here.

tony are you suggesting:
lame --nogap track1.wav track2.wav....etc
if so what does lame the encode to?

Also, http://mitiok.cjb.net/ has CLI binaries of lame for Windows. There is no real difference between it and Unix versions. It's pretty much just the same sources compiled for Windows. My point being that if you think it's WinLame causing your problem, you should be able to use that lame instead of finding someone with a Unix machine to confirm or deny it for you.

tony are you suggesting:
lame --nogap track1.wav track2.wav....etc

Precisely. That is a REQUIREMENT for lame's nogap to work. It must have ALL of the wave files all at the same time in order for it to be able to dovetail the ends and the beginnings of the tracks together. Get it?

if so what does lame the encode to?

track1.mp3 track2.mp3....etc.

if so what does lame the encode to?

track1.mp3 track2.mp3....etc.


I ment was what type of MP3s will this produce?
CBR-128? Is that the Lame default?

Right.

- Extract all the tracks to wav files using Exact Audio Copy.
- Use WinLame with Lame v3.92.
- Choose all the wav files, and use the predefined preset "alt-preset: standard + nogap"
- Run all the resulting mp3 files through vbrtagger (http://www-public.tu-bs.de:8080/~y0010858/mp3lister/) to generate a Xing header.

My results:
testing for audible transitions between two files (Jesse Colin Youngs' Lafayette Waltz -> Jambalaya)
Lame 3.92 | Win98SE | EAC wave file rips.
Anytime --nogap was used, Lame issued a message about Xing VBR headers being disabled - even when doing cbr.
Inputs using --nogap file1.wav file2.wav (single spaces between arguments)
outputs were file1.mp3 file2.mp3
All listening tests on the player.

1. lame --nogap walt.wav jam.wav
128kbps CBR. Both with or without artist/title tags, I could detect a minor (almost inaudible) blip.

2. lame --alt-preset insane --nogap walt.wav jam.wav
320kbps CBR. Same as #1.

3. lame --alt-preset 192 --nogap walt.wav jam.wav
192kbps ABR (average bit rate). Slight blip. Track time inaccurate due to missing Xing header. Adding Xing header with VBRTagger fixed track times, but made a very noticeable gap.

4. lame --alt-preset cbr 192 --nogap walt.wav jam.wav
192kbps CBR. Same as #1 and #2

5. lame --alt-preset standard --nogap walt.wav jam.wav
HQ VBR. Least noticeable blip. Usually did not notice it at all. Track times bad of course. Adding Xing header made a noticeable gap. Adding artist/title tags did not affect anything.

My conclusions;
Lame's --nogap removes Xing headers for a good reason. Adding them back in to fix the track times totally defeats the --nogap function.
While my results were best with --alt-preset standard VBR encoding*, I'm not sure that I want to live with the screwy track times.
The absence or presence of ID3v2 tags does not seem to make a difference.
That leaves using CBR. I would go with CBR in a fairly high bitrate mode, and using the --alt preset cbr xxx format in example #4.

* I was surprised by this. I had assumed from my readings on the board that VBR would cause a problem. That may still be true, but not for the sample files I worked with.

As your example shows, only the Xing tag for VBR causes the problem, not VBR itself. I also didn't want to accept the screwy track times. But I definitely wanted --nogap. So I'm sticking with CBR. To date, out of 54 CDs ripped & encoded, there is only one transition that is not smooth (TOOL's Parabol to Parabola) on the player. I have been thinking about merging those two into one file since I never want to listen to one without the other.

I have always used music match jukebox ver.4.35 to encode my mp3s I encode them at 192kbps cbr, I have 5 pink floyd albums that I have encoded on my empeg and I almost can't hear any gap, I have to listen very hard and I am picky about this kinda thing. The ver. of music match that I use came with the old sound blaster live card that had the live drive, maybe there is somthing diferent in this ver. Also the nero burning rom program has a nice mp3 editor you could cut out the gap manualy

Thanks for this detailed report. I am updating the FAQ entry on this topic with this information now.

In the FAQ, it might be useful to point out that a variation of the --alt preset settings can be used.
--alt preset cbr 192 uses the key settings but forces encoding at 192 CBR.

Much better, I think, than leading people to use just the --nogap option which defaults to 128, or the --nogap with only a higher bitrate.

More on this can be found here:
http://www.hydrogenaudio.org/forums/showthread.php?s=&threadid=260&highlight=preset+standard
(this might also be a good faq link)

OK, working on it now.