I think I know how to do this but it's as pain in the ass, so I don't want to write it if someone has done it already. (There's no way to say "track whose location is X" so I think you have to do it the long way around, by iterating every track until you find a match.)
No good comes of any question involving Applescript, really.
This script creates a playlist called ZZZ_cmdplayline based on the filenames passed on the command line. (iTunes will import the music if it's new, otherwise use the existing imported song). It then plays the list, sets the playlist to repeat and switches the view to it. Optionally it will append new tracks to the existing list or delete all existing entries before adding new ones.
The magic is
add posix file "/path/to/file" to user playlist plname
Combination of bash to create applescript. HTH.
So the problem with using "add" to get a handle on the track is that sometimes -- but not always -- that causes a duplicate entry to show up in the DB. Then you have to delete one of them, and half the time you'll pick wrong, and the "date added" of the track will change.
The less flaky way to make this work would be to build up a table of every track's location, mapping that to database ID, and then you can do "track with database ID".
Hmm, I've used this script on a regular basis for years and never had that problem. It's my standard way of picking an album to play ("play /mp3/SONGS/ALBUMS/The_Jam/Greatest_Hits/*'). Maybe helps that I don't sync my music to other sources; it's a standalone iTunes instance. Hmm...
This "mapping from Location to DBID" is something I've been pondering for a while. I always gave up without coding it up when I kept hitting the problem that AppleScript doesn't have anything like associative arrays for looking up the locations once you've obtained the list, but tonight I decided screw it, I'll just try brute force linear search for the lookup and see how bad it is. Answer: it's not too bad. I have about 15K tracks in my iTunes library, and it takes a few seconds to grab all the track info, and then less than a second (on a six-year-old MacBook Pro) to linear search through them in AppleScript. Good enough for v1, maybe good enough forever.
And so I give you: v1: http://www.technomaki.com/hacks/code/MakePlaylistFromTrackLocations.txt
Seems to work OK for me, on my machine, but all the usual disclaimers apply, plus extras because AppleScript.
I have successfully avoided Applescript and iTunes (at least for music) for a few years now, but the python-appscript library was pretty nice. It talks the same AppleEvents as applescript does, but there is no actual applescript involved anywhere, just python, so a lot of the gratuitously-awful applescript stuff goes away. I think there's a Ruby equivalent as well. I seem to remember the Perl glue modules worked in a different way and weren't as good, but like I said this was a while back.
It's always weird watching jwz try to get applescript or itunes to work, but I guess everyone has their kinks.
The Ruby interface has worked for me in the past. I've also successfullyish used the ObjC "AppleScript Bridge" to write a small CLI tool that talks to iTunes via AppleEvents and that's pretty light-weight, if a bit frought with its own issues.
But our host here asked for AppleScript, and since I like this party, I obliged.
I implemented something similar years ago with perl and Mac::Glue
Mine imports a directory of mp3s and adds it to a new playlist.
I think "add" will only create a second database entry if the file path & metadata doesn't match something in the itunes database. This might happen when extended character sets don't play well.
See what you think of http://paste.lisp.org/display/133959
This guards against the second copy of the track being added by testing the date added, and iff the track was just added, it searches for an alternative with the same name, album, artist, kind, bit rate, disc count, disc number, track count, track number, year, but an older date added. If such a track is found, it removes the newly added track and uses the old one.
Maybe I'm missing something, but if you have the filenames already, couldn't you just make an m3u in perl or sh really, really easily? Surely, iTunes will import one of those? I'm sure I'm missing something obvious, but I'm not sure what...
I didn't say "import the files". I said "make a playlist in iTunes that contains the named files". The files are already imported and I don't want them fucked with, I just want a playlist of them.
I meant import the playlist, not the files. Anyways, I tested it in iTunes on my work computer just to make sure I wasn't totally missing the point. What I did is:
1) Make an m3u playlist in ~/Music that has relative paths to files that are already in the iTunes Library
2) File -> Library -> Import Playlist ... (I assume you can AppleScript that somehow?)
It didn't appear to create duplicate instances of the files in the iTunes Library. I assume this is less good in some way than just creating the playlist directly in iTunes, but I don't see how. Maybe this has the potential to create duplicates in some corner case?
Oh, right, I think that would work! Thanks...
Actually, now that I think about it -- and based on the length of time that it takes -- I believe that what iTunes does in that case is an "import" of each of those files, with the same chance of ending up with duplicates that I mentioned in my above worry about using Applescript "add".
Well, that would probably be the reason that no one else uses that method. At least I have my answer now. heh.
Anyways, I'm sure you're right. I just can't fathom why iTunes wouldn't have a good (read: 100% accurate) way to quickly tell whether a file is already in the iTunes Library or not, given a filename.
Well, if you didn't want them fucked with, why did you put them in iTunes?
* plonk *