Regardless of bit rate, MP3s encoded with LAME do not function correctly in iTunes.

iTunes fails to give a correct time code, meaning that the song will sometimes abruptly end, even though the MP3 file has the information to keep playing!

MP3 files encoded with VBR work PERFECLY if you use iTunes' built-in MP3 encoder - but who wants to do that when LAME does a better job? (HA Wiki proves this, I inject no bias.)

CBR is inefficient and produces lower quality files at the same bit rate as VBR.
To have CBR have the same quality as VBR, higher bit rates must be used, also resulting in large file sizes.

This is just simply unacceptable! A program called "VBRfix" has been offered before, but what about Macintosh users?

If you want MP3s to play back on your iPod and iTunes, it would seem you have NO CHOICE but to use CBR or encode VBR with the less-than-stellar iTunes MP3 encoder. Is there any solutions? Anyone?

Hmmm, I haven't had an issue with LAME VBR MP3s in iTunes using -V 2. The only issue I have had is my iPod skipping briefly on one LAME VBR track of mine but others have played fine. But I have heard other people having issues with this.

Same here. I don't see this problem with iTunes, and *all* of my VBR MP3 encodes are LAME generated. As iTunes/iPod "owns" the portable device market, this can't be a general problem.

Sounds like you're not using LAME properly and generating files with bad headers. How are you encoding?

iTunes 6.0.4 (3) is the software I am using to play the VBR MP3s.
I am using Max 0.6.1 (on Mac OS 10.4.6), which uses LAME 3.97b2.
Strangely, they sometimes play correctly! (I double checked)

I have no idea what is causing this, but I had heard a lot of people talking about and *do* notice it when a song cuts off 10 seconds early...

Any other users have this issue? I just joined HA and after reading a thousand posts I won't be posting without proof or unbiased results! Any help appreciated - I'm about to do a massive undertaking of ripping 200-300 cds in a format good enough for DJing and I simply CAN NOT have the tails of the tracks deciding not to play!

My ears aren't golden, but I can tell when songs don't play all the way through - I don't believe it to be an isolated incident (some songs, sometimes, just me, my computer is messed up, etc.) - so I hope this post can help others.

You say you are using a Mac, I wonder if that has something to do with it. I'm on Windows and haven't had an issue with iTunes playing my LAME VBR files. Anybody with Windows experiencing a similar issue?

I have had this problem with iTunes 6.0.x on Windows 2000/XP. It appears that there is some inaccuracy in time calculations when iTunes deals with a file with large VBR bitrate variations (e.g., -V 2 settings). The error is generally small, and so seems to be noticable only when playing long files (typically longer than 10 minutes or so).

With shorter songs (the majority of pop music) it is rarely observable.

I have noticed this when playing some long LAME encoded tracks on my old 3G iPod as well (??) - my Shuffle does NOT appear to exhibit this issue.

I have tried re-encoding tracks that exhibit this, and found that there is a degree of randomness - the re-encoded tracks "cut off" at slightly different times. Using FooBar to rebuild the MP3 stream changes it again, but not by much.

Transcoding the tracks to AAC eliminates the issue, not surprisingly.

I wish I knew more, but that's what I have.

Ah... I use -V1 or -V2 settings depending on what the final bit rates will be (I like my files to be in the 210-250kbps VBR range).

Perhaps it is this setting + TIME that most affects whether or not something will skip? I DJ with these MP3s, and many MP3s are club edits, meaning they can last up to 7.5 minutes each...

Although I use CDs to DJ, I use my iPod *every day* in the car to judge/rate/choose tracks for my upcoming sets. I would hate to have to transcode all my mp3s (two libraries) so that I could have 1 set for listening and 1 set for DJing. For my setup and sound system (important, right?), MP3s in lame become transparent at around 200kbps VBR. Of course, the car or iPod setup could easily be doing -V5 and I'd probably not notice (as long as the songs played in full!)

I wonder if using a different version of the lame codec would help? I have no problems with 3.96.

