I know the perils associated with gapless playback... You need to either have MP3's without any metadata, or the decoder must be smart enough to skip over the metadata. Furthermore, you need to have the encoder encode on frame boundaries, like with the new LAME alphas... etc etc etc...

But having done that, there are still gaps, and while they're small, they're certainly noticable on any continuous album/mix. While I realize programming truly gapless output is no simple task, I think this is the absolute most lacking feature. Even WAV files "skip" between tracks on the Empeg.

I think it's possible to make gapless playback happen, and yeah, it's probably not easy, but Empeg has some very bright programmers. I would hope that gapless output is high on the list of priorities, and hope to see it in a future release. It's by far my #1 wish.

Gapless playback is a lot easier than people make it out to seem. However, gapless playback will not kill what some people perceive to be a gap. Frame aligning, etc. are all methods that will probably still fall short of duplicating the layout of the originals on the CD (remember that's a spiral medium where the laser just keeps playing as if you're still reading a single track). A slight pop or a bit of missing sound often isn't a case of playback, but rather the material in the file being played. Some rippers will rip extra amounts of data. Or pad with some blank space. If you have an overlap in meterial from one track to the other, then playing it back gapless can cause an audible glitch. Same goes for encoding.

For a complete "gapless" playback without the need for optimal controls in making the tracks, you'd probably be best off with a cross-fader.

The empeg plays back some of my continuous songs right now without any gap or pop. And using a good cross-fader in Winamp with some tuning gives back completely seamless playback of any continuous albums.

I'd really love a quality cross-fading implementation with a few settings for the empeg. It works really well with tunes that aren't supposed to be seamless. :)

Bruno

Well a cross fader is only appropriate for dance mixes, etc... Pink Floyd albums aren't going to sound good being cross-faded. I know some rippers don't get the exact number of bits correctly, but a lot of them do, and EAC can be adjusted with offsets, etc. to help fix any ripping errors.

I believe that if the decoder did its job, completely gapless output would be possible with MP3. Like I said, the frame boundaries would have to be done right, and the decoder would have to skip over ID3 tags, but it could be done. The gapless output plugins on WinAmp are proof of that.

I dunno about you, but with the latest alphas and some carefully-trimmed files, I'm getting pretty darn good gapless playback on my player.

Are you using vbr or cbr? What command line options are you using now?

Sean

I have a mix of VBR and CBR files made in several different encoders. Have you read the FAQ entries on this subject? I'm using my own Gapkiller software to do the trimming. The behavior of the WinAmp Gapless Output Plugin and the Empeg player is very similar, so I'm getting pretty good results with it.

Now, in 2.0b3 there's that known bug where there's a caching skip just before the end of some files. But that's fixed in later builds and the behavior is back to normal, and I get decent results. Dark Side of the Moon is nearly perfect on my player except for one slight transition between two songs.

When you said you were using the latest alphas, I thought you were referring to lame, not 2.0. Yes i have read the faq. Nice work!

Sean

Well a cross fader is only appropriate for dance mixes, etc

In general I will agree, but the cross-fader for winamp that I'm using has a ton of features and can be used with any music. I have it set in more of a gap-killing mode than a long-mixed mode which is what you'd expect with dance music. I like the results so much that I keep it set all the time.

Incidentally, all my personally encoded music is VBR and has been encoded with LAME 3.90alpha (seventh release I believe). I don't use any trimming software and my experience, even with 2.0b3 is similar to Tony's.

Incidentally, if a player causes a skip or pop because of ID3 info, then it's a poor implementation. This should be taken care of by a read-ahead cache. The header ID3, or appended ID3V1, for the next song should be parsed before the current song ends. Without some type of buffering there will always be too many variables that can affect the "gaplessness" of two songs. If you want a non-mp3, non-music example of effective buffering, ake a look at ACDSee image viewer sometime. It parses the header and reads the entire next image while displaying the current one. So when you move to the next image, pffft. It's instant.

I don't know exactly what the empeg guys have already incorporated to improve the track-to-track audible quality, but it's pretty darn good. Even going by stuff you've mentioned, to improve it significantly you will have to make sure that the audio at the end of one track does indeed match with that at the start of the next.

Of course, you can also make very long rips. And if someone were cleaver, they'd create an index within the ID3V2 framework that could be used to seek to different points within the track - obviously with software written to accomodate that feature.

Bruno

Incidentally, if a player causes a skip or pop because of ID3 info, then it's a poor implementation.

Agreed. Even with ID3 info stripped from a file, even with a perfectly gapless player, encoders still write silence into the beginning and end of files, causing skips. The lack of gaplless playback of MP3s is mostly the fault of the encoders.

Well I don't understand why any manual edits should be needed. Assuming the following prerequisites, I think PERFECT automatic gapless output should be do-able:

Ripper
You use a ripper which does exact rips of each track, and doesn't insert any kind of silence of its own.
Encoder
You use a LAME 3.9x with a properly working --nogap option which aligns the frame boundaries properly.
Decoder / Player
As the decoder gets to the end of the currently playing song, it should pre-load the next track, and read the first frames into the buffer, aligned exactly with the end of the first track. It should also skip over ID3 tags if possible (I don't know if some kind of offset is necessary or not... Maybe Emplode would have to store the ID3 offsets in the database or something, I dunno...

So the ripper and encoder are basically taken care of these days. The only missing link seems to be the player. I guess if the newer 2.0 alphas don't do the cache skip at the end of the tracks, that's a good improvement, maybe that puts us one step closer to gapless... But why does one have to do manual editing with your GapKiller to make an album like DSOTM sound right? If the ripper, encoder, and decoder were all doing their job, the re-constructed and decoded bits should line up the same way they do on the source, except for, of course, the differences from the MP3 loss. I don't see why the quest for gapless output has been so difficult.

All of the pieces you just listed are already in place, except that LAME isn't ready for prime time yet. I tried it and it's still got some work to do in that area, at least with the last build I tried.

The 2.0x player software currently plays tracks adjacent to each other without inserting gaps. And I don't know of any ripper which inserts silence, that only happens at the encoding stage.

The reason I still needed to use GapKiller is because I had tracks that were not encoded with LAME, and besides, LAME doesn't do it perfect yet anyway.

Hrm, so you're saying that to your knowledge, the player itself has *zero* time between the end of one tune and the beginning of the next? I kinda thought that might be true, but with the cache-related skip right before the end of the currently-playing song, I thought that was related to some inability to truly play the songs back to back. I guess since you're using a newer version of the software, your mileage will be different than ours, though...

So how is that alpha testing going?

so you're saying that to your knowledge, the player itself has *zero* time between the end of one tune and the beginning of the next?

Yes, that is what I'm saying.

So how is that alpha testing going?

Fine, but they're trying to work out a couple of minor things before a public release.