[Lame-dev] --nogap "quality decrease"? and nogaptags & decode issues

[Mike B. <mi...@sk...>]

Hi all,

I'm not a developer, just an interested user. I'm going through all the 
different software-based "gapless" MP3 encoding & playback procedures in order 
to figure out what works and what doesn't, and why, and what shortcomings 
there are with what does work.

When I got around to trying out lame --nogap, I was disappointed that so 
little info about it ever existed. I wonder if it would've been more widely 
tested and supported if it had been better documented. Probably that ship has 
sailed, so I'm not trying to encourage its further use, don't worry... 
mentioning --nogap on the HA forums is like trying to talk about Fight Club, 
and I also realize that Gabriel Bouvigne has been vocal about ditching the 
feature altogether. Nevertheless, I want to acknowledge and better document 
it, as the theory behind it is basically the same as one of the common methods 
of producing MP3s ready for kinda-gapless playback (concatenate the input WAVs 
and encode one big MP3, then split on frame boundaries, and hope that the 
files are joined before/during playback).

One of Gabriel's complaints was that with --nogap there's "a potential quality 
decrease at the beginning and at the end" of each file[1] and he claims that 
using delay & padding values from the LAME tag "is way more elegant, and at 
least it does not reduce quality of individual tracks (unlike --nogap)."[2]

The current documentation describes --nogap thusly:

  "Encodes multiple files (ordered by position) which are meant to be played 
gaplessly. By default, LAME will encode the files with accurate length, but 
the first and last frame may contain a few erroneous samples for signals that 
don't fade-in/out (as is the case of continuous playback). This setting solves 
that by using the samples from the next/previous file to compute the 
encoding."

Gabriel's comments seem to contradict the documentation. I was unable to find 
any explanation of the quality problems he was referring to. He seems to be 
saying the problem is with the way the files are encoded, but that it 
manifests only when playing them back separately. Is it related to the bit 
reservoir? (Is the reservoir flushed by the last frame?) Or is it really just 
a decoding issue? - Like, the decoder doesn't have access to frames from 
adjacent files when playing the files separately, so even though good data is 
encoded, you get some different samples in the output than you would get when 
decoding the same portion of the concatenated input? That kind of problem 
wouldn't be unique to nogap files, though, so it wouldn't be solved by using 
delay & padding values from the LAME tag instead of --nogap. So just I don't 
understand what he's talking about.

In my experimentation and research, I also ran across what I think are 2 bugs 
that I want to ask about:

1. There seems to be a bug in --nogaptags. When the LAME tag is written, it 
declares the encoder delay to be 576 for every file, but after looking at a 
set of decoded nogap MP3s (decoded using lame --decode --decode-mp3delay 
-529), it seems only the first file has this delay. The rest have 0. I believe 
Gabriel Bouvigne asked about this[3] in Oct 2001 but nobody responded.

The 576 declared encoder delay in all but the first file is a mistake, right? 
Or am I not understanding something?

2. When lame --decode is fed an MP3 whose LAME tag accurately declares the 
padding to be 0, the decoder correctly leaves the end unstripped, but it also 
seems to append 529 samples of junk, like some kind of buffer getting flushed. 
One channel is some noise followed by silence, the other is a bit of signal. I 
expect the decoder to either not do that at all (so the output should be 529 
samples shorter), or for the 529 samples to be good data decoded from the last 
frame (maybe with the help of a dummy padding frame).

More generally, what output should be expected when the padding is less than 
the decoder delay? If I understand correctly, the # of 1152-sample blocks of 
output has to match the # of frames of input, so the decoder delay effectively 
makes the last samples of the last frame unreachable, and that's why it's 
normal to encode at least that much padding on the end - you won't miss it 
when it "shifts out".

But if there's less padding, it seems to suggest that there's an expectation 
that an inversely corresponding number of additional samples are required in 
the output. (529 samples for 0 padding, 528 for 1, ... 0 for 529). To get 
reasonably correct samples, if a frame from the next file isn't available, I'd 
just append a silent frame to the input stream, then pretend the padding was 
declared to be 1152 samples higher than it was actually declared to be, for 
stripping purposes. Is doing that actually forbidden? Is there a reason not to 
do it?

Thanks for your time,

Mike (mjb2006 on the HydrogenAudio forums)

[1] <http://sourceforge.net/mailarchive/message.php?msg_id=9923039>
[2] <http://www.hydrogenaudio.org/forums/index.php?showtopic=16020&view=findpost&p=211791>
[3] <http://sourceforge.net/mailarchive/message.php?msg_id=4771409>