lame mp3's not completely gapless on 5G ipod

[saratoga]

The best way to get gapless playback w/Lame-encoded MP3's is to use the "--nogaptags --nogap" command-line switches using the .EXE file.

This is actually a terrible idea.  --nogap is an ancient hack thats totally unneeded in rockbox.  LAME has been completely gapless without it for about 5 years now.  Its only useful for crappy decoders that can't handle gapless playback correctly (and even then it rarely works).

[michael.conner]

The best way to get gapless playback w/Lame-encoded MP3's is to use the "--nogaptags --nogap" command-line switches using the .EXE file.

This is actually a terrible idea.  --nogap is an ancient hack thats totally unneeded in rockbox.  LAME has been completely gapless without it for about 5 years now.  Its only useful for crappy decoders that can't handle gapless playback correctly (and even then it rarely works).

I stand corrected -- and totally surprised!  Thanks for the info.

Old habits die hard -- I used to have an Archos JBR, so I've been encoding live CD's and other albums that would need gapless playback that way for years now.  

[Llorean]

The one *advantage* of the --nogap option is that the whole CD is encoded in one go, and then split, I believe, which means the gap will be 100% seamless even in those problem cases where the current gapless in LAME will sometimes have a very slight audible difference in the sound, even though there's no actual *gap*. At least, that's my understanding.

Of course the _huge_ disadvantage is that you're cutting at frame boundaries so that in many cases you actually get a little of the prior track in the current one (or a little of the next track in the current one, I don't know which way it cuts)

[saratoga]

The one *advantage* of the --nogap option is that the whole CD is encoded in one go, and then split, I believe, which means the gap will be 100% seamless even in those problem cases where the current gapless in LAME will sometimes have a very slight audible difference in the sound, even though there's no actual *gap*. At least, that's my understanding.

