On the contrary. For me, the only reason to use rockbox, which i do, is so i can drag-drop music to my iPod. But i'm probably going back to apples firmware any time.

so, does apple use the same way of storing gapless info in aac/mp4 as nero?

Someone in this thread mentioned the tracktime VBR problem not being fixed yet - is this the problem where iTunes incorrectly reports the length of tracks, and reaches what it thinks is the end but continues to count up until the song is actually over? I've noticed this since iTunes 5 - it annoyed me, but wasn't a big deal. But starting with 6.02, iTunes reaches what it thinks is the end of a track and then just STOPS - it doesn't finish the song, it just stops and skips to the next song, sometimes cutting off as much as 2 seconds of a song.

I assume this is no longer an issue with 7, what with gapless playback and all - has iTunes just returned to counting past what it reports is the track length?

My experience was about 19h on stock firmware, 11h on rockbox.

Encoded through iTunes or encoded by any application using the QuickTime 7.1.3 AAC encoder?

When was the last comparison between Nero's AAC and iTunes'?

Are there any plans to have Nero's AAC files compatible with the way iTunes determines gapless? I'm pretty sure that the gapless information is stored within the iTunes Library database, because my iPod did NOT update my entire library when I set them all to gapless (meaning the files themselves were not modified).

Same here. I'm a Rockbox user from *way* back (as in Archos days) -- I used Rockbox specifically for gapless playback. I've been having no problems so far with gapless under the new firmware/iTunes 7 combo and I seriously doubt I'll be going back to Rockbox. It would be nice if Apple introduced true bookmarking for audiobooks, rather than just .m4b files, though.

Rockbox also boesn't support connector control, so i can't use it with my car stereo..is a great shame, and appears my nano didn't have a firmware update so im stuck with gaps in m car boohooo

Yep, that is what I notice occasionally on iTunes 7 (OS X), just a few seconds and sound is not cut off but it looks a bit odd when you keep looking at the timer until the end of the song.

can i upgrade my nano, without un-rockbox-ing it?

Note that gapless playback does NOT work on 1st gen nano with current firmware (1.2). Also, there is a compatibility issue between 1.2 nano and rockbox. You can still install rockbox, but whenever you switch back to Apple's firmware, the nano cannot see any tracks, even though the tracks are visible in iTunes.

This behavior was never fully explained, AFAIK. I mentioned several times in previous threads that I had no such problems with LAME-encoded VBR files in iTunes 6.

They probably think about that when they take breaks from counting money.

I just installed iTunes 7

Damn, it IS gapless!

What a great day!

Now I can give my Karma to my girlfriend and keep my 30GB iPod Video!

pika2000, Apple made it fairly clear... the gapless features are for the current iPods: iPod nano (2nd Generation), and iPod video (5th Generation). (The new nano is 100% different internally.)

As the 5G iPod video is still "current" (just slightly updated as of Tuesday), the new firmware adds gapless to bring it into parity with updated shipping 5G.

I wouldn't hold my breath waiting for gapless on the old nano...

I thought the 1st gen nano and 5G iPods use the same CPU, as noted at the rockbox website: http://www.rockbox.org/twiki/bin/view/Main/IpodHardwareInfo
If they share the same CPU, it shouldn't be hard to provide gapless playback to 1st gen nano, unless Apple doesn't want to do it to boost sales of the new nano.

I just reripped an album in iTunes AAC, importing direct from CD in the process, and it came out gapless. Bleh! I'm not going to rerip every CD I have to get this right.

OK, to answer my own question on how to consistently get already-ripped music to play gaplessly on a 5G:

• You don't need to rerip, existing lossless files ought to be fine.
• Don't use Nero AAC, use iTunes AAC. I haven't tried MP3 encoders but I'd assume that iTunes MP3 would also be preferred over LAME. iTunesEncode appears to work, to get transcoding right from foobar (for us lossless people).
• Upload the M4As using only iTunes. Don't use foo_dop or anything else that might muck with the tags or the db.

Preliminarily, once I followed these guidelines, I finally have true-gapless playback on my iPod. woot.

I have no problems in iTunes 7 with gapless using VBR mp3 lame and apple lossles. I was having the bug with lame files at the end of track, but it seems solved in iTunes 7 . When I switched from windows+foobar I was not very happy with iTunes. Right now I I'm enjoying the experience fully . The only gripe is the limited number of formats that can be used. My library was constructed around flac and ape formats, though now with XLD the conversion is easier. The new coverflow mode is great, neat advance in browsing through big libraries.

