Re: Setting iTunes album art with ScriptingBridge
Re: Setting iTunes album art with ScriptingBridge
- Subject: Re: Setting iTunes album art with ScriptingBridge
- From: has <email@hidden>
- Date: Fri, 23 May 2008 22:40:42 +0100
Bill Monk wrote:
The biggest issue with the album art is simply getting the image
into PICT format, since last I checked, iTunes won't accept any
other format. Unfortunately NSImage can read but not generate PICT.
The only way I found to do it was to use <ick> QuickDraw APIs to
create a GWorld, then draw the NSImage into it, and then create a
PICT from the GWorld.
True, though actually the OP showed a clever little technique using
NSPasteboard, much easier than a GWorld and works great.
In the past I've used Image Events, it'll convert many formats to a
PICT file, then read from offset 513 (skipping the PICT header) to
get the data iTunes wants. Works fine.
The difficulty isn't with the PICT data, it's that a script like
this, which works under Tiger:
tell application "iTunes"
tell current track
try
set data of artwork 1 to myPICTData
on error error_msg number error_num
display dialog error_msg & error_num
end try
end tell
end tell
does not work under Leopard.
I rather suspect it is a data problem, although exactly what is hard
to say. Unfortunately, the 'standard' AEDesc image types (typePicture,
typeTIFF, typeEPS, etc.) lack any sort of formal definition from
Apple, which really doesn't help things. In theory, they should just
be the image data stuffed into the descriptor's data handle plus the
appropriate four char code for the descriptor type. In practice, it's
pretty much up to individual applications what they do, and since it's
not a common feature you can likely expect even more screw-ups than
usual.
All I can really suggest is that you try to reverse-engineer what's
going on in iTunes' cranky internals and then work back from there.
e.g. I dragged a small PICT file, test.pict, onto iTunes to create an
album cover, and then ran the following:
#!/usr/bin/ruby
require 'osax'; include OSAX; include Appscript
d = osax.read(MacTypes::Alias.path('/Users/has/
test.pict'), :as=>:PICT_picture)
p d.data
puts
d = app('itunes').current_track.artworks[1].data.get()
p d.data
Looking at the two dumps, it's pretty obvious that what's coming back
from iTunes isn't the same data as the original file; the latter
actually looks like PNG data with a PICT file header, which I've a
sneaking suspicion is different to before. I wouldn't be surprised if
iTunes' internal implementation had been changed recently only for the
developers to forget to update its scripting API to accommodate this
change (the artwork-related APIs have long been notoriously rough).
On Leopard, you get param err instead. Other variants I tried didn't
work either, often getting good old "Unknown object type" error, so
something sure seems to have changed.
File bugs on iTunes' artwork APIs, and go jump up and down on the
AppleScript team to spec this stuff properly so that application
developers know what they're meant to do.
This works up to the -addObject, which throws error -10014: "Handler
only handles single objects."
SB's -addObject: method, along with its whole object creation process,
is defective by design and is already known to fail on iTunes and
various other applications which don't march lock-step to Cocoa
Scripting's tune. Go use objc-appscript instead; unlike SB, it's
designed for maximum compatibility with existing AppleScriptable
applications, and on the very, very rare occasion that its high-level
API does choke its multi-layer design allows you to fall back to its
mid-level APIs fairly gracefully. And once you get over the initial
paradigm shift (Apple event IPC is RPC plus queries, not OOP),
appscript's approach just makes a whole load more sense since you're
dealing directly with the application's own APIs without having to dig
through a whole load of obfuscatory faux-OOP crap to get there. You
getter documentation and developer tools too; plus the whole codebase
is completely open and hackable (MIT license) should you feel the urge
for that sort of thing.
HTH
has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden