In Fixing up Files That Lostify Won’t Read, I talked about using AtomicParsley from the command line to strip existing metadata out of MP4 files.  This can be useful in situations where either an MP4 file contains tags that are somehow corrupt, or where bugs in AtomicParsley prevent it from correctly handling fragmented tags left over from past editing. Users have particularly encountered these issues when using the Cast Listing feature to embed (and later try to modify or remove) cast listings in Lostify.

While I am working on tracking down and fixing the related bugs in AtomicParsley, I decided to offer a more drag-and-drop solution for users who need to take this drastic action of stripping all existing metadata from an MP4 file.  So I put together Squeegify.  Sorry, I know the name is awful, and the icon’s not much better.

Squeegify, like Lostify, is typically launched by drag and drop. But in all other respects, it’s rather the opposite of its older sibling. Where Lostify presents a user interface and has numerous options, Squeegify does not (the only UI is its dock icon).  Where Lostify allows adding and editing metadata, Squeegify strips it out. Where Lostify can optionally overwrite existing files, Squeegify always outputs a fresh copy in the same directory as the original.

It really is a one-trick pony, but if you need to remove corrupt or otherwise unwanted metadata from an MP4 file, try Squeegify.

I’ve been in communication with a handful of users experiencing some technical issues with Lostify. While work is progressing on the next release, I’ve taken time out to put together a couple small utilities to try to help these folks work around the existing issues. This post is about one of these two new “workaround” utilities: MetaFreshen.

Lostify’s iTunes integration apparently fails for a handful of users. When you enable the feature to run Lostify from within iTunes, or to have Lostify add tagged tracks to iTunes automatically, these users begin getting errors like “Can’t get track 1 of library playlist 1 whose database ID of it = xxxxx”. Extensive efforts to debug this problem have proven fruitless; it appears to be a bug in iTunes’ AppleScript support. If this error happens to you frequently in Lostify, please let me know and I’d be glad to work with you to research the issue… but until we can discover the root cause and address it, I may have a temporary solution for you in the form of MetaFreshen.

MetaFreshen is an AppleScript that runs completely from within iTunes (thus working around the bug). It reads the full-length description out of the selected MP4 file(s) and set iTunes’ long description field appropriately. This means you can get the nifty little “i” button on your own movies and TV shows, not to mention descriptions that are over 255 characters. As you probably know, this is normally done by Lostify itself, but (as mentioned above) this is only useful in situations where that integration is failing for reasons unknown.

After downloading and unzipping MetaFreshen, simply install it in the ~/Library/iTunes/Scripts folder. You run the script by choosing MetaFreshen from the scripts menu inside iTunes. There is no user interface; it should simply run and quietly update the description for each selected file.  I hope it’s helpful to someone.

Occasionally, you may come across an MP4 file that Lostify will fail to read. Lostify may complain that it’s an invalid MP4 file, but this is not always the case. It may simply mean that while trying to read the existing metadata, Lostify encountered something unexpected and gave up.

In the future, I’ll continue to try to loosen up Lostify’s parsing code, so this happens less and less. I’ll also probably add a “repair file” command to Lostify for serious cases where the metadata may actually be unreadable by AtomicParsley. But in the mean time, you can repair these files manually using AtomicParsley, the command-line tool upon which Lostify is based.

Here are some instructions for doing this type of repair, assuming no prior knowledge of how to use Terminal. If this is your first foray into Terminal, however, please take care to follow the instructions closely!

1. In Finder, go to where you’ve got Lostify saved. Control-click the Lostify application, and choose Show Package Contents.
2. In the new Finder window that comes up, navigate to Contents:Resources. The first file in that list should be AtomicParsley. Leave this window up where you can get it later.
3. Back in the original Finder window, navigate to where you can see the MP4 file you want to fix. Also leave this window up where you can get it later.
4. Open a Terminal window (Applications:Utilities:Terminal.app).
5. Drag AtomicParsley from the Resources window in step #2 into the terminal window. The unix-style path to that file appears at the Terminal prompt, followed by a space.
6. Now drag the MP4 file you want to modify from the Finder window into the same Terminal window; its unix-style path is appended to what you did in the previous step.
7. Now append an instruction onto the end of the command you’re building in the Terminal window:If you want to clear all existing metadata out of the file, type
   

   -P

   Or if you only want to reset the Copyright tag, for example, you could type

   --copyright 'some new copyright text'

   There are lots of commands you can give to AtomicParsley; AtomicParsley will list them out for you if you simply follow steps 1-5 above (to invoke AtomicParsley by itself with no parameters).

