Only SebastianG is able to tell if the lame tags with the gapless info is written exactly as lame does it itself, but if Foobar2k works, in theory iTunes should get it right too.

Are you sure iTunes "searched for gapless info" before it transfered files to your ipod?

You may also try to retransfer them with the new Winamp 5.30. Make sure to go to the preferences in the Portable -> iPod -> Advanced, and scan for gapless info there before transfering.

This is only necessary for old files already on the ipod.

Just been playing some more and found that the first track that I cut with pcutmp3 is gapless to the second on both itunes and the ipod but the next 3 or 4 I tried had a slight gap, strange?!

Can I upload the album to my ipod using winamp 5.3 and not disturb any of the itunes info as I'd hate to upload my library again?
Also does winamp deal with the gapless differently to itunes?

cheers

Rochey

You can use the same ipod with both Winamp and iTunes. However, it's probably best to use only one or the other (or else back up your itunesdb file often

iTunes 7.0.1 is released.

It's really starting to frustrate me now.

All the cd's that I rip manually using EAC and Lame 3.96.1 all appear to be gapless on both my ipod 5G 80gb and itunes 7. This is great.

I have got a couple of continuous mp3's which I have split using the .cue file and pcutmp3. Now when I play these newly split mp3's in itunes SOMETIMES they are gapless and other times they are not (it seems totally inconsistant). And then on top of that the Ipod NEVER seems to be gapless on these newly made mp3's!!! How frustrating!!!

It's great that the Ipod has gapless and now that it does I want all my mp3's to work. Maybe I'm asking too much.

I haven't tried using winamp 5.3 as I don't want to have to re-download all my mp3's, although I will test if anyone thinks that winamp does the gapless differently.

If anyone can help it would be greatly apprieciated.

Also another route I was thinking is mounting the mp3 and cue as an image and ripping it using EAC but I don't think that there is anything out there that supports this. If anyone has heard of any tool that does this then please let me know.

I look forward to the replys.

Rochey

I'm not familiar with pcutmp3. Does it write a new Xing/LAME header at the beginning of the files it creates? If it does, are the padding values that it writes accurate? Do the pcutmp3-generated files play gapless in a Winamp or foobar?

[complete guess mode]

All the files I have split using pcutmp3 work great in foobar (I don't have an ipod). However, they do have very large values of <ENC_DELAY> and <ENC_PADDING>. Much larger than files generated by normal CD rips (eg. 2856/1440 vs. 576/1380).

Could it be that itunes/ipod can't handle such large values? (As Sebastian mentions, fb2k 0.8.3 doesn't)

[/complete guess mode]

Ok, I've had some weird luck with LAME files and gapless in the new iTunes 7/iPod firmware 1.2 combo.

CD: Brian Wilson "Smile"
Problematic track transition: 07 Wonderful / 08 Song for Children

With straight-up lame -V 4 --vbr-new encode, the iPod cuts maybe 100 milliseconds off the end of track 7 or the beginning off of track 8 and the rhythm is messed up as a result.

lame -V 4 --vbr-new --nogap encode, the transition is a little smoother, but the rhythm is still wrong. I did run the resulting files through vbrfix to get the reported track lengths corrected.

lame -V 4 --vbr-new --nogaptags --nogap encode: PERFECT transition. (re: --nogaptags -- I got in the habit of encoding with this along with --nogap with an old Archos Jukebox using Rockbox as per their wiki for Archos machines. I've been told it's wrong to use it. And yet it works...)

Pretty much any other gapless CD I have in LAME on my hard drive was encoded using --nogaptags --nogap as the extra parameters but work perfectly gaplessly. I've been recently told that LAME is supposed to be gapless by nature and that --nogap is redundant and --nogaptags is definitely not useful. Any idea why I've had this experience?

--nogap is a kludge that assume a specific behaviour of the decoder/player.
If you stop using --nogap, you'll have proper gapless decoding in Fb2k/Winamp/iTunes.

Right, that's what I've been told -- but like I said, I did a "normal" encode without --nogap and did *not* have proper gapless decoding in the iPod. I ripped the CD to .WAV using EAC and encoded using RazorLame with Lame 3.97 using -V 4 --vbr-new and did not have a smooth gapless transition between the two tracks on the iPod.

Edit: I should point out that I did have perfect gapless playback with those same files (the ones encoded without --nogap) in foobar and iTunes, just not on the iPod.

