yesterday i tried if the new gapless feature would work on my l my lame 3.94 encoded mp3s. between some tracks there is a (very) little glitch that can be heard. (more often on more silent classical tracks) i checked with my ogg/vorbis versions of the same tracks: no glitch. tried to rerip and reencode with lame 3.96.1 the glitch can be heard again. finally i tried ripping and encoding the same tracks with itunes using aac. guess what: no glitch. so for me the gapless mp3 playing does sometimes not really work.rao

I think Apple is doing a reasonable job of work with their own formats, but also open standards. FLAC support in beta versions of OSX is a great sign, and possibly means it will be integrated directly into iTunes.

So I got iTunes 7 today, installed and plugged in my iPod with 3750 songs. It has now been doing that "Gathering information about gapless playback" for many many hours, and it is only about half way! How can I stop this??!! And what the h... is it really doing?

So I got iTunes 7 today, installed and plugged in my iPod with 3750 songs. It has now been doing that "Gathering information about gapless playback" for many many hours, and it is only about half way! How can I stop this??!! And what the h... is it really doing?

Computer specs and encoder settings of the file?

I tried it yesterday, with a library of roughly 4000 LAME 3.97 files on a P4 1.5 GHZ and it took about 40 minutes!

I'm the one in the picture, sitting on a giant cabbage in Mexico, circa 1978.Reseñas de Rock en Español: www.estadogeneral.com

So I got iTunes 7 today, installed and plugged in my iPod with 3750 songs. It has now been doing that "Gathering information about gapless playback" for many many hours, and it is only about half way! How can I stop this??!! And what the h... is it really doing?

Computer specs and encoder settings of the file?

I tried it yesterday, with a library of roughly 4000 LAME 3.97 files on a P4 1.5 GHZ and it took about 40 minutes!