I will rip 20 CDs of rock, dance, and jazz - i'll listen to the tracks and see if any of them cut out. I've updated all of my software (OS, iTunes, Max, etc.) -- Just to be sure (and because I need to), I am wiping out my system and reinstalling everything on to a clean HD. This should eliminate any doubt that it is the system, HD corruption, etc.) If the problem persists or goes away, I'll post again here.

Thanks for your help and information!

I've got extremely long songs in my iTunes 6.0.4.2 Library on my Windows XP Pro PC (some uncut live shows in the 2.5 hour range), encoded via EAC and Lame 3.97b2. My 60Gb ViPod plays them correctly as well.

I use -V5 through -V2 for the files, depending.

The times are all exactly correct. This is proven that the records can be retagged with Foobar+FreeDB before and after importing to the iTunes library, and of course that they are played correctly by iTunes.

In other words, there is some third factor causing this issue for you. I really hope you can hunt this issue down, because missing out on LAME is missing a lot.

Have you tried the LAME iTunes plugin for Mac? That might help, or not. I couldn't know.

I had this problem on some of my older LAME VBR encodes. VBRFix fixed them in all cases. Newer LAME builds from rarewares have never caused this problem for me. iTunes for Windows.

Download the lame command line encoder and try that. Its probably just a crappy ripper.

I just tested a 23 minute song encoded a -V 2 and I can confirm I have this problem. The song cuts off slightly before it is supposed to end. iTunes reports the song as 23:08 and Foobar reports the song at 23:09 but Foobar finished the song correctly while iTunes seems to miscalculate the time of the song.

BTW, EAC 0.95 beta 4 and LAME 3.97b2 (build from Rarewares) was used to do the rip and encoding and iTunes 6.0.4.2 was used for the playback.

Edit: I would also like to add the Windows Media Player 11 beta reports the song at 23:08 as well and before the track ends it reaches 23:08 on the counter but WMP 11 continues to play the song until it ends. I would also like to add that QuickTime 7 plays the song correctly, must be an issue with iTunes.

try using different versions of lame and see if the problem persists

it might be attributable to a particular lame build

I just did two test encodes, one with LAME 3.90.3 and another with LAME 3.98 alpha 4 and the problem still persisted in iTunes. I think the issue is with iTunes.

iTunes does seem to have trouble playing LAME vbr files correctly if one fast forwards with the playhead, but if the file is played straight through, it ends correctly. Really strange.

You guys don't have that stupid 'cross fade' setting in iTunes turned on do you? It might be trying and failing to do that.

I think this is unlikely and a semi-annoying comment on my part, but I just want to clarify since no one has brought this up yet.

I share my Lame MP3's with my room mate who has an iBook. He and I both use the latest iTunes (he on his Mac and I on my HP Pavilion running XP Pro) and neither of us experience this issue.

Already thought of the crossfader and disabled it. Problem still persists. Note that the problem seems to only exist with very long files (20+ minutes for me). Shorter files playback flawlessly.

I have the same problem directly on the iPod, songs abruptly end (sometimes 30 seconds in advance). This seems to be caused by the fact that I transfered the songs on my ipod using yamipod, which is a 3rd party utility to transfer songs to an ipod. iTunes seems to add the SONGLEN tag to every songs when you add them to the library, or transfer them to your ipod, yamipod does not do it. This is confirmed on my ipod since I only uploaded two albums on it using yamipod. For songs that my ipod think are longer, they just get played all the way thru, then they skip song when the ipod figures there's no more audio data. The bug is also visually appearant on the progress bar, on the ipod.

For the record, I am using a 30g black video iPod.

Yes, it's yamipod's fault. I'm using an iPod 5g 30gb, too and no -V2 --vbr-new encoded mp3s stutters or something similar.

I just tried Windows iTunes 6.0.42 using a standard LAME 3.97b2 -V 2 rip that I made myself. I skipped back and forth and never got anything odd to happen. Perhaps the problem is specific to some iTunes versions then? I've never seen anything like it.

Agreed!