I believe the output should be the same on a gapless decoder like rockbox with and without nogap (well when comparing the entire CD, obviously the tracks won't be the same length as you mentioned).  Its literally just creating one giant MP3 like with a cue sheet, and then splitting it up at the end.  The splitting process should be lossless, though the MP3s probably won't be identical anyway because the bit resivior will be packed different due to the different track lengths.

There also shouldn't be problem cases with LAME, just broken files and broken codecs. As far as I'm aware, the current lame.exe and a compliant decoder like foobar2000 can produce sample accurate decoded mp3s for all possible source files.  If you're not getting sample accurate output, theres probably something wrong with your lame compile (as in this thread) or you have a broken tag.

The problem with nogap is that it assumes that your decoder can output two MP3s back to back without inserting a single sample of silence.  Very few decoders can do this aside from those designed to be gapless with LAME anyway.

[preglow]

I believe the output should be the same on a gapless decoder like rockbox with and without nogap (well when comparing the entire CD, obviously the tracks won't be the same length as you mentioned).  Its literally just creating one giant MP3 like with a cue sheet, and then splitting it up at the end.  The splitting process should be lossless, though the MP3s probably won't be identical anyway because the bit resivior will be packed different due to the different track lengths.

I think there's a slightly greater chance of an audible glitch at the track transition if you don't use --nogap. You'll seldom hear it in normal use, but I've provoked a very audible glitch doing some very synthetic tests. No gap or anything, just a glitch thanks to how MP3 works internally.

[saratoga]

I believe the output should be the same on a gapless decoder like rockbox with and without nogap (well when comparing the entire CD, obviously the tracks won't be the same length as you mentioned).  Its literally just creating one giant MP3 like with a cue sheet, and then splitting it up at the end.  The splitting process should be lossless, though the MP3s probably won't be identical anyway because the bit resivior will be packed different due to the different track lengths.

I think there's a slightly greater chance of an audible glitch at the track transition if you don't use --nogap. You'll seldom hear it in normal use, but I've provoked a very audible glitch doing some very synthetic tests. No gap or anything, just a glitch thanks to how MP3 works internally.

Have you tried outputing the sample to wave in foobar or similar app and then counting samples?  I don't see why there should be a glitch if the decoder is working right.

[preglow]

Have you tried outputing the sample to wave in foobar or similar app and then counting samples?  I don't see why there should be a glitch if the decoder is working right.

Of course I have, I did these tests back when coding and validating Rockbox' gapless MP3 support. The problem stems from the fact that the encoder has to MDCT transform an incomplete frame of data, which has been padded with arbitrary values that should contain samples from the next track, but which don't, since the encoder encodes each track seperately when not in --nogap mode. When the two tracks are spliced together, this might cause phase discontinuities at the track change point, and this might be audible in rare cases. This will/should never happen with --nogap since complete frames are always coded, thanks to the encoder's knowledge about all tracks belonging to a gapless sequence.

[pabouk]

...the encoder has to MDCT transform an incomplete frame of data, which has been padded with arbitrary values that should contain samples from the next track, but which don't, since the encoder encodes each track seperately when not in --nogap mode.

So encoding multiple tracks separately

Code: [Select]

lame --options track01.wav ; lame --options track02.wav ...

gives exactly the same results as encoding them in one run

Code: [Select]

lame --options track01.wav track02.wav ...

when not using the --nogap option?

Now I see that the --nogap mode could probably solve my problem with light pops at the track boundaries and it is a candidate to be my preferred mode.

[preglow]

I wouldn't even consider using --nogap mode myself. I don't think I've ever heard a click in properly encoded MP3s at track boundaries before, and I listen to quite a lot of gapless music.

[lalittle]

I wouldn't even consider using --nogap mode myself. I don't think I've ever heard a click in properly encoded MP3s at track boundaries before, and I listen to quite a lot of gapless music.

This has been my experience as well.  I use JR Media Center to encode (which uses the LAME encoder) using the "preset standard" setting.  When I first learned of gapless mp3 playback, I was worried about the issues being discussed above (i.e. slight waveform differences at the transition that might cause a slight pop) but even in critical listening, I've never heard any sign of the transition -- it appears to be truly gapless in both JR Media Center and Rockbox (using a 5G iPod.)  Gapless playback is very important to me since my favorite music tends to have no gaps between songs, so I did a lot of "test" listening when I first heard of this capability.

Now I see that the --nogap mode could probably solve my problem with light pops at the track boundaries and it is a candidate to be my preferred mode.

If you're hearing "light pops" between songs, I honestly think that something else is going on with you're particular situation.  I'd look to your encoding chain for some possible issue that is causing this.  I know that when JR Media Center first implemented this feature, there were tiny pops between songs.  This, however, was a bug that was immediately rectified in an update, and is no longer a problem.

Before going through the extra work of using the "nogap" option, I'd experiment a bit and see if you can find where else the problem may be occurring.  I can't say that a pop is not a theoretical possibility, but I CAN say that in careful listening to numerous albums requiring gapless playback (Pink Floyd, Genesis, etc.) I've never heard any pops.

Larry

[pabouk]

Thank you for the information! In fact I did not test the problem with pops thoroughly and it could be probably caused by the CD ripper because I used foobar2000 for CD ripping for the first time. I will do some tests (with and without compression) and post the results.

[saratoga]

Of course I have, I did these tests back when coding and validating Rockbox' gapless MP3 support.

Haha sorry, was distracted and didn't realize who I was quoting.

The problem stems from the fact that the encoder has to MDCT transform an incomplete frame of data, which has been padded with arbitrary values that should contain samples from the next track, but which don't, since the encoder encodes each track seperately when not in --nogap mode. When the two tracks are spliced together, this might cause phase discontinuities at the track change point, and this might be audible in rare cases. This will/should never happen with --nogap since complete frames are always coded, thanks to the encoder's knowledge about all tracks belonging to a gapless sequence.

Ugh.  Heres where the limitations of my DSP knowledge come into play.  It was my understanding that zero padding an MDCT results in no phase or magnitude distortion, but rather simply different points along the same (interpolated) curve.  It seems to me that since I believe phase is not altered, and since the decoder can then trim off the excess samples, you should get essentially the same result.

However, I am not very familar with MP3 encoding.

[Jag86]

Hi! I'm new in this forum, but I use RockBox since it was ported for my iPod model, a 2nd generation iPod mini. It's really a great OS for me, because it has a lot of functions that original OS doesn't have. One of the most important feature is the gapless playback, because I hate to hear those gaps between those songs which was made to play smoothly (such as lives or Pink Floyd creations).
However, the last bleeding edge releases of RockBox have a strange problem: if I play, for example, The Dark Side Of The Moon, the first four or five tracks play in a gapless way, but the remaining tracks don't play smoothly, there are noticeable gaps between them. One thing I noticed is that, if I start to play the same album from those last tracks, they play perfectly gapless.
I'm sure all of my mp3s have the extra-header (delay+padding) of Lame, because I verified with foobar2000 that they play gapless.
It seems a problem of a certain buffer, but I'm not into programming of RockBox.
I've got version 060828-1343 installed. I'm sorry if the post is so long , but I hope you can help me.
PS to the devs: continue in this way, you rock!

[lalittle]

if I play, for example, The Dark Side Of The Moon, the first four or five tracks play in a gapless way, but the remaining tracks don't play smoothly, there are noticeable gaps between them. One thing I noticed is that, if I start to play the same album from those last tracks, they play perfectly gapless.

Are you playing the album all the way through -- i.e. you're not just jumping to the next song to see if it's gapless, are you?  The Rockbox software seems to need time to load songs into memory, so if you try to play the "next" song too soon, it won't be gapless.

Assuming you ARE letting the album play, I'm not sure why it would stop being gapless after a few tracks.  It's NOT a problem with the encoding since they do play gapless in certain situations, so there's definitely something else going on.  It looks like your build is from the end of August, however, so the first thing I'd try would be to update to the latest daily build and see if you still get this behavior.  They're constantly changing/fixing things in Rockbox, so it's possible that whatever the problem was, it has since been taken care of.

Please post back to tell us what happened,

Larry

[Jag86]

Hi Larry! First of all, thank you very much for your answer!
Yes, I let play the album all the way through, because I wondered that Rockbox needs a little time to pre-load the next song. Honestly, I found this situation very strange! A funny thing is that when I try to play the "bad" tracks directly from them, without the previous ones, and I press+hold the skip button in order to do a fast-forward to the next song, everything plays fine! So, Rockbox is better than I thought!
I will try to install the latest daily build and tomorrow I'll post again to say if everything it's ok or not.

PS: I forgot to say that I don't use any kind of equalizer or heavy WPS, just to be sure that iPod's CPU is not extra-loaded.