My own, revised findings are that LAME MP3 usually works. Every once in a while, my iPod screws up a transition. I'll go back and try it again and get gapless playback. I think there are still some sizable bugs in gapless. pcutmp3 mp3s don't work consistently either, despite having proper LAME headers with all the required info.

I'm new to this (to LAME that is, not digital audio in general) so my suggestions/comments may be obvious. If they are, I apologize.

My understanding is that when you encode tracks to be gapless, they must all be specified on the command line of LAME at the same time. Utilities that only place one file at a time on the command line will not result in gapless files. I think RazorLame puts only a single file on the command line at a time.

The only frontend that I've seen that allows for this is ALL2LAME. There is a check box for gapless and you need to set "dividers" between albums by clicking a button. This causes the files grouped together as albums to all be put on the command line of LAME together.

Perhaps this will help you out.

Rich

Thanks... actually, I used ALL2LAME for the two "gapless" encodes. As I understand it, checking the "No Gap" box in ALL2LAME simply puts in the --nogap command while encoding.

The first time I encoded using ALL2LAME, I used "-V 4 --vbr-new" and clicked the "No Gap" box. Resulting files have a faulty transition *every time* on the iPod (although less faulty than when I used Razorlame).

The second time, I used "-V 4 --vbr-new --nogaptags" and clicked on "No Gap." The resulting files have a perfect transition every time.

(As a side note, encoding the same files with iTunes AAC is perfect every time.)

It may be that for whatever reason, iTunes' gapless scanning can be occasionally buggy.



I think so, too, about the bugs in gapless playback. I have been finding AAC gapless pretty flawless. But I've had that same experience you had, too, where going back made it work correctly. Those two Brian Wilson tracks I mentioned in my earlier post are the first ones I've had be consistently bad.

One of the issues I've noticed with gapless on IPOD itself is that it often doesn't work if you fast forward through a song to get close to the end to "check" for gapless. The very act of moving through the song seems to throw things off. I've listed to many gapless on the IPOD over the last few days (lots of live concerts) and it seems to work perfectly with lame and old fhg CBR files so long as I play the song all the way through. Probably a function of the cache, etc. within the ipod itself.

AHA! I just tried the two "bad" files again, just let them go all the way through -- perfect gapless. Thanks!

I'm just about 100% certain this is not true. I believe that as of Lame 3.90.3, gapless information is placed in the lame header by default. My tracks are gapless in foobar2000, Winamp and iTunes7 and I have done nothing special to my Lame command line.

EDIT: Going out on a limb and striking my uncertainty...

2G nano 1.0.2. firmware should fix that.

The issue I raised before about "playing song all the way through" to insure gapless works is true on my 5G 60GB ipod with most current 1.2 update. The issue is not the ability to search long tracks, but the way it sometimes (not always) throws off the gapless transition.

This is probably straying off topic, but it is still regarding gapless and playback on iPod. I'll be moving to using an iPod with files encoded with LAME and I want to make sure I'm doing this correctly before I go nuts encoding all of my music.

Can somebody verify with 100% certainty that it is NOT necessary to put all files of a gapless album on the command line of LAME when encoding? Anything that I've read indicates that you have to, but I'm new to LAME, so I may have missed something. I know that --nogap is no longer required, but I'm not sure about the files on the command line issue.

Thanks!!

I should have also mentioned that my gapless lame files are created one at a time.

EDIT: And my thinking as to why you're seeing gaps is because you are seeking within the track rather than letting it play through, which is commonly known to create problems.

EDIT #2: one at a time

Actually, this also forces ALL2LAME to put the files all onto a single command line with LAME.exe.

From the ALL2LAME documentation:
"No Gap:

When "No Gap" is checked the --nogap switch is set and all filenames are put on one command line (my emphasis). Some things you should know about the --nogap switch:"

With foobar2000, it's quite easy to see the gapless info.

Right-click>Properties>Properties tab>General Section>Duration

Complementing what has already been said:

don't use --nogap

It doesn't fix the gap problem in general.

It works like if one had cut an mp3 at a frame boundary, and not using bit reservoir on those two frames.
This doesn't remove the delay a decoder would introduce when starting to decode.

Got an idea for the long mp3's with a cue sheet, don't know how feasible it is for you guys.

How about mounting the cue file in foobar2k using it to create an image via Nero 7.5 and then using EAC to rip the new tracks.

