I've been building up quite the collection from EMusic as of late. Some of the albums I've got are intended to be played continuously, without gaps.

When burning these to CD I'd like to eliminate the in-MP3 gaps. I'm looking for more information on them, or maybe even a tool someone's already built to take those gaps off. (I am a fairly competent Python programmer and can use pymad to decode, if I have to build my own tool.)

Where exactly do they come from? How long can they get? How loud are they, so I could somewhat reliably strip silence? Are they at the beginning, or end, or is that encoder-dependent?

Yeah, I know I could also just load the decoded WAV into an editor and chop, but I'm looking for a general purpose solution here. I have a lot of these babies.

To create a continuous output:

The typical "solution" for this is to have a buffer of a certain length, decode 'til the end of the MP3, and analyze the data in the buffer. Processing at the end first, work back until you get to a peak of a certain magnitude (such as -50dBFS). Perform similar processing on the beginning of the next MP3, then line it up so that the two -50dB peaks coincide and then mix the two streams together.

From there, you need to make a CUE file to hold all the index infos and things. I'm not as knowledgeable about this, though; hopefully someone else in the forum can contribute.

I hope that was clear and cogent; if you have any questions, ask.

Edit: several points of note:

• MP3s are not inherently a gapless format. The fact that samples were removed due to encoding/decoding may be audible.
• -50dBFS is just a guess, really... I forget where I read that.

Alternately, foobar2000 will do this step for you, with the dsp_no_gaps plugin, and will decode to a WAV file. I'm not sure whether or not the Audio CD burning plugin is gapless. If it is (ought to be easily testable, at the cost of a coaster or a CD-RW format), you ought to be able to do this all without even coding anything.

Just ensure you have the following settings enabled:

"No Gaps" DSP enabled (or whatever it's called; I don't use it.)
ReplayGain mode set to "Album" if you're using ReplayGain.

Under the Audio CD writer config:
Use DSP
Don't reset DSP between tracks

Edit2: Furthermore, the options used for the Audio CD writer need to be used with the diskwriter for gapless WAV file creation. Bleh. It will require concatenating the WAV files as well. I don't see any "Make one WAV file" option there.

You could try to contact this guy, he nailed the problem long ago. Too bad diskwriter support remains to be seen.
Maybe he'll tell you his secret, maybe he won't.
I don't think there's nothing to lose.

The gaps are introduced by the encoding process.
However, encoders such as FhG (using VBRI header) and Lame (using LAME header) are storing the encoder delay and padding values.
So if you are a programmer, you can read those values and use them to remove the extra samples in the decoded file.

Canar:

Your strategy is pretty much what I ended up hacking on over lunch yesterday, although guess I'm at a loss as to how to calculate dBFS; I used a strategy of checking that both L and R channel values were within a range (-512, 512) instead, kind of like xmms-crossfade does.

Right now my script seemed to do well on a test album, but I neglected to make sure that the tracks were multiples of 588 samples (which is what cdrdao's manpage says audio tracks need to be), so they got padded by cdrdao and I got brand new gaps. Now I have a better strategy, but my math is off somewhere ATM so cdrdao is running out of samples in the middle of the last few tracks. Should be easy to fix. FWIW, in the album I tested with, my script identified exactly 1105 samples of silence in each track. They were LAME-encoded so I should compare them to the tag.

I should also mention that I'm not a Windows user, so I'm not going to be able to use foobar. But thanks anyway for that bit.

AtaqueEG:

Thanks. I've sent the author a mail asking for more info.

Gabriel:

I've seen info on the LAME tag before but never noticed this bit. Is there a canonical source for LAME tag info, or is the one at your site (that is yours, right?) the definitive copy? Google's turned up other, older ones, too.

Maybe you can also help me with another question in this regard -- is there anything in the encoding process that would cause a track that should have originally come from CD to have (after stripping of the exact number of samples mentioned in the tag) anything other than a multiple of 588 samples, which is apparently a requirement for a CD audio track? After stripping silence the hard way yesterday, it seems the total number of samples varies quite a bit from a multiple of 588. That could be an artifact of the ripping process, or even decoding, I suppose...

Thanks, everyone.

The one from my website is just a draft, but it is the most up-to-date.
You can use it to have info tag specs. One thing to correct is that it is tag rev0 and not tag rev1.

The delay can change between encoders, but they all introduce a delay. Moreover, some decoders add an additionnal delay, but most of them are removing the samples introduced by themselves.

Right, but if I take a source with x samples, encode it with, say, --alt-preset standard, then take the resulting y samples and subtract the number of samples specified in the encoder delay field, should I end up with x samples again, or might it vary for some reason I'm not clear on?

You will have x samples again

Sometimes, yes. You don't seem to even have tested it yourself, and lame.exe apparently doesn't remove samples padded at the end of file when decoding. I haven't been able to produce code which reliably tells original source length from a lame 3.90.3-encoded mp3 file.

No, Lame doesn't properly removes gaps when decoding.
But it should still be possible as the delay and padding are stored into the file.

Yeah right. "samples_per_frame * total_frames - (enc_delay + enc_padding)" DOES NOT match length of source file and gives random error depending on file used.
Also, enc_delay is always set to 576, while actual number of samples that need to be removed is 1105, which LAME nicely handles by adding (528+1) to the value read from the header. How do you explain that ?