One possibility is some programs won't use the LAME settings (I'm talking about lame_enc.dll with the .ini configuration) we think and expect them to use, and somewhere along the line settings are either mangled or ignored altogether. I ran into this when I briefly only for a few minutes tried out AudioGrabber that so many people rave about with lame_enc.dll that utilizes the .ini for forcing settings, not a good experience. Also Audacity overrides chosen settings via the .ini, and since lame.exe can't be used I never export to mp3 with Audacity anymore. Use the trustworthy it does what you want everytime lame.exe.

Did you scrub it back and forth and then to the end and so that it played out completely? Seems it cuts off almost all the LAME tracks a few seconds early here.

OK, I'm not a "big fan" of iTunes... so it's not my primary player by far. When I casually tested it earlier, I wasn't able to repro it.

But, later today... I able to reproduce this on some content: I used numerous tracks from eMusic -- who uses (an older) LAME VBR MP3 on all their content. The encodes I've produced seem to have a much higher "no problem" rate. But no matter... It does cut off the very end of the track in many cases... just a second or two. I just jump to the last 30 seconds and let it play out to reproduce. Obviously, if there is silence at the end... you won't notice.

Anyway, it is an issue with iTunes. Other MP3 players/decoders have no problem with the content, including my car. Good luck on seeing this fixed... it'll probably get as much attention as the VBR MP3 skipping issues on iPod nano & mini. I guess anyone that cares can log a support call and offer sample content if necessary.

I'm using Max and iTunes as well, encoding to V2 and V0, and I don't have any problems either in iTunes or on the iPod with displaying incorrect time lengths.

It's not really the "time length" display... it's just that it gets cut off. As I said, I don't really have the problems on most of my encodes... but I did reproduce it using a few of eMusic's LAME encodes and it only happens with iTunes. The last one I tried was encoded using 3.96 -- but I have no specifics on what parameters beyond "-V 2" they used. (Most of the content seems to be 3.93.)

So maybe it could be related to how it was specifically encoded, but the "problem" only appears with iTunes...

EDIT: I forgot mention, in my tests... it generally only happens if I skip around or "fast forward" through the track... if I play the track from beginning to end without interruption, the end isn't cut off.

I think I have discovered the problem.

I ripped a track using LAME 3.97 to test to see if iTunes played that file back without stopping. iTunes showed the file as 23:08, however, played the file through to the end at 23:25.

I used MP3Gain on the file and tried playing it with iTunes and iTunes stopped playing the file at 23:08.

Seems the problem is caused by adding APEv2 tags to the files using MP3Gain, or whatever MP3Gain does to the file to increase the volume. This is causing iTunes to end the file early.

Edit: I was thinking about my results and they may be flawed. The MP3s I created I did not add any ID3v2 tags too during creation. I'll rip that song while adding ID3v2 + ID3v1 tags with EAC and see if the problem still occurs without using MP3Gain.

Edit 2: MP3s I ripped with EAC using LAME and did not tag with any tags played fine in iTunes. However, when I added ID3v2 and ID3v1 tags with EAC during ripping the problem occurred again in iTunes. I also tried adding the tags to the MP3s with LAME and the problem still occurred in iTunes. I even tried just adding an ID3v1 tag to the MP3 with EAC and iTunes still stopped play early. Finally I tried adding an ID3v2.4 tag to the MP3 with EAC and iTunes stopped playback of that file as well. Seems like iTunes is having a problem with tags of some sort.

Ok, I'm back with more information.

Quesiton: Can you encode your music to MP3 using the LAME encoder and still have it work in iTunes?
Answer: NO.

At least on the Mac OS X platform, there are no encoders which will work.

CD Stack, iTunesLame, LameBrain, Max, and NMP3 Ripper do not work.
Lame versions 3.95, 3.96, and 3.97b2 have been tested. None work.
Your songs will always be truncated no matter what encoder you use, no matter what LAME version you use, and no matter what bit rate or setting you specify (as long as it is VBR). Every song will be truncated.

Conclusion: If you use iTunes and/or an iPod, you cannot use any version of LAME or any encoder utilising LAME to encode VBR mp3s properly. CBR will work fine, but ALL VBR MP3s will have truncation problem. This is a problem with iTunes (specifically header information).

