Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Watch for a filename length issue in iTunes Apps
I've come across an extremely annoying bug with iTunes that cost me over an hour of my time this morning.

To back up my iTunes music library, I use a Smart playlist that automatically grabs any new music that I add. It's defined as "Date added is after [date]." At some point, I back up that playlist to DVDs using the "Burn playlist to disc" feature (which can handle backing up to multiple discs), and then reset the date in the Smart playlist definition. Simple and effective.

Except today. After I had burned two DVDs, iTunes balked on the third one with an error message to the effect that there was an invalid filename. But it didn't give me any indication of which track had the invalid name or what was wrong with it.

After following a few false leads, I found the problem: there is a limit of 255 characters to filenames on a DVD. When iTunes burns a track to DVD, it uses the track name and prepends a sequential number to it to create the filename on the disc. Thus, a track named "1. Allegro Energico" will end up on DVD as "001 1. Allegro Energico" (assuming it's the first track on that DVD). This is a simple way to make certain that there will be no duplicate filenames. Now iTunes enforces a 255 character limit on the length of a track name. The problem occurs when a track name is at or near that 255 character limit within iTunes. When it tries to prepend the sequential number, the name is now longer than the DVD's 255 character limit.

So why would I have a track with such a long name? Some CDs split an individual work into multiple tracks -- like the Richard Strauss tone poem Don Quixote, for example. When I import those tracks into iTunes, I tell it to join them together, so that during playback there won't be jarring pauses in the middle of the music. The problem is that iTunes then names the ensuing joined track by concatenating the names of all the component pieces.

Note to self: remember to shorten the track name when joining tracks.
    •    
  • Currently 3.60 / 5
  You rated: 5 / 5 (5 votes cast)
 
[11,456 views]  

Watch for a filename length issue in iTunes | 14 comments | Create New Account
Click here to return to the 'Watch for a filename length issue in iTunes' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Watch for a filename length issue in iTunes
Authored by: DougAdams on Feb 10, '05 10:43:51AM
Run this AppleScript on a Playlist you suspect may have tracks with long track names; it will copy the long-named tracks to a new discrete Playlist ("_Tracks With Long Names") so you can edit them.
property longPlaylist : "_Tracks With Long Names"
tell application "iTunes"
	set thisPlaylist to view of front browser window
	if class of thisPlaylist is not library playlist then
		set z to true
		repeat with aTrack in (every track of thisPlaylist)
			if (length of (get aTrack's name)) > 250 then
				if not (exists playlist longPlaylist) then
					make playlist with properties {name:longPlaylist}
				else if z then
					try
						delete every track of playlist longPlaylist
						set z to false
					end try
				end if
				duplicate (aTrack) to playlist longPlaylist
			end if
		end repeat
	end if
end tell

---
Doug's AppleScripts for iTunes
http://www.malcolmadams.com/itunes/

[ Reply to This | # ]

Watch for a filename length issue in iTunes
Authored by: Frederico on Feb 10, '05 01:42:25PM

Unless I misunderstand the OP's problem description, this script will not help, as it only identifies the track name as recorded in iTunes under the 'name' field, whereas the actual file name can be longer (or shorter) depending on both your preferences to have iTunes manage your library and the file type.

E.G., I have several files in my library with the following name format in Finder:

Tangled Up In Blue (live) - Bob Dylan - The Bootleg Series, Vol. 5; Bob Dylan Live 1975 - The Rolling Thunder Revue (Live) - 1975 (1977) (2002) - Rock - iTunes QT Videos.mp4

and yet iTunes reports the name only as 'Tangled Up In Blue (live)'.

So, if the OP's problem is that actual file name in Finder, the above script will not flag it. It would need to be modified to get the track's location, instead, and count characters less the parent file path, including extension. Isn't at all hard to do (should be less than three lines), especially for the iTunes Scripting Guru who posted this.

If I misunderstand the OP's original problem description, then please disregard this post.

Cheers

Frederico



[ Reply to This | # ]
Watch for a filename length issue in iTunes
Authored by: Frederico on Feb 10, '05 01:53:38PM
This should do it:

property longPlaylist : "_Tracks With Long Names"
tell application "iTunes"
	set thisPlaylist to view of front browser window
	if class of thisPlaylist is not library playlist then
		set z to true
		repeat with aTrack in (every track of thisPlaylist)
			set fileName to ((get aTrack's location) as text)
			set fileName to characters (-(offset of ":" in (reverse of every character of fileName as text)) + 1) thru -1 of fileName as text
			if (length of fileName) > 250 then
				if not (exists playlist longPlaylist) then
					make playlist with properties {name:longPlaylist}
				else if z then
					try
						delete every track of playlist longPlaylist
						set z to false
					end try
				end if
				duplicate (aTrack) to playlist longPlaylist
			end if
			
		end repeat
	end if
end tell


[ Reply to This | # ]
Watch for a filename length issue in iTunes
Authored by: DougAdams on Feb 10, '05 03:43:01PM

Of course. I scripted hastily!

Cheers.

---
Doug's AppleScripts for iTunes
http://www.malcolmadams.com/itunes/



[ Reply to This | # ]
Watch for a filename length issue in iTunes
Authored by: drewk on Feb 11, '05 01:25:32PM
Since the poster described the behavior of iTunes adding characters that then cause the filename to cross the 250 character limit, this line:

       if (length of fileName) > 250
needs to be:

      if (length of fileName) > (250-5)
to allow for the suffix on the name. Assumably 99,999 songs is enough ;->

drewk

[ Reply to This | # ]
Watch for a filename length issue in iTunes
Authored by: Frederico on Feb 19, '05 11:16:04PM

If you reread the OP, you'll see he notes a 255 character limit, standard for HFS+ under X, hence the >250 (251) character flag, which allows for the addition of up to four more characters safely.



[ Reply to This | # ]
Watch for a filename length issue in iTunes
Authored by: shavenyak on Feb 10, '05 10:51:16AM

Better yet, if Apple would just FIX ITUNES so it plays consecutive tracks without a gap, we wouldn't need that ridiculous Join Tracks feature.

Before anyone responds... no, setting Crossfade to zero doesn't work. At least, not well enough for listening to Pink Floyd. There's still a very noticeable hiccup at the transitions. There are some music programs that play them seamlessly, as God intended. Too bad they all either suck, or run on Windows (but I repeat myself... :) ).



[ Reply to This | # ]
Watch for a filename length issue in iTunes
Authored by: DavidRavenMoon on Feb 10, '05 12:37:41PM

It's not that simple. The reason for the gaps is that each song is a separate file, and there is a start and stop bit to be read. From what I have read, it's impossible to get zero gap without combining the files. So each file has to be loaded first. I would think that a series of files could be loaded into RAM and played with no gap, but I would imagine Apple would have been able to do this by now if it were possible.

Audio CDs on the other hand do not actually have separate files for each song, even though it looks that way in the Finder (the CD driver does that). CDs stream the audio off the disk, and any gaps between songs were actually placed there intentionally.

---
G4/466, 1 GB, Mac OS X 10.3.8



[ Reply to This | # ]
Watch for a filename length issue in iTunes
Authored by: huzzam on Feb 10, '05 05:26:46PM

So why can't iTunes just start reading the next file ten seconds (say) before the end of the current one, and thereby have the data ready? Even slow notebook hard drives are much faster than the data rate of mp3 music, so they are fully capable of keeping up with this.



[ Reply to This | # ]
Watch for a filename length issue in iTunes
Authored by: pstadelmann on Feb 11, '05 04:08:30AM

I do use iTunes to listen to continuous music, saved in separate tracks. There's no gap at all if you use crossfade (set to 0). BUT... My music is encoded using Apple Lossless. If you use a lossy format, then the very end of a track and the very beginning of nex track won't match anymore, which causes the gap. That's not iTunes fault at all. In fact, if you burn an audio CD from theses tracks using e.g. Toast, it will also hear gaps.



[ Reply to This | # ]
Watch for a filename length issue in iTunes
Authored by: ezthrust on Feb 10, '05 09:19:40PM

It IS possible. As anyone who has used WinAmp will tell you. Apple just doesn't care about this feature.



[ Reply to This | # ]
Watch for a filename length issue in iTunes
Authored by: silentway on Feb 24, '05 03:28:43PM
Yes, indeed, seamless crossfade is possible with compressed audio files, and Apple has not implemented it (yet). There are plenty of pro-level DJ apps that crossfade seamlessly, instead of the non-seamless "fade-out-then-fade-in" method. eg. Traktor DJ Studio 2. They do it by loading the files into memory first.
And, to bring the thread back on-topic, I once hit the 255 character limit in the title of a song (from Flaming Lips' "Soft Bulletin"). (This was with an older iTunes, though.) After entering it manually (not via CDDB), the CD would lock up my Mac. I had to manually hack the iTunes Library file to remove the entry before it would eject!

---
Tony Brooke
OS X 10.3.7, G5/1.8 iMac, 1.5GB RAM
http://www.SilentWay.com
http://www.TastyCast.com

[ Reply to This | # ]

Watch for a filename length issue in iTunes
Authored by: dfbills on Feb 10, '05 12:39:11PM

Isn't there a 255 character limit in the macos in general? Why is it surprising that itunes would _respect_ that?

---
-d



[ Reply to This | # ]
Watch for a filename length issue in iTunes
Authored by: Krioni on Feb 10, '05 01:28:45PM
The surprise is that when iTunes adds characters to a file name that is almost 255 characters, it should make sure the resulting name is less than 255. If it does not, it is not honoring the 255 character file name limit.

So, the problem and surprise is that iTunes here is not handling the limitation properly, but instead just failing. Proper handling would be to follow a user-definable preference on how to change the name automatically, or AT LEAST letting you know which file is causing the problem. The way its working now is almost the worst way to "handle" the limitation.

[ Reply to This | # ]