Re: Setting iTunes album art with ScriptingBridge

FROM : has
DATE : Fri May 23 23:40:42 2008

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