Until there is a fix (either from Apple or 3rd party), that seems to be it!

As a test I made an 80 min test file with a wave editor. First I repeated an arbitrary music sample so that the track duration was exactly 78 minutes. For the last two minutes I looped a selected 5.000 second sample 24 times and got an exact duration of 80 min 0.000 s. This 5 s sample has clearly distinguishable start and end passages so it is easy the count the amount during listening.

Then I converted this wave file to MP3 using LAME 3.97b2 -V5 --vbr-new. The resulting MP3 file did not have any ID3 or APE tags.

Foobar could play the MP3 file without problems. It stopped playback correctly after the 24th five second loop.

Windows iTunes 6.0.4.2 was different story. According to its display it started playing these 5 s loops at 1:18:51 instead of 1:18:00. It stopped playback at about one second before the 14th loop ended (the display showed 1:20 at that moment). So iTunes truncated about 51 seconds from the end of the track. (= a bit over ten 5 s loops).

I tested the behavior a bit more.

I encoded three additional VBR MP3 files from the same source file with Helix, FhG and iTunes.

Here's how the files played with iTunes:

Helix (makes a standard Xing header)
iTunes displayed the file length as 1:20:00. According to the display iTunes started to play the 5 s loops at 1:18:51 (similarly with LAME), but this time iTunes continued to play them all. At the end the display showed 1:20:51.

FhG (I used Wavelab 5 for encoding, probably the file has Fraunhofer's VBRI header)
The file length was displayed only as 1:11:20. The 5 s loops started at 1:09:53. iTunes played all 24 loops. At the end the display showed 1:11:53.

iTunes (a hex editor shows the word "Xing" in the header area, but I have no idea if this differs from a regular Xing header)
The file length was displayed as 1:20:00. The 5 s loops started at 1:17:57. iTunes played all 24 loops. At the end the display showed 1:19:57.


Edit: fixed a mistake (the iTunes "start" time was incorrectly 1:17:53, and VRI > VBRI )

So, nothing got it right on ay 80 minutes, 0 seconds...

I ripped more CDs using iTunes built-in encoder w/VBR. Flawless.
However, it isn't really LAME. iTunes 6.0.4(3) seems to have a much better encoder than the previous ones, and I will not inject bias for no reason: I would really like to see if there are ABX tests for LAME 3.97b2 vs iTunes 6.0.4(3) anywhere.

Anyone know of any?

I guess I'll just have to CBR them all!

Unfortunately when searching I did not come across this, so I started another topic here.

What I've been seeing is CD to LAME VBR via EAC seems to scrub fine (meaning you can fast forward) and tracks play through OK to the end in iTunes.

However if I convert something like FLAC to WAV to LAME VBR, I get the problem with the track cutting out towards the end if I've skipped around and forwarded through the track. This problem only occurs in iTunes on both Mac and Windows. Other players on Windows (foobar 2000 and Winamp) seem fine and the Finder in Mac OS X plays through completely to the end even while forwarding through tracks.

The solution is really simple: ditch iTunes.

So what are the steps to replicate this problem?

My library is almost entirely LAME VBR mp3s and I've never experienced this problem.

Everyone should contact apple and complain about it saying to either fix the problem (itunes 6.0.5.xx is still doing the same thing) or to use lame as there standard mp3 encoder.

Find me a better program to replace iTunes that doesn't make me use POS Windows.

On iTunes display, no, but the important difference is that all other MP3 files played up to the very end of the audio content. Only the LAME encoded VBR file was truncated. The playback stopped about 51 seconds before the real end of the audio content.



I explained how you can reproduce the problem. Wasn't that clear?

For example: Open any long audio track in a wave editor and paste some speech like "one-two-three-four" 20 times after the original content. Then just encode the file and test how many "one-two-three-four"s iTunes can play.

It seems that the error is smaller with short files and increases when the file duration is longer.


Edit: Make sure that the test file doesn't contain silence at the end of the track.

Edit 2: In case this wasn't obvious, I didn't try to play the complete 80 min tracks without skipping towards to the end of the tracks.

OK, I sat down and tried to replicte the problem. I was able to do it with relative ease. I tested six different songs:
Korn - My Gift To You
Korn - Dirty
Korn - Daddy
Korn - Kill You
Korn - When Will This End
And I threw in a 4:37 track, Korn - Clown

All of them had problems in iTunes if I skipped ahead in the tracks. There is a song at the end of My Gift To You called Earache My Eye, iTunes cut into this song by 5 seconds. There is static at the end of Dirty and iTunes cut this off by 15 seconds, there is some dialogue at the end of Daddy and iTunes cut this off by 20 seconds, there is a acapela version of Twist at the end of Kill You and iTunes cut this off by 3 seconds, and there is a live version of One at the end of When Will This End and iTunes cut this one off by 1 second.

So, I thought that iTunes did this because all these tracks were 8 minutes and longer. So I tried Clown which is a 4 minute and 37 second track. I played the track from the beginning and counted how many times "Your just a f**ken' little" is said at the end of the song. He says it 7 times then the song ends 2 seconds later. iTunes played it fine without me skipping ahead. I then played it again but I skipped ahead by 2 seconds. Well, at the end of the song, he only said it 6 times which means that iTunes cut off a total of 9 seconds on a 4:37 track.

I am really dissapointed now. I don't want to use any other mp3 encoder other than Lame. My 5G 60GB iPod plays everything fine, even when I skip ahead or rewind. I only have problems with iTunes. iTunes is fine if I transcode those Lame VBR mp3's to iTunes VBR mp3's. iTunes is also fine with VBR mp3's encoded with Helix (RealOne player) and VBR mp3's with Nero's PowerPack Lame plug-in.

I am going to bug Apple about this now and send them a e-mail about once a week. I wish Apple would just use the Lame mp3 encoder in iTunes instead of the Fhg one. I don't remember where I heard this but, I heard that Apple might be fixing this problem at their conferance in August.

P.S. The solution is not to ditch iTunes. Sure, it may be a resource hog in Windows but it is the only software that can easily integrate with the iPod and the iTunes Music store, it has a clean UI, and I have been using it since 2003 and really don't want to learn any other jukebox that looks like it was made in the basment of a Linux fanatic (not that there's anything wrong with Linux or Unix).