I have just done it and the whole process took about 7-10mins to do. I loaded the newly ripped tracks on itunes and they all played completely gaplessly.I haven't tried my ipod but I would assume it will also be gapless as everything that I ripped using EAC has been gapless.

The only downside to this is audio quality but still it's a possible workaround for the long mp3's that we want to split.

Could someone explain the loss of audio quality through this process to me? If the loss of audio is only negligable then I think that I will start to split my long mp3's this way.

What I can say is:

• I've never heard of this necessity
  therefore
• I've never used LAME in this fashion
  and still
• I've yet to come across the first LAME MP3 that is not gapless in iTunes

With the firmware 1.0.2 on my 2G nano, it all seems to work flawlessly. I've been through 7 of my Pink Floyd albums, where most tracks have gapless transitions. No problem when I scroll to the end of the songs for checking gapless-ness.

I rip as tracks with lame -V4 --vbr-new, and tag with both id3v1 and id3v2. Also APE tags are added if I do mp3gain after encoding - none of the tags have affected the gapless playback.

I suspect the difference between your experience with the nano and mine with the 5G is that the 5G is a harddrive based system.

Looks like the key of gapless playing in iPod is the "iTunSMPB" comment tag. The 4th hex value (64bits) is the real sample count, that is always less than the physical sample count encoded in the MP3 file. Somehow, with the other two values it defines a "window" inside the file in order to avoid the boundary conditions. Furthermore, seems that this 64 bit value is always multiple of 588, the number of samples contained in a CD frame or sector.

Another interesting comment tag is "iTunes_CDDB_1", contaninig the original CD TOC info in this order:
- CDDB ID
- Leadout sector LBA address
- Number of tracks
- For each track: starting track sector LBA address

This info can be very useful to reconstruct the source CD TOC so it generates the same CDDB ID after burning.

I just noticed that the iPod does not read the lame header (or has problems with too high enc_delay), because songs cut with pcutmp3 don't start where they are supposed to start. bummer

Just because it as problems with tracks split with pcutmp3 does not mean that it does not read the lame header. It's already been verified by several people that lame playback is indeed truly gapless.

How can this be if it doesn't read the lame header?

On my 5G 60GB iPod, I mostly play LAME mp3 tracks, and they have played back gapless.

It appears to be a bug in itunes. A discussion of similar problems (with fb2k 0.8.3) is in the pcutmp3 thread. http://www.hydrogenaudio.org/forums/index....showtopic=35654

I guess that if musicmusic adds support for writing gapless data to the ipod database in foo_dop, pcutmp3 files could be added with the correct length?
Discussion here: http://www.hydrogenaudio.org/forums/index....st&p=432119

Based on everyone's observations, we know both iTunes AAC and LAME MP3 play glapless. Does anyone know about Fraunhofer MP3?

I have many fraunhofer mp3s that now play gaplessly on itunes and the ipod itself (5G). Coded with the codec in MMJB 7.5. For example, live concerts play with no gap and things like side 2 of Abbey Road play gapless. So, on my end the Fraunhofer mp3's work gaplessly.

