I recently wrote up an interview here on MacStories and although I was able to get it posted, I almost had to scrap the entire article because QuickTime crashed and I lost the recording of the interview.

I say it was a crash but to this day I still don’t know what happened. I had recorded my conversation with Ken Case on my Mac using QuickTime X player. The process to record audio with QuickTime is simple enough and it has never failed me in the past. After we got off the phone I immediately hit play on the recording to make sure the sound levels were adequate – first mistake. I should have hit Save then checked the sound levels. Not wanting to listen to the interview on the speakers in my display I paused the interview and left the room to track down my headphones. When I came back the audio recording was gone. The QuickTime application was still running but the recording window was gone.

My stomach dropped.

I frantically started tabbing through all of my open applications to see if anything else had closed, but they were all running. I checked all my desktop spaces and minimized windows but found nothing; it was gone and I hadn’t clicked save.

At this point, I hit up Viticci and started cussing like sailor at my own stupidity. He later told me that when I wrote up this recovery tutorial, I could post exactly what was said in our conversation. However it was so explicit that I decided not to.

Anyway, I started crawling the web for any information I could find on QuickTime temp file locations, Viticci and Cody contributed some suggestions as well.

Here are some of the potential locations I checked via web results:

$TMPDIR/com.apple.QuickTimePlayerX 

~/Library/Caches/QuickTime/ 

/tmp /var/folders/ 

/tmp/501/TemporaryItems/ 

/Library/Application Support/ 

etc... 

Unfortunately, none of those directories turned up anything useful. As last attempt I decided to run some 3rd party recovery software.

I did a quick Google search and downloaded a demo of Disk Drill for Mac. After running it for about an hour, it found a lot of deleted files, but not my QuickTime recording. The problem was I still didn’t even know what format it would be in or what filename it might have.

I soon remembered that I had a copy Data Rescue 3 so I immediately ran it. Data Rescue 3 ran for several hours, well in to the night, and found a lot more than the demo of Disk Drill found. However I was in the same situation, I had a lot of files but none of the audio recordings it found was the interview with Ken Case and I still had no idea where I should be looking.

So I decided I would start another recording in QuickTime, stop it, then check all of those temp location suggestions I had found. Unfortunately I didn’t find anything useful doing that.

Then by either divine intervention or a stroke of genius I opened a Terminal window and dragged the little QuickTime icon from the recording window in to the Terminal window and dropped it.

Sure enough, it printed out the location and file name of that test recording.

It all became clear, I can’t believe I hadn’t thought of it sooner. Now that QuickTime is sandboxed I needed to look in QuickTime’s container for the temp recording. I finally had all of the information I needed:

In the directory:

/Users/Don/Library/Containers/com.apple.QuickTimePlayerX/Data/Library/Autosave Information 

In a bundle called:

Unsaved QuickTime Player Document.qtpxcomposition 

I simply had to right click on the .qtpxcompostion file and inside I found the .m4a audio recording of my QuickTime test.

Now this is where the magic ends; this next part, the actual recovery of the file was thanks to Time Machine doing hourly updates. I simply had to open the Quicktime Autosave Information directory in Time Machine to the time right after I ended the call with Ken and there was my recording in its sandboxed temp directory.

I know this probably seems like common sense – just open up Time Machine and recover the file. However if you don’t know the filename or the directory it was located in your backup is not going to be much use. Thus, I felt this was worth sharing in case you are ever in the situation of having to retrieve a lost QuickTime recording.

Now you know where to look.

Developed by Steve Streza and released during last night’s App.net hackathon, Project Amy integrates App.net private messaging with the Messages application for OS X. A first version of Project Amy has been made available for download on App.net itself.

Project Amy is a clever experiment that showcases the App.net API and Apple’s IMServicePlugin.framework: using only public APIs and no proxies (unlike Steve’s first App.net project), Project Amy adds App.net as a native account in Messages, allowing you to have private conversations with other App.net users inside Messages. Once installed, you can simply login with your App.net credentials to have the account listed alongside AIM in the bottom left corner of Messages; choose Window > Buddies (or hit CMD+1) to show a list of users that you can send private messages to (they will be displayed as online with their full names rather than usernames).

Because it uses official APIs, messages sent through Project Amy also show up on App.net’s online messaging interface, Omega. In my tests, messaging with one or multiple users in Messages correctly mirrored the conversations to Omega, where they were updated in real-time without needing to refresh the webpage. I was even able to drag images into the conversation in Messages, and, while they didn’t show up as attachments on my end, they did appear as inline uploads on Omega and inside the recipient’s Messages application. Obviously, file uploads were handled by App.net’s File API as well.

Project Amy is a little buggy in this first version, but certainly promising. Aside from using an official OS X framework that few developers seem to know about, it shows the potential of the App.net API as a versatile solution capable of delivering more than just Twitter clones at this point.

Check out Project Amy here.