A64 3500+ (but isn't it the ipod where the bottleneck is?), but it speeded a lot up now that I got home from work. But even still, shouldn't I be able to not do this? I wanted to transfer an album to my ipod this morning before work, but this task stopped me from doing that...

I've been following this thread since it started. It seems that too many posts are primarily focused on gapless playback using iTunes7. The subject of this thread is not about iTunes7, it is about gapless plaback on iPods. I believe this is part of the reason why there is confusion over which versions of the iPod are capable of gapless playback. Sure I can play back tracks gaplessly from my 3G iPod when using iTunes7, but I cannot get gapless playback from either the headphone out or line out of my iPod.

LAME gives perfect gapless playback and is still the encoder of choice.

I was under the impression it was nothing more than a hack (gapless implementation)

I'm sad to see Apple has avoided CUE suppport and chances now are prolly very slim.

Having said that. CUE support has been an outstanding request on the Rockbox list since 2002 !!

CUE is the only way to get true gapless, but since only the Archos supports it i guess we wont be seeing true gapless just yet.

CUE is even more of a hack than 'conventional' gapless playback is. Stuffing all tracks in one file and then using a second file to split them again on playback is not a hack?

Whether something is a hack (and gapless on lossy formats is impossible without hacks) or not it is not relevant to gapless, the audible result is.Relevant is:- No audible gaps between adjoining tracks- Implementing this with the least amount of drawbacks

The implementation Apple chose is one which follows both conditions. The only drawback being a one-time analysing session which can be lengthy...IMHO even better than CUE support instead of 'conventional' gapless because I consider 15 files in one large file with a second one just to be able to listen to one track a rather large drawback.

There is a hidden message in the song at approximately 4:32. If played at half speed, Waters can be heard to say, "That was pretty avant-garde, wasn't it?"

I also confirmed that iTunes v7.0.0.70 does attach the information for calculating accurate stream length to MP3 files.

Creating two WAVE files with 441000 samples (10 seconds) and 441001 samples (10 seconds + 1 sample), I encoded them to two MP3 files by using iTunes v7.0.0.70. I checked the MP3 files and noticed some differences in ID3v2.2 tags generated by the encoder.

Note that there're some differences in iTunNORM and iTunSMPB comment frames. The different values may represent the number of padded samples by the encoder.

As these MP3 files have 385 frames, the number of decoded samples will be 1152 * 385 = 443520 [samples] (without any handling for gapless playback). Assuming that the second and third values in iTunSMPB present the numbers of encoder delay and encoder padding in samples, I obtain the original sample length: 443520 - 528 (0x210) - 1992 (0x7C8) = 441000 [samples] = 10 [sec]. The forth value in iTunSMPB frame probably represents the original sample length since 0x6BAA8 equals to 441000 [samples]. I'm not sure how other values in these frames are used, but I hope this will be a good starting point to understand the mechanism of the gapless playback proposed by Apple.

I've been following this thread since it started. It seems that too many posts are primarily focused on gapless playback using iTunes7. The subject of this thread is not about iTunes7, it is about gapless plaback on iPods.

I agree with you, but we need to make sure whether if the necessary information for accurate stream length exists in the MP3 files encoded by iTunes. iRiver once claimed that they implemented gapless playback, but it was just the infamous gap (or silence) removal. Now that the necessary information is confirmed to be attached to MP3 files, we can celebrate the true gapless-playback only if someone with the new iPod experiments it on the hardware player.

I also confirmed that iTunes v7.0.0.70 does attach the information for calculating accurate stream length to MP3 files.

Just to make it clear: This only happens when iTunes 7 rips to MP3. It will not modify your existing MP3 files with these extra tags. (It didn't touch any of my LAME MP3 content.) It's a shame Apple didn't just write a LAME/Xing compatible header with enc_delay & enc_padding info when ripping to MP3... since that's as close to a "real" standard as you can get for MP3 gapless. Now we have more proprietary iTunes tags other players will probably ignore. I guess it doesn't matter. Who really uses the iTunes MP3 encoder?

LAME uses a method in which the correct track length is stored in metadata. With a compliant decoder, the track will be played to its original length everytime, perfectly.

The original length is indeed respected but the junction of two files isn't always smooth. As a consequence there's sometimes a small 'pop' when the player starts to read the following track. The problem is known and has been reported some times ago. LAME isn't alone in this situation: the same issue is reproducible with Nero AAC and WMAPro which are both supposed to be gapless. Vorbis and Musepack (1.15v only) aren't affected.

N.B. To be accurate, the existence of such pop doesn't question the 'gapless' status of these encoders. Simply because there's no gap (silence) between musical data, only a lack of harmony between the last samples of the initial file and the first samples of the subsequent one.

Stuffing all tracks in one file and then using a second file to split them again on playback is not a hack?

Obvious mistake, nothing is getting re-split.

Once you reach the designated track, its name changes, the stream is continous.

Maybe your ears won't catch the transitions, each time but they are there, not so with one continous stream. In fact someone just said they noticed very slight changes, that is proof enough for me that this is a best effort with mp3 that is not a gaples format to start with.

In fact someone just said they noticed very slight changes, that is proof enough for me that this is a best effort with mp3 that is not a gaples format to start with.

The workaround is to use CUE.

OK, one more time: LAME MP3 is gapless, and has been for quite a while. It just needs a compliant decoder. Like your CUE sheet implementation-- if there is no compliant player that can read the CUE info and apply the necessary track "change points", it is completely useless.

But LAME's gapless implementation is clever and simple. Apparently, this time Apple went with something similar.

People wo "noticed differences" either used some unappropiate MP3 encoder/settings or a non-compliant decoder.

MP3 was not a gapless format to begin with. But since around 2003, it has been.

I'm the one in the picture, sitting on a giant cabbage in Mexico, circa 1978.Reseñas de Rock en Español: www.estadogeneral.com

I also confirmed that iTunes v7.0.0.70 does attach the information for calculating accurate stream length to MP3 files.

Creating two WAVE files with 441000 samples (10 seconds) and 441001 samples (10 seconds + 1 sample), I encoded them to two MP3 files by using iTunes v7.0.0.70. I checked the MP3 files and noticed some differences in ID3v2.2 tags generated by the encoder.

Note that there're some differences in iTunNORM and iTunSMPB comment frames. The different values may represent the number of padded samples by the encoder.

As these MP3 files have 385 frames, the number of decoded samples will be 1152 * 385 = 443520 [samples] (without any handling for gapless playback). Assuming that the second and third values in iTunSMPB present the numbers of encoder delay and encoder padding in samples, I obtain the original sample length: 443520 - 528 (0x210) - 1992 (0x7C8) = 441000 [samples] = 10 [sec]. The forth value in iTunSMPB frame probably represents the original sample length since 0x6BAA8 equals to 441000 [samples]. I'm not sure how other values in these frames are used, but I hope this will be a good starting point to understand the mechanism of the gapless playback proposed by Apple.

This analysis is correct. Additionally, the sixth value is the byte offset from the first audio frame to the 8th-from-last frame. This provides a resynchronization mechanism to restore a decoder's true sample number after a seek.

I also confirmed that iTunes v7.0.0.70 does attach the information for calculating accurate stream length to MP3 files.

Just to make it clear: This only happens when iTunes 7 rips to MP3. It will not modify your existing MP3 files with these extra tags. (It didn't touch any of my LAME MP3 content.)

Yeah. I didn't write this in the previous post, but I also confirmed that iTunes reads the MP3-Info header, where LAME stores the information for accurate stream length. I got gapless playback between two MP3 files encoded by LAME, but not if I modified (or broke the MP3-Info header), through a hex editor, the number of padded samples stored in the MP3-Info heder. This proves that iTunes 7 also supports the gapless playback with MP3-Info method, as well as iTunSMPB method.

Based on the posts in this thread, I guess (hope) that Apple implemented gapless playback with both MP3-Info and iTunSMPB methods in iTunes and the new iPod firmware. I don't like the idea of storing these information in ID3v2.2 since some tag editors may remove these frames accidentally (some tag editors cannot handle multiple comment frames properly). But Apple might hesitate to create MP3 files with MP3-Info header since the specification defines fields reserved specially for LAME (e.g., encoding flags, ATH type, noise shaping type, ...). Anyway, I think it's a great news that they supported MP3-Info method even if they introduced another method.