Thank You for your continued support and contributions!
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.
Quote from: michael.conner on September 10, 2006, 04:34:20 PMThe 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).
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.
Quote from: saratoga on September 10, 2006, 09:33:25 PMI 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.
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.
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.
...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.
lame --options track01.wav ; lame --options track02.wav ...
lame --options track01.wav track02.wav ...
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.
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.
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.
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.
Page created in 0.127 seconds with 20 queries.