Errant Control Characters in Metadata
As you probably know: when you first mount a new CD and have a look at it in iTunes, the track information you see, for the most part, is not from the CD. (Well, there is such a thing as CD Text but it is not widely used.) Instead, this information is typically retrieved over the internet from Gracenote, a company that maintains an information database of virtually every CD.
Ostensibly, the record labels provide Gracenote with the correct metadata for their products. But users can contribute "corrected" track data to Gracenote from many music apps, including iTunes. Crowd-sourcing this information famously has its, uhm, pitfalls.
Recently, a Correspondent told me of an issue with finding return and linefeed characters in the Name tags of some of his tracks, metadata which were undoubtedly retrieved from Gracenote. These control characters aren't supposed to be used in iTunes tags. In fact, entering a return character in most iTunes text fields is usually a signal to end editing. At best, iTunes does not accommodate line ending characters very well. The ID3 Tag spec may not permit them either, but I am not certain. Of course, I suppose it is possible that some other music app does allow return or linefeed characters in its track entries database.
So, evidently, perhaps someone was able to upload Name metadata to Gracenote formatted with line breaks, something like so:
Cycle for Children v2 XI Jerring Song ' The Sun Shines Into The Church' (allegro ironico) (Gyermekeknek Sz42)
(At first, I thought the problem was that a linefeed was somehow "attached" to the single quote character; but in the second instance the linefeed is followed by a space. So maybe this was just poor cursor placement or bad automation.)
Depending on the app and the UI element that is rendering this text, the linefeed characters may not actually "feed" a new line but instead will be replaced with a space character (on the screen, anyway). This leads me to think that perhaps the source machine was a WIndows box; there was a time when "Mac or PC" made a difference in this regard. I still see Windows XP-era text effluvia in some Comments tags, for example.
In any case, while it may seem that formatting Name text with control characters wouldn't be a problem, its the sort of thing that may "work fine...until it doesn't". My Correspondent found that several AppleScripts of mine that he was using weren't working to remove these errant control characters. (Who knows what kind of havoc may be unleashed when syncing these tracks to a device or iCloud?)
So, I created a simple script that removes any return or linefeed characters from the Name tags of a selection of tracks in iTunes.
(There are a number of ways of doing this, but novices should grasp the concepts here.)
tell application "iTunes"
set sel to selection
if sel is {} then return
repeat with aTrack in sel
try
set name of aTrack to my filterReturnLF(get name of aTrack)
end try
end repeat
end tell
to filterReturnLF(badtext)
set goodtext to {}
repeat with i from 1 to (count characters of badtext)
set w to character i of badtext
if w as text is not linefeed and w as text is not return then
set end of goodtext to w
end if
end repeat
return (goodtext as text)
end filterReturnLF
Save this in Script Editor with a format of "Script" and name it whatever you like—"Filter Line Endings in Names", for example—and put it in your ~/Library/iTunes/Scripts/ folder so it appears in the iTunes Script menu. Select some tracks whose names may contain the probelmatic line endings and launch the script by selecting its name from the Script menu.
There may still be some additional clean-up to do. You can find more tools here on the Scripts Recommended by Task page.