I am enjoying iTunes 7 a lot. Seems to be finally the media player I always wanted

No, it reads the LAME headers to use its native gapless ability so any MP3 made with a modern LAME encoder would be perfect for gapless playback. Furthermore, iTunes MP3 encoder is not really considered to be of equal quality to LAME.

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

Please provide some more information on the differences, including sound quality.

Having read through this thread, there still seems to be some confusion over what version iPods might support gapless.

Specifically, my wife has a 20GB 4G grayscale iPod. Upgrading to iTunes 7 is OK - buying new hardware is not. Apple's website isn't much help - there doesn't seem to be any area which lists iPod firmwares and their features.

So, has anyone here tried a grayscale 4G, and does gapless work on it?

They should have the same result. iTunes uses Quicktime to encode its tracks, too.



I read on the Apple Forum that the 4G greyscale iPod does not get the firmware update, but the iPod Photo (aka the iPod Color) does get the firmware update.

Do you have further proof of this? My tests are showing otherwise.

Which forum exactly ?

http://www.hydrogenaudio.org/forums/index....8231&st=75#
iTunes knows the exact original length, the only way to know this is through the Lame header.

Apart from that, I have yet to come across a LAME MP3 that is not perfectly gapless. Listen to the third set of these files for instance.

What did you test and how?

hmmm...

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

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?

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.

This is not a hack. It is as true as gapless gets. It has been already stated.

iTunes seems to use the metadata info on LAME files. It has not been yet confirmed, but, so far it is perfectly gapless to me. As much as foobar2000, which uses the compliant decoder for true gapless.





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

The new-gen nano uses core guts supplied by Samsung, instead of PortalPlayer.... which they abandoned earlier this year (and caused PortalPlayer's stock to crash.) See: http://www.eetimes.com/news/semi/showArtic...cleID=186701236

EE Times confirms some of this: http://www.eetimes.com/news/latest/showArt...cleID=193000601

Sorry, I have no subjective evaluation of sound quality... other than the maximum output is slightly lower from the headphone jack.

This is totally false!

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.

The thread regarding iTunes7 can be found here.

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.

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.

[441000.mp3]
TT2: segment1
COM(eng): iTunPGAP=0
TEN: iTunes v7.0.0.70
COM(eng): iTunNORM= 0000121E 00000C71 00006417 00002D9A 000024A1 0000234E 0000827F 000085FB 0000023E 00000D43
COM(eng): iTunSMPB= 00000000 00000210 000007C8 000000000006BAA8 00000000 00026783 00000000 00000000 00000000 00000000 00000000 00000000

[441001.mp3]
TT2: segment1
COM(eng): iTunPGAP=0
TEN: iTunes v7.0.0.70
COM(eng): iTunNORM= 0000121E 00000C71 00006416 00002D9A 000024A1 0000234E 0000827F 000085FA 0000023E 00000D43
COM(eng): iTunSMPB= 00000000 00000210 000007C7 000000000006BAA9 00000000 00026783 00000000 00000000 00000000 00000000 00000000 00000000

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

Isn't that essentially the definition of a redbook CD? A TOC + one continuous audio stream?

(Probably off-topic, and also a bit trite, sorry.)

-brendan

Hhmmm, but CD's are oldfashioned crap.

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?

Almost everyone with an iPod and their mommas

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.

If you want to experience it by yourself, try with these small samples.


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.

Pio2001 illustrated the problem in 2004:
http://www.hydrogenaudio.org/forums/index....post&id=390
More information:
http://www.hydrogenaudio.org/forums/index....showtopic=18211

As far as I know iTunes has AAC encoding as default. Anyone just pressing 'Import CD' in iTunes will encode in AAC, not MP3

I just verified this with my iPod's LAME MP3 content.

Exactly !!

Here's a simple test for gapless....Diskwriter

try saving to wav and compare the output
- of split traks + Lame gapless info vs playing the file continously.

Note the difference!


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.

The workaround is to use CUE.

What I have noticed is that the time marker on the iTunes display kinda stops and "hesitates" at the last second.

This produces no audible effect, though. But it seems as though it was reading some tag or something.

I noticed that too. I think is because of the inaccurate time issues iTunes still has with MP3 VBR files, its prediction is often a few seconds too short.

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.

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.

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.