As a test, I just re-encoded The Wall, disc 1 with LAME 3.90 and upped it to the empeg.

The --nogap encoding actually seems to work very well. A very small, almost inaudible click is all that I can hear, but there are no perceptable pauses.

When encoding using --nogap and --r3mix (high q, vbr), track times are not always correct (tracks 1 and 7), and seeking backward through a song to a previous song sometimes skips backwards a couple of songs. This does not seem to happen using CBR 192.

I ran it from the (Win2k) command line using either the --nogap and --r3mix, or --nogap and -b 192 options.

Has anyone else tried 3.90 and --nogap yet?

Merry Christmas & happy holidays to all!

I hadn't tried yet but now that you've mentioned it, I will. Even without re-encoding with --nogap, I've noticed the skip between songs has decreased for this version. In the previous version there was a slight skip a few fractions of a second *before* the track boundary (due to some caching behavior, as I understand it.) Well now the gap seems to happen *at* the track boundary which means the player might be doing its job perfectly, and maybe it's just the MP3's that need fixing.

I am going to try to re-rip a CD or two and see how things are. But I'm already happy about the improvements in this area.

does mp3tool (http://rtr.ca/ ) fix the VBR positioning problems from lame?

Apparently the problem with jumping multiple tracks is not limited to VBR encoded files. I am having a problem with Roger Waters-Radio K.A.O.S. track 7, encoded at CBR 224. It behaves very strange - if I try to seek back, as soon as track 7 starts (< 2 sec or so) it behaves normally and continues seeking into track 6. If I wait until it is 5 or 10 seconds into the track and then seek back, it seeks back to track 6 for a fraction of a second an then skips back to track 5 and continues to seek normally.

I have made the 3 files available at http://24.184.34.6 (temporarily, anyway) in case anyone would like to try to duplicate my results...

Well, my observations on a boring Christmas Eve after the family is soundly sleeping...

*** Test #1 - MP3 files ***
Setup
Encoded tracks 2 and 3 of Pink Floyd's Echoes (our samples seem to be skewed towards Pink Floyd don't they? ). Previously I had used 128k CBR without --nogap, now using 128k CBR with --nogap. The first set (without nogap) have ID3 tags, the second do not.
2.0b3 behavior
Gap was pressent between MP3's without the --nogap option. I toyed with the --nogap while running 2.0b3 but I gave up on it when I heard that there was skipping/gaps for other reasons (player bug.)
2.0b7 Results
I notice no difference with --nogap at all, at least no beneficial one. If anything, the gap might actually be a little more with the --nogap. Why this might be is anyone's guess. Since --nogap is undocumented and doesn't provide any feedback or anything, it's hard for me to say whether it even did anything to the MP3. But there are still gaps with both sets of MP3's. Keep in mind, as I said earlier, the skip between tracks got much smaller in this release, so this isn't a complaint.

*** Test #2 - WAV files ***
Setup
Sent over the WAV files to negate the effect of MP3 frame boundaries, etc. In theory if the player is doing its job, there should be *no* perceivable gap. WAV files have no headers or anything.
2.0b3 behavior
There was a skip between WAV files. Said to be due to a player caching bug of some type.
2.0b7 Results
Huzzah! Nary a gap to be heard. None at all. Completely gapless output. This is a first.

*** Test #3 - MP3 with --nogap and -t ***
Setup
Around this time I noticed during this testing that LAME adds a "lame tag" to each file. This doesn't seem to be an ID3 tag. I found that it can be turned off by adding the -t switch to LAME. So I encoded with --nogap and -t to see what happens.
2.0b3 behavior
Not tested.
2.0b7 Results
Better! Seems to be less gap than without the -t switch. It seems (from my observation) that this LAME tag widens the gap a little bit. Dunno if the "lame tag" is important, but it makes true gapless output difficult unless the decoder is smart enough to skip over it.

*** Test #4 - MP3 with just -t ***
Setup
So I thought that since -t cleaned up some of the gap problems, that maybe --nogap was doing more harm than good. Took off the --nogap and tried again.
2.0b3 behavior
Not tested.
2.0b7 Results
Gap was worse. So --nogap seems to be beneficial in some way. Using only the -t option yielded files with a larger gap than those encoded with --nogap -t.

