Support gapless MP3 playback

[valadaptive]

The MP3 format has an inherent delay due to the MDCT + polyphase filterbank, and encoders may add their own delay.

While determining the encoder delay isn't possible for every MP3 file, LAME includes an extension to the Xing info that explicitly lists the encoder delay.

I have a (work-in-progress) branch that parses this delay field and offsets the timestamp. However, Mediabunny really doesn't seem to like negative timestamps; despite the documentation explicitly saying that timestamps may be negative, there are a ton of code paths that assert that they aren't. This would also require API consumers to explicitly notice and trim the delay themselves based on the timestamp.

An alternative approach would be to automatically trim the leading and trailing samples in the decoding step. This has the downside that we'd have to do it for each combination of codec and container, but would avoid pesky negative samples. It would also better handle trimming of trailing samples in general; I'm not sure what actually happens if the advertised duration of an audio packet is shorter than its actual sample count.

[Vanilagy]

This is part of the broader theme of having Mediabunny correctly compensate for audio encoder delay across all containers and codecs. Once I address this issue, it'll hopefully be fixed across all codecs, including MP3. Yes, adding negative timestamp muxing support will be one part of that solution.

For MP3, I'll need to see if I'll make it emit the first samples with a negative timestamp or simply trim off or not emit the priming samples directly. Right now, priming delay in ISOBMFF is compensated for with negative timestamp offsets, so for consistent, I'll probably go for negative timestamps in the MP3 case as well.

[Vanilagy]

Could you send me a demo MP3 that has such LAME field?

[valadaptive]

Here are CBR and VBR MP3s with an encoder delay (leading samples to trim) of 576, and an encoder padding (trailing samples to trim) of 1624:

narrative1_128.mp3
narrative1_V6.mp3

Here's one with an encoder delay of 528, and a padding of 1672:

narrative1_128r.mp3

There's a "specification" for the LAME tag, but I'd take it with a grain of salt. In particular, the byte offsets seem to be inaccurate in some cases (and will vary depending on which Xing header fields are present).

What decoders seem to actually do (and what I implemented in my branch) is:

1. Check if the LAME extension to the Xing header is present, by checking if the first 4 characters of the "version string" are "LAME", "Lavf", or "Lavc".
2. Read the 3-byte gapless playback field, which contains the delay and padding as 12-bit fields within it.
3. Add the 529-sample inherent decoder delay to delay, and subtract it from padding. Notably, even though this 529-sample delay is present in all MP3s, decoders seem to ignore it unless a LAME extension is present. This means that even if the gapless playback field is all zeroes, the presence of the LAME extension should still cause 529 samples to be trimmed from the beginning.
4. Trim delay samples from the beginning of the audio, and trim padding samples from the end of the audio.