I am new to the forums, not sure if this is the right place for this question (having asked in general forum, so I am hoping you might help:)

Itunes is dropping/losing the sound at the very end of mp3 tracks which other players are playing fine.

This became noticeable with some CDs that are either live (or soundtracks) that have some tracks without a silence gap, or no gaps at all. I ripped and encoded using EAC and LAME to MP3 vbr (v2 new). Strange thing is when playing the mp3s of an album in itunes, itunes literally drops the sound the last second or so of the track then starts up seemingly losing the first bit of next track. However, the same mp3s played with MS Media Player (for comparison) dont' lose anything, and while there is a very slight pause between live tracks, it's barely noticeable with media player. Interestingly, Itunes will properly play the source ripped .wav file all the way to the end!

I am in a bind because I need to setup an iPod / iTunes for a client, and I have already got hundreds of CDs encoded. I never realized iTunes would have this issue. Can anyone advise? (I am not using crossfading in itunes, btw.)

I know many people don't use itunes, but I need to configure it for a client so I have no choice. I hope there is someone on this forum that can help me!!
THANKS !!!

Newer models of iPod (including the Video) shouldn't have anymore problems with VBR MP3s.
But iirc, older models up to the Nano still have problems with VBR MP3s.

Of course, cmiiw, as always.

Have you tried to encode some test MP3 files with Windows Media Player 10 and iTunes? You could try WMP10 at 192 kbps and iTunes with a similar VBR setting and test if the behavior is any different.

Turn off the cross fade playback option. With iTunes open, click on edit, then click on preferences. Click on the playback tab and just uncheck the cross fade playback option. For some strange reason, Apple has setup iTunes so that its default playback mode uses cross fade. It is supposed to give the illusion that it is playing back the tracks gaplessly but I find it annoying.

Dumb question, but do you have crossfade in iTunes turned on? iTunes has a really crappy crossfader which can cause this sometimes.

If this is only happening to VBR MP3 files, then download a program called "VBRFix" and run it on those files. This will regenerate the Xing VBR header. I had some MP3s that had problems with shortened (or lengthened) tracks in iTunes because their VBR header was broken. It might help.

Did you guys read the original question?


So I suppose howiezows is not using the iTunes crossfader.


So the files have VBR headers (if the setting really is -V2 --vbr-new)

If there's not an bug in the version of LAME he's using, of course.

You take a bit too much for granted, IMO. I prefer to actually try things until the problem is found. If he tries VBRFix, and it works, well then that tells us where to go looking for root causes, no?

Sure, I just asked an innocent question.

As I said, I think trying CBR Fraunhofer (WMP) and VBR iTunes files would tell if the used encoder can make any difference. It might be a good idea to try LAME CBR too.

It is odd that iTunes chops files. It should play any MP3 files normally gapped since it does not have a gappless playback function.

Edit: typo

That's what bugs me. iTunes doesn't chop files. At least, I've never noticed it chopping files like that, and I have 3000+ VBR MP3 files still in my library.

The cases where I did find it chopping files turned out to be files that lacked a Xing header. Every time. The time it displayed and played the file was wrong because it assumed the file was CBR and it seems to do a simple length calculation using the bitrate of the first frame in that case.

Now, in those cases, the file showed up in iTunes as CBR when it was not. So looking at what iTunes actually thinks the bitrate is might be useful.

First, Thanks for your input, I've been experimenting and have some new information -- I'd love to hear your continuing ideas:

To clarify: I'm using LAME version: 3.97 beta 2 (and EAC as the front-end program.)
I have been testing using the same .wav file of a track from a live album.

RESULTS:
1.) Itunes plays the .wav file to the end without a problem.
2.) Using Itunes itself (built-in option) to encode to VBR 192 bits, resulting mp3 plays fine in itunes all way to end of track.
3.) Using LAME (via EAC to process the .wav) as CBR [-b 192] produces mp3 which Itunes plays all the way to end of track.
4.) Using LAME with various vbr settings (including [-V 2 --vbr-new] and [-V 2 ]) the resulting mp3 will not play to the very end in itunes. Over one second is dropped.
5.) Tried using the vbrfix program, it did not solve this issue.

Does anyone have any thoughts based on the above? Also:

• Can I eliminate the ripping of the .wav file from consideration (as a problem) based on above?
• Not being an expert, could the issues relating to either CD player offset or LAME offset be in any way influencing this? (I'm guessing not, due to same wav file playing ok when encoded with CBR but not VBR.)
• One last thing: I have not yet even tried this on an iPod - this is all within Itunes for Windows. The iPod is still in the box for imminent transfer of music (again, this is for a client, I am actually new to the iPod scene! )

THANK YOU again, in advance for sharing your combined expertise!!!

Ripping the wav can be eliminated, as CBR works as ist should with the same file that gives problems with VBR. This also rules out CD player offset problems. I don't know what exactly you mean by Lame offset, I hope you didn't touch the encoder offset menu in EAC, it should be left at the default value.
To rule out a bug in the Lame version you are using, try e.g. with Lame 3.90.3 --alt-preset standard. If this gives the same problems, the problem has to be in how iTunes handles VBR files IMHO.

I'm having the same problem. Did someone figure out the resolution?

Just one update: Playing the same MP3s on the iPod itself results in complete play all the way to the end of each track. That solves my biggest problem since my client will ONLY be using the iPod, not using iTunes. Of course in a live album, there is a slight blip of "audible silence" between tracks, but this is a known and documented "shortcoming" of the iPod player.

Howie

I just noticed the same thing on the final note of the Brandenburg Concerto #1 in F - 1 Allegro. It cut out just before the complete fade. Thinking this might be a LAME issue, I looked at the command line option and changed the parameters to "-h --athlower 3" (to lower the decible threshold by half, re-ripped the CD and this time it worked.

I have found a pretty good solution. It seems that the Lame and VBRFix seek tables just aren't quite right for iTunes. I have had good luck re-building the VBR table with MP3 Tag Studio 3.5 b17. Not perfect, but the whole song (many of my "songs" are very long classical peices) usually plays after seeking.

The seek table in general isn't (and cannot be) very accurate for long tracks. So, if you want to jump to frame XX, do a seektable lookup you actually get frame XX+/-something. Any player that relies on the accuracy of the seektable-derived file offset for frame XX and doesn't play all remaining frames after a seek is a stupid one.

Edit: Sorry! This wasn't very constructive. But I just wanted to point that iTunes is to blame.

tbowman,

You could have posted in this newer thread: http://www.hydrogenaudio.org/forums/index....showtopic=45684

In this post I published my test results. iTunes stopped playing a long LAME VBR file 51 seconds before the real track end.

I have not tried the latest iTunes version yet. Probably Apple has fixed the bug. Otherwise properly working gapless playback would not be possible.

Yes, I agree. There is nothing inherently wrong with using a seek table to jump to a point x percent into a song, but iTunes seems to keep its own time state, and when it gets to what it thinks is the end, it just stops! Stupid. I tried various "seek-table rebuilders" after noticing that the one made by iTunes itself seems to work perfectly. I was going to write my own that would generate the same offsets as iTunes, but decided it wasn't worth it.



Ah, OK, I'll switch threads. I am skeptical that iTunes can do perfect gapless playback with MP3s, though. Since every MP3 frame generates 1152 samples, the only way to do it is to re-encode the songs as a group, and move the transition points between songs very slightly. As far as I can tell, the only thing the iTunes "gapless" flag does is turn off the crossfader, and maybe shovel out the next song's first frame a little faster!

I too am sceptical, but haregoo's report here looks promising. It seems that iTunes actually uses the LAME header info for gapless playback.