Conclusions
1. LAME --nogap isn't ready for prime time.
2. The Empeg player seems to be doing its job with WAV files, and assuming that there aren't any differences related to how it decodes and buffers MP3 streams, we can place the blame for that little tiny skip on LAME.
3. Adding the -t option to not automatically add the LAME tag seems to minimize gaps.
4. Adding the --nogap option on its own didn't seem to change the gap (to me anyway.)
5. Using both --nogap and -t provides the best results, but a small gap is stll left behind.
6. In 2.0b7, WAV files play without gaps *flawlessly* so LAME must be the guilty party barring some idiosyncracy in Empeg's handling of MP3 vs. WAV.


Anyway that concludes my scientific study on gap removal. Class dismissed. Time to get visions of sugar plums dancing in my head.

To take your diligence one step further, I have come up with a few similar comparisons (I don't have Echoes - yet ) using The Wall tracks 4 and 5, and captured the line in playback in Sound Forge in an effort to quantify the results. I am using 2b7 and Hijack v80.

Here's a screenshot of a side-by-side comparison of the transitions. I did not even think about trying straight wav's earlier until you mentioned it - I've got to stop thinking of it as an 'only' an MP3 player...

Here are the captured results if anyone is interested (zipped wav's, ~530k each)...
4-5wav.zip is just straight wav files. Absoultely zero gap - perfect!
4-5-b128.zip is encoded using just 128k CBR. It has a very noticeable 57 mS gap.
4-5-b128--nogap.zip is encoded with --nogap and 128k CBR. Only a 5 mS gap (barely perceptible).
4-5--r3mix.zip is encoded using --r3mix preset (high Q VBR). 31 mS gap.
4-5--r3mix--nogap.zip is encoded using --r3mix preset (high Q VBR) and --nogap. 5mS gap.
4-5--r3mix-t--nogap.zip is encoded using --r3mix preset (high Q VBR), --nogap, and no Lame VBR header. 5mS gap.

There did not seem to any discernable difference by removing the Lame VBR header. Maybe due to different source material? The gaps are apparently resulting only from the start of the second song. I tried Tony's Gapkiller to trim a few frames, but it seemed to make it worse. Anyone know a way to remove the 5 mS silence at the start of a track, or is this strictly a limitation of the mp3 format?

Good stuff! I have SoundForge as well but didn't consider hooking it in to the LineOut to get graphs. That's a nice touch. Well now we can measure the gaps as new versions of LAME come out (or as the Empeg supports new formats, Vorbis, WMA, or whatever.) If WMA files were gapless I would re-encode my entire collection (or at least the albums that need gapless.)

Tony, your testing with LAME, I'm wondering...

I seem to recall that LAME 3.90 alpha needed a bit of coaxing in order to properly do its gapless-ing job. Most notably, it wasn't enought to go:

LAME --nogap filename1
LAME --nogap filename2
LAME --nogap filename3

Instead, you had to go:

LAME --nogap filename1 filename2 filename3

That way it could do the necessary work handling the ins and outs of each file. The problem (at least when I messed with it) was that the syntax parser wasn't completely up to the task of properly handling all the usual command line parameters you normally throw onto the command line when you were doing the nogap stuff. I remember I even had trouble with certain file names and I had to pare them down to a simple track01 track02 track03 and couldn't specify the destination file names at all. I also noticed I couldn't get the quality and bitrate options to work, I had to take everything at the defaults.

It it possible you just weren't feeding it the proper command line to get it to work?

Because when I tried it, it "worked", it just wasn't yet perfect. It was better than a standard encoder, but not as good as my hand-trimmed copy of Dark Side of the Moon.

It it possible you just weren't feeding it the proper command line to get it to work?

That's possible, but the command I used was more like your second one. When I did it with just --nogap (and not with -t) it looked like this:

lame --nogap "02. Pink Floyd - See Emily Play.wav" "03. Pink Floyd - The Happiest Days Of Our Lives.wav"

Given what you said about having trouble with certain filenames, it's possible those filenames were confusing (spaces, hyphens, etc.) but really they shouldn't be. I might try tonight giving them simpler names like track01 and such.

Anyway it still doesn't seem perfect, which it should be, because WAV file output is now "flawlessly gapless" on the Empeg, very much a milestone in my opinion. Now we just need LAME to hold up their end of the bargain.

My testing was done on tracks named 01.wav or Track01.wav, etc. I never tried anything with spaces and such.

Anyway, gapless mp3 encoding/playback definitely seems to be progressing, but I may just re-rip my continuous material cd's to wav's anyway, since I have the space available (at least for now...)

Cheers!

Anyway, gapless mp3 encoding/playback definitely seems to be progressing, but I may just re-rip my continuous material cd's to wav's anyway, since I have the space available (at least for now

I'm not about to go that far, space is at a premium right now. I will await LAME's improvements to --nogap, or hope that someone else unlocks a foolproof method to create gapless MP3's. Or maybe the WMA format will bail us out, the Empeg guys claim that WMA is coming Real Soon Now. Then I'll re-rip all my continuous albums, and maybe my entire collection (I have access to a lab with about 15 PC's, so ripping all of my 300+ CD's is about six hours of work.)

Besides size, the other problem with wavs is that the drive never spins down due to the high data rate...

Or maybe the WMA format will bail us out, the Empeg guys claim that WMA is coming Real Soon Now.

I'm not about to touch WMA, but if WinAmp has a dec for it, maybe someone could try this out using the gapless playback plugin.

I have access to a lab with about 15 PC's, so ripping all of my 300+ CD's is about six hours of work.

I can just picture Tony in my head running around swapping out CDs between fifteen different computers like some deranged The Price Is Right contestant. ``Tell him what he's won, Rod Roddy!''

Running around swapping out CDs between fifteen different computers like some deranged The Price Is Right contestant. ``Tell him what he's won, Rod Roddy!''

You might think you were just being funny, but that's really what it's like! EAC has a nice option to beep after encoding, so I just listen for the beeps and look across the lab to see which one is done. It's like a chef baking 300 cakes in 15 ovens. It gets pretty crazy but that's how I originally did my rips, all in one marathon 6 hour session. Then again now that I've bought some more CD's it might be a little more, but hey, it's worse than doing them one by one for several weeks straight.

It also has an autoeject-after-rip function that I like to use in addition to the beep. I have a laptop that I keep under an ottoman in my living room that I do multiple rips with. I watch TV or whatever and when it's done, it beeps at me and I swap CDs out. Unfortunately, none of my computers has a fast ripper or processor, so my CDs take about 30-40 minutes per. Plus, it's writing the data over 802.11b onto a Samba server. Slooow.

It's like a chef baking 300 cakes in 15 ovens.

Really? Wow. I find that I spend a large amount of time cleaning up after bad entries in the CDDB. Likewise, many of my CDs (particularly the obscure-label jazz ones) aren't in CDDB, so I have to type them all in by hand. Plus, I like to get the correct years on every song in a compilation (which you can't do in EAC, so you have to do it after-the-fact with MP3 Tag Studio).

I'm figuring that I could, at best, keep four or five computers going continuously before I'd hit the wall on data entry.

I'm figuring that I could, at best, keep four or five computers going continuously before I'd hit the wall on data entry.

Well, each CD was taking about a half an hour... So let's assume one finishes up every two minutes (evenly distributed.) I'd say 10 out of those 15 will be in CDDB properly, 3 will need some touching up, and 2 will not be in at all. That seemed to be enough time to get all of that done... Obviously there was some "idle time" where a disc was finished and I was on another PC entering data or switching discs or something, but I pretty much kept 'em busy. If I have to re-rip (and I will some day) I think it'll probably take a little longer (I was using CBR before, VBR tends to take a little longer.) But it's a decent system.

I'd say 10 out of those 15 will be in CDDB properly

You're optimistic. I'd say that zero out of these 15 will be in CDDB without some need of fixing up...

I'd say that zero out of these 15 will be in CDDB without some need of fixing up...


Yeah, it depends on how picky you are.

To me, I get about that ratio (perhaps 1 in 100 discs doesn't need touching up). But that's usually because I'm picky about things like capitalization, adjusting the Genre to my liking, and making sure the Year is entered. If people don't care about those things, then the CDDB is actually quite useful.

I don't think I have ever had one that has the year filled in

I don't think I have ever had one that has the year filled in

Well, that's probably a software thing. The older version of the CDDB didn't even have a field for the year, so software that still uses the old spec won't give you the year even if it is available. For instance, I don't think AudioCatalyst will ever give you a Year field.

If you use newer software that's gracenote-aware, you should get a year filled in a lot more often.