At first I doubted that this issue existed, but recently I transcoded an audio book from eight casette tapes to a single VBR MP3 for my mom, and the resulting file, when played in iTunes lops off about forty seconds of the end. The amount of time removed from the end of each LAME MP3 is relative to the length of the file and is also tied to the bit rate of the file. A long, low bit rate file, suffers the most.

I've noticed that some of my favorite podcasts, when encoded with LAME also exhibit this issue. Some of my longer Japanese lessons are missing large chunks at the end.

This is an iTunes issue and not an issue with LAME, but unfortunately, that's a little like having an Internet Explorer-incompatible website. I wonder if Apple will address this issue, or just enjoy the fact that it forces some LAME die-hards to AAC.

Anyway, my appologies to those I expressed my doubt to earlier in this thread.

iTunes is not the slickest, or most capable player (that would be Foobar, which I also love) but we come back to iTunes, quirks and all, because it is insanely comfortable, and the organizational aspects of it are second to none.

I hope Apple cares to resolve this issue.

I'd just like to add my 2 cents worth, which might not even be worth that much, as I'm just echo-ing the complaints previously expressed.
I produce 4 podcasts each week. On average, they each run between 15 - 25 minutes.
The 44.1kHz 16 bit stereo wav's are encoded to --vbr-new -V5 using 3.97b2.
iTunes (I've so far tried v5.0, and v6.02) ALWAYS cuts off the last 10 seconds (or thereabouts). Yes, I am jumping to the end of the files to check them... I've never actually let it play all the way through to see if that would work properly.
Interestingly though, I've never had a listener e-mail to complain about this phenomenon.
Bizarre.