PDA

View Full Version : Gapless playback with mp3 - another shot



Familie Tromp
2005-03-09, 17:23
Hello everyone,

I have followed the discussion in february on the development-forum and wonder why it would not be possible to playback gapless like foobar2000 does. From what I've read on the Hydrogen Audio forum (http://www.hydrogenaudio.org/) it's all a mather of calculating with values which are offered by a lame encoded mp3. Maybe it's not Slimserver which has to be reprogrammed but the Squeezebox itself since mp3 decoding begins there !

Can it be possible to ask the Slimdevices team to study on this.

Just my two cents.

Excuses for my poor english as an cheeshead from Holland,

Karel

Phil Karn
2005-03-09, 19:50
Can somebody give me some background on gapless playback? I don't
understand why it's a big problem.

With FLAC, at least, I don't seem to have any problem at all playing
tracks that flow together seamlessly. Occasionally I'll get a FLAC file
that was created with an erroneously embedded WAV header that results in
a "tick" at the beginning of each new track, but there is no actual
interruption.

Phil

Michael Peters
2005-03-09, 21:21
On Wed, 09 Mar 2005 18:50:45 -0800, Phil Karn <karn (AT) ka9q (DOT) net> wrote:
> Can somebody give me some background on gapless playback? I don't
> understand why it's a big problem.

I'll try in a non technical way.

The mp3 container has to be specific size increments, so you end up
with empty data at the end of most tracks.

The hack to make mp3 gapless is just that - a hack, it steals bits
from the next song during encode to make the file be the perfect size
to not have empty filler.

With mp3's encoded this way, some players can achieve gapless with
mp3, but it's a hack since it takes some bits from the next track to
do so.

There is some talk of putting mp3 in an mpeg4 container, which would
allow "true" gapless (no theft of bits needed) but I don't know if
players will ever support. I think winamp already does, but I think
they are one of the only ones.

--
http://mpeters.us/

Phil Karn
2005-03-10, 21:41
Michael Peters wrote:

> The mp3 container has to be specific size increments, so you end up
> with empty data at the end of most tracks.

Ah, I see. And I take it there's no field in the header that tells you
how many audio samples are *really* in the track? If you had that, then
you could just pad out the data during encode, and discard extra samples
during decode.

What is the size quanta, i.e., how much padding can be needed, worst case?

FLAC doesn't seem to have this problem; it has always produced
decompressed WAV files that are identical to the original files before
encoding, regardless of length. I presume that they have to be an
integral number of N-channel samples, though; i.e., for ordinary CD
16-bit PCM, the FLAC input stream can be reasonably expected to be a
multiple of 4 bytes long.

Phil