Interestingly enough (as I've posted elsewhere with no responses), the fraunhofer mp3's do not play perfectly gaplessly on fb2k or winamp. My conjecture is virtually all these fraunhofer files have slight variations in time as reported by "verify integrity" within fb2k. These are all CBR 192, and the reported time error is tiny. Itunes plays fine gaplessly on these files. I suspect that the ITUNES scanning of the files for gapless info somehow stores the needed info in the itunes library. So they work gaplessly in itunes/ipod. But since they are not LAME encoded, and for some strange reason all have incorrect time errors (note I'm talking about 20,000 files here), fb2k and winamp doesn't deal with the gaps. What happens is that I get a very, very small hiccup as it moves from one song to another...that is "almost" gapless but not quite. I do NOT get this on the same songs in ITUNES.

On songs that I've encoded with LAME (last 3 years of stuff), I get gapless on itunes/ipod and fb2k and winamp. So it is definitely something with the fraunhoffer files. Any thoughts on why all 20,000 of these files get time difference warnings from "verify integrity" within fb2k???

garym, iTunes 7 has some (currently undocumented) logic to eliminate the gaps on content that isn't gapless by design. That's part of the "magic" it does when evaluating your content for gapless playback. In your case, iTunes seems to do a very good job at gap elimination for FhG MP3 content... just like pre-existing iTunes MP3 and AAC encodes.

foobar2000 only supports "true" gapless MP3, using the additional LAME header info.

iTunes just told me that firmware 1.3 for my nano was available

iPod Software 1.3 for iPod nano

• Support for additional Nike + iPod voice kits

• Bug fixes

hey all - I hope this hasn't been 100% covered yet (I don't have enough time in a day to look through all 12 pages of this thread...sorry!)

I've got a 60GB Photo running the latest firmware. I enabled gapless on some tracks in iTunes, but they're MP3s (not AAC or MP4), and I have no idea what encoder was used for them.

My understanding is that gapless will NOT work on MP3s that were not encoded using iTunes, correct?

That's how it would appear at this point. I'm testing with some techno albums, and there's a definite gap between tracks.

I'm starting to think my only option is to re-encode everything in iTunes...which would take awhile considering I'm up to 40GB of music.

I think LAME MP3s also work, but I am not 100% sure since I use AAC only.

I'd choose either iTunes AAC encoder or LAME MP3 encoder. Both are native gapless in iTunes. You could use iTunes MP3 encoder but is has no benefit whatsoever over LAME while its quality is generally considered lower than LAME.

Mind you, gapless should even work rather well on MP3's not made by iTunes or LAME although it's not as perfect as the genuine stuff.

This thread is well worth looking over. This stuff has already been covered in graat detail. Even someone from Apple has taken the time to contribute.

Otherwise it's only going to get longer with people asking the same questions over and over because they'd rather do this than make any kind of effort.

I was working on a summary thread. Sticky, anybody?

Haven't tested yet or noticed any previous mention but i just got a 1.3 update for my older nano, "bug fixes", lets hope its gapless

This is NOT true. iTunes is pretty much able to play any properly encoded mp3 or AAC file gaplessly. There were some initial problems with Nero AAC files but I think that has been fixed. I currently have iTunes 7.0.2 and a older 5G iPod model with the latest firmware. Most of my library is encoded with Lame 3.97 (final) at -V 2 --vbr-new and all of my Lame 3.97 files playback gaplessly. I have some older iTunes AAC content, Nero AAC, FhG mp3s, and mp3s made from older versions of Lame. I have yet to come across a file that didn't playback gaplessly. If you are having issues with your music not playing back gaplessly, then the mp3s might be corrupt or you need to download the new version of iTunes released a couple of days ago. Make sure to go to itunes.com as the iTunes update module currently does not detect iTunes 7.0.2.

Kornchild,
In this thread, you say that Nero AAC seems gapless since itunes 7.0.1. This isn't true on the one live album I tested with (using 7.0.1.8). It may seem gapless if you're not paying attention, but a small gap is definitely still present; I checked against foobar 0.8.3 behavior of the same Nero AAC files.

Haven't tried with 7.0.2, but I'm not going to do the full download just to find out.

I tried it, still not gapless with Nero AAC. I guess it will never be to help promote their own AAC encoder.

Well, I guess Nero could make an update to their encoder and add the gapless meta info in the same format as the iTunes encoder uses, which would make them gapless compatible. That's up to Nero.

That is strange as I have 3 albums encoded with Nero's latest AAC encoder, all of them are gapless. Sometimes, the first time I played them, there would be a very small gap. Now, anytime I go back and play the files on my iPod or in iTunes, they playback gaplessly. I guess the issues with Nero AAC haven't completely disappeared. I may have to go and test some other albums (like Tool's Lateralus) using Nero's AAC encoder and iTunes 7.0.2.

Well, since iTunes apparently doesn't read NeroAAC's gapless data it reverts to its 'magic guessing procedure' to get this data. This may sometimes be 99% right (inaudible), sometimes 80% right (barely audible) and sometimes 40% right (clearly audible).

That might explain why results vary among users. I think Apple did a pretty good job on this 'magic guessing procedure', it's just not 100% right all of the time.

What if, like me, you don't give a monkeys, and you just want to use itunes to loads videos onto a 5G that you've already loaded exactly how you want with a custom database from ape tags, using foo_pod ? How much would it be to ask to be able to completely disable the feature, so that itunes doesn't wade in and completely screw up the tags in your itunesDB ? Stuck on itunes 6.0.5 until there is a workaround. (Do the 2nd gen 5G's work with itunes 6.0.5 out of interest?)

Niels