That’s a big script to try and go through, and one I have no means of really testing myself. But I do have two observations having had a skim through it:
① The variable thisFile is not defined in the scope of this handler. It’s a variable that gets instantiated for the repeat loop in your (implicit) run handler that loops through the batch of files; however, handlers (and other objects that contain code, such as script objects) have their own domain for storing and referencing variables that are fenced off from one another. So the variables in the main part of the script are only accessible from the main part of the script; and variables in the mediainfoFile() handler are only accessible from within the mediainfoFile() handler; likewise for the returnNumbersInString handler; and so on…
You may notice, however, that one of the handlers does access a variable outside of its domain:
--THIS HANDLER READS THE XML DATA:
on trackInfo given type:type as text, id:|id| as text : -1, key:key as text
local key, |id|, type
global tracks
.
.
.
It does this by declaring the variable tracks with global scope, meaning that the trackInfo handler gains access to that variable, even though it was originally declared outside the handler, in the main part of the script. I won’t go into this in much more detail other than to make you aware of this. Generally speaking, I wouldn’t suggest declaring variables as global all willy-nilly, because it makes it very difficult to keep track of them in a script, and very easy to alter their values in another part of the script without meaning to (the reason it suffices to do this for tracks is because I specifically created that variable to have one, and only one purpose, and a singular instance of being seen in the main part of the script—the moment it is first declared. It couldn’t be declared inside the trackinfo handler otherwise mediainfoFile() would be called every time you go to retrieve a piece of information from the same file).
What I recommend doing is declaring a parameter (or argument) in the mediainfoFile() handler, which will allow you to pass the value of the variable thisFile from the main part of the script to the handler at the point where you call it. So this line:
on mediainfoFile()
will become:
on mediainfoFile(thisFile)
Note: Don’t be confused by the fact I’ve used the same name for the argument as the variable in your repeat loop; you can give this argument any name you wish, as long as make sure to change it in the line that comes immediately after, which currently uses thisFile. Although the variable in the repeat loop and the argument plus variable used in the handler have the same name, they are distinct entities, and have no relation to one another.
Then call the handler passing thisFile as an argument like so:
set tracks to the mediainfoFile(theFile)'s tracks
② The second observation I’m going to make is a tendency I see a lot in novice scripters, which is to use error-catching try blocks a) unnecessarily; b) in large quantities; and c) that encompass many, many lines of code within a single block. The consequence of all of this is that you have no idea where your script is encountering problems; what the nature of those problems are; what is causing those problems; and, therefore, have no means to know how to debug/fix the script.
Don’t get me wrong: effective, thoughtful error-catching is a good, sensible facet of scripting and programming, but it should always have a specific purpose, and be used to catch an error that you can predict will happen, under a specific set of circumstances you know will arise in your script, and that you know and understand why the error gets thrown. If the try block is there purely to ensure execution of the script isn’t interrupted by some inconvenient error that comes out of nowhere when the try block is removed, then all it is doing is masking a sick, broken script. Chances are, after one line throws an error that gets caught and swept under the rug, the lines of code that follow are at risk of doing the same.
I would suggest deleting every single try block in your script; running it; and painstakingly going through each error that arises, finding out the nature of the error in Script Debugger’s event log, or at the time of alert, and fixing them one by one. If you can’t fix them, the script is damaged and unreliable; if you can fix them, you won’t need the try block. If there are instances where you do need to use one for a purpose, try and have it cover only one or two lines of code, specifically targetting where the error arises, and having an error handling block that does something useful to cater for the dysfunction so that it doesn’t have a ripple effect when the script exits the block.