Gapless playback is an idea I've been kicking around for some time.  At some point it will be introduced, but some major changes to the threading playback system would have to happen, which I'm not currently prepared to undertake (I'm currently drowning in bug reports). Sorry guys... hopefully by 1.0.

Because gapless playback requires a little more than just overlapping the tracks. Unfortunatly it seems that when you encode to mp3 a little silence is always added to beginning/end(?) of the track. This means that the player needs to search for this silence and then skip forwards to where the sound starts. Anoying or what!

DiGiTaLFX is correct, you have to add code to read the LAME header for MP3's and use info contained in it to eliminate the gap that gets built into the MP3 itself.

You also have to handle the streams somewhat differently than it handles them now (currently it creates a new playback stream for every song), and that's somewhat problematic with regard to format plugins and such.

DiGiTaLFX wrote:

Surely this has no effect tho! As long as the code knows where the gap is in relation to the two songs, it can just start the second one (as a new stream) from the correct place as soon as the "end" of the first one has been reached. I only say this because I assume that when the crossfader comes into action, it plays two streams at once and just fades the old one out whilst fading the new one in.

It can have an effect, although it might not. Basically, when a song ends, the old stream is deleted, the new one is started, and playback begins. If this process happens fast enough, you'd never notice any gap, but if there's a delay between removing the old stream and adding the new one, you'd have an issue.

The crossfader causes the new stream to start before the old one finishes, whereas with gapless we want the new stream to start at the exact moment that the old one finishes, which takes some doing.

DiGiTaLFX wrote:

So if you know all this information, then you could just start the new stream at the right time. I don't really know much about doing this, so I can only assume that the problem would be that you can't predict when the new stream will actually start?

Right. You can do it, it's just not particularly simple. Starting playback on a channel involves some latency before playback actually starts. In order to eliminate this latency issue, you basically must never actually stop playing data. When the stream ends, you have to keep going with the next stream without stopping and restarting.

Essentially, you can do a BASS_StreamCreate and feed it a callback to your own decoder function. This function will basically take a look at two different open BASS_Streams and return decoded data from one of them to play, using BASS_ChannelIsActive() to tell if there's decoded data left and BASS_ChannelGetData() to get that data into a buffer. You can also put in patches here for ignoring certain bits of data (beginning and ending of a MP3 file) to ignore inserted silence due to encoding.

Anyway, when the stream ends, this callback function switches to the other one instead. Then you have your playback functions call another function to swap the two streams and open the new stream with the new file.

This sort of thing prevents you from having to close the stream or stop the channel playback, eliminating that latency problem. It's buffering everything through a single stream which is always "playing", essentially.

You also will need to change how you get the played time and such so as to ask the current stream instead of the actual playing stream (since that stream is always playing) and essentially you have to abstract a whole lot of stuff to account for this weird mess. This also makes it tricky for a format plugin that doesn't use built in BASS decoders to work. Not impossible, just trickier. Some thought has to be given to the decoder there because now you're going through two callbacks instead of one, so the first callback has to be really, really fast in case you don't have a lot of buffer time left.

Anyway, it can be done, but it'd take some time to do and it would also substantially change the way format plugins work, so those would all break as well.

Last edited by Otto (2005-04-27 13:39:16)

But im not even getting gapless playback on streams that I know have no blank data at the start or ends, as ther ogg vorbis, and iv looked in soundforge. They even burn gaplessly in nero (knowing how notoriously bad at gaplessnes it is)

HuwSy wrote:

But im not even getting gapless playback on streams that I know have no blank data at the start or ends, as ther ogg vorbis, and iv looked in soundforge. They even burn gaplessly in nero (knowing how notoriously bad at gaplessnes it is)

Gapless has not been implemented in musikCube yet, which is why you're not getting gapless. I was just describing how it could be done and why it's slightly complex.

Yep, that's sorta how it works. If you want to work on it, talk to Casey, I'm sure he'd be glad for any help.

Just to voice more support for gapless playback--

I was a foobar2000 user, but I needed better database capabilites. I even tried writing my own universal music database frontend in Java (see http://jmediacat.sourceforge.net) but I wanted to see what else was around.

I found musikCube, and love it, but not having gapless playback is a huge drawback. I don't know how all of those iPod junkies can live without it, but I can't.

I figure the more people that ask for gapless playback, the more the developers will be motivated to implement it. There, I'm done ranting. Keep up the great work on mC, otherwise.

Yeh you know if it was possible to implement this for cd playback (i presume this is handled in a slightly different way to files from hard disk ?) then this would be a good idea.

ah well mC 2.0 for sure then

Yes me too, live audio sucks wihtout gapless