8. When you’re done building the command, press Enter and the AtomicParsley program should execute the command you requested on the MP4 file. If everything was entered correctly, it should say something about writing to a temp file.

The output file will appear in the same directory as the input file, with the same name and “-temp-12345″ (actually a random number) appended at the end of the filename. This output file should now be able to be read by Lostify again; the input file should remain unmodified.

I hope this helps folks who have, for one reason or another, encountered MP4 files that Lostify fails to read!

Several folks have commented about Lostify’s unfortunate propensity for making copies of the video files you try to tag, especially when tagging files inside of iTunes. When you’re dealing with large files, sometimes over 1GB each, this can really take some time (not to mention disk space). And unfortunately, this is kind of a technical problem. Nevertheless, I’ll explain it here. Maybe the ensuing discussion will give rise to a better solution.

What you’re seeing here is a confluence of several factors:

1. Lostify tries to play things safe: because AtomicParsley (the command-line utility Lostify uses to actually modify MP4 files, hereinafter referred to as AP) is still in beta testing, Lostify doesn’t necessarily trust that it will not produce a corrupt video file. Such corruptions are rare, but they have been known to happen. To avoid this, Lostify has several different means of providing safety: it can (a) instruct AP to produce a separate tagged copy of the file, leaving the original alone; (b) instruct AP produce a separate tagged copy, then (if it appears to have been successful) trash the original and rename the copy same as the original; or (c) make a backup copy of the original, then instruct AP to overwrite the original file with a tagged version, and (if successful) trash the backup. Or there’s choice (d), which is to throw caution to the wind and just instruct AP to overwrite the original.
2. Options (a) and (b) above are straightforward — as far as AtomicParsley is concerned, the output is a new file. But whenever you tell AP to overwrite the original file [see options (c) and (d) above], two different things can happen. In a few cases, the existing metadata/tags are “just right,” and the file can be overwritten in place. But in most cases, AP must rewrite the entire contents of the file into a temporary file in the same directory as the original, and then it replaces the original with this temp file.
3. iTunes uses aliases rather than simple file paths to keep tabs on its tracks. This means that if you take a file in iTunes (while iTunes is running), move it to the trash, and replace it with a newly-tagged version in the same location and with the same name as the original… iTunes still goes ahead happily referring to the one in the trash. You have to quit iTunes and restart it before it will recognize the new file. (If anybody knows some clean and reliable ways around this, I’m all ears.)

As a consequence of #3, Lostify works differently when you are tagging files from within iTunes. If you have normally selected methods (a) or (b) for safety, Lostify substitutes method (c). This explains the extra copy operation you see — in fact much of the time, first Lostify makes its backup copy, then AtomicParsley makes another whole tagged copy as it works, then AP replaces the original with its tagged copy, then (assuming the new copy looks good) Lostify trashes its backup. Yeah, I know it’s wasteful, but at least it’s safe.

There are some cases when you might not care so much about the safety aspects. One would be if you already have the videos backed up somewhere — either in the same format, or (if you don’t mind transcoding again, in the rare case of corruption) in a different or original format. In cases like this, you’re much better off just choosing option (d), which will operate as fast as possible and won’t leave anything filling up your trash can.

Another case where you might consider “safely” choosing option (d) is if all your MP4 files come from a particular version of a particular encoder, and Lostify has already proven itself in producing reliable results with those files. For example, if you always encode your MP4s using QuickTime, and they always go through Lostify correctly, then you can be fairly certain that other MP4s encoded with the same version of QuickTime will also encode correctly. But if you update to a new version of QuickTime, you’d be wise to temporarily switch back to a safer method for Lostify to produce its output, until you’ve verified that things still work smoothly. The same goes for ffmpeg, iSquint, VisualHub, or whatever you use to encode your MP4 files.

Having said all that, I’m certain there’s a better way to be doing this. Maybe there’s a way for Lostify to tell iTunes (via AppleScript) that it should not worry about the old copy in the trash, but to look at the path instead to get the new version. Maybe I can work with the AtomicParsley folks to get it to be more “careful”, so the odds of overwriting a good original with a corrupt tagged version are drastically reduced (or eliminated). Or maybe someone reading this will have another bright idea to solve these troubles. I’d love to hear your comments.