Support and General Use > Audio Playback, Database and Playlists

lame mp3's not completely gapless on 5G ipod

<< < (5/9) > >>

saratoga:

--- Quote from: preglow on September 11, 2006, 08:04:03 AM ---
--- Quote from: saratoga on September 10, 2006, 09:33:25 PM ---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.

--- End quote ---
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.

--- End quote ---

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:

--- Quote from: saratoga on September 11, 2006, 10:07:45 AM ---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.

--- End quote ---
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:

--- Quote from: preglow on September 11, 2006, 11:10:07 AM ---...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.
--- End quote ---
So encoding multiple tracks separately

--- Code: ---lame --options track01.wav ; lame --options track02.wav ...
--- End code ---
gives exactly the same results as encoding them in one run

--- Code: ---lame --options track01.wav track02.wav ...
--- End code ---
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:

--- Quote from: preglow on September 11, 2006, 04:06:07 PM ---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.

--- End quote ---

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.


--- Quote ---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.
--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page