How to extract patch names from preset files?

johndunn · Post by **johndunn** » Mon Apr 07, 2008 4:50 pm

Anyone know how to extract patch names from preset files? I've looked at a binary dump of the files, but there is no clearly defined text.

I need to get the preset names so I can see them in a patch change function in an external program.

Any help will be greatly appreciated.

Lima · Post by **Lima** » Mon Apr 07, 2008 11:57 pm

I don't think it's possible.
A workaround could be : do a screenshot, crop it to the preset area and then traslate it using an OCR application.

johndunn · Post by **johndunn** » Tue Apr 08, 2008 10:52 am

Let me put it this way: If anyone can give me enough information so that I can decode and extract the patch names from the SPF preset files, I'll give a free registration key for ArtWonk or MusicWonk, your choice. This software works great with Scope, except that it needs to know the patch names for presets in order to give you a list to select from. As it exists you have to just use numbers. Works, but having the names is nicer.

Taking a screen shot and running it through an OCR, while obvious, is not a practical solution. There are dozens if not hundreds of patches, so you need an automated way to do this. Something like a right click and copy to the clipboard would be OK, but thePreset dialog window doesn't seem to have anything like that. So assuming I can get this information, I intend to write a utility that will read the preset file and spit out a little .txt document with the patch names.

If I am able to do this, I'll also make the utility available here or on my site as a free download.

John Dunn
Algorithmic Arts
http://algoart.com

Post by **garyb** » Tue Apr 08, 2008 12:00 pm

that sounds good, you should contact s/c...

sharc · Post by **sharc** » Tue Apr 08, 2008 12:32 pm

Not exactly what you're looking for, but might help...

http://www.planetz.com/forums/viewtopic ... highlight=

RX seems to have put a lot of work into this already. It should be possible to get the preset names (for most of the CW devices) from the file he's kindly supplied. Would be a good idea however, to give him some credit if you do so.

capacitor · Post by **capacitor** » Tue Apr 08, 2008 1:34 pm

Here's where we are at the moment:

Installed two Unix-like packages into Windows XP. Shell is my preferred environment. The first one is called UWin, and is old. The second one, which I've used for development, is called Msys (we don't need it here, but I mention it because it is better supported imo)

Copied a preset file, 4-Pole M.pre, into the UWin environment, and renamed it, making it easier to work with (from 4-Pole M.pre to 4-Pole_M.pre).

In Unix, there is a command called 'file', which examines the first few bytes of any file. It does its best to accurately report the contents of the file. Anyone, please PM me for details on how it works. I used to teach this stuff.

Uwin's file command reports that the preset file is gzipped:

$ file 4-Pole_M.pre
4-Pole_M.pre: gzip compressed data, win/32, deflate

Let's try unpacking:

$ cp 4-Pole_M.pre 4-Pole_M.gz # for convenience with gunzip
$ gunzip 4-Pole_M.gz

Well, It sure is. Gunzip exits with an exit status of 0 (no problems) and 4-Pole_M appears, with no file extensions.

$ vi 4-Pole_M (attached screenshot)

Unpacked, the factory file's preset names are visible. Almost as important, it looks like it has a repeatable pattern. Note that "Piano Resonancer" is offset a certain amount, then further down you'll see "Ballad Resonances", offset by the same number of characters from the left.

Vi is Not the way to go when pulling the names out of the file, of course

I'll be back to calculate the offsets of the patch names.

-cap

capacitor · Post by **capacitor** » Tue Apr 08, 2008 3:13 pm

Continuing, using the Unix "od" (octal dump) command, to determine the byte offsets of the preset names.

Attached is the result of running the following:

$ od -c -A d 4-Pole_M > 4-Pole_M.doc # .doc b/c it opens in Wordpad on Windows to preserve the columns

Looking at the locations (byte offsets) of the beginning of each preset name, here's the pattern of the first 7:

163: Slow Motion
343: Piano Resonancer
527: Pad Gater 140 BPM
711: Space Filter 120 BPM
903: Organ Gater 120 BPM
1087: Ballad Resonances
1271: HH Regroover 100 BPM

In offsets from the immediately previous preset name:

NaN
180
184
184
192
184
184

So, this isn't consistent. Next: looking at the offsets, using the null byte that ends the preset name field.

Back shortly - cap

hifiboom · Post by **hifiboom** » Tue Apr 08, 2008 3:25 pm

wow some interesting info here.

capacitor · Post by **capacitor** » Tue Apr 08, 2008 3:29 pm

After staring at these file dumps, I'm starting to feel like the Operator in those Matrix movies.

capacitor · Post by **capacitor** » Tue Apr 08, 2008 3:55 pm

Further results, using the trailing null byte of the first 7 preset names.

174: Slow Motion
359: Piano Resonancer
544: Pad Gater 140 BPM
731: Space Filter 120 BPM
922: Organ Gater 120 BPM
1104: Ballad Resonances
1291: HH Regroover 100 BPM

In offsets from the immediately previous preset name:

NaN
185
185
187
191
182
187

This means (apparently) there is not an absolute consistency of preset record sizes. In other words, the presets may possibly vary, in terms of their sizes in the preset file.

Still not done - MusicWonk looks awesome!

However, I think I need a beer or two, while I rest my eyeballs.

The next step is to look for preset delimiter byte sequences, and see if the preset names align to those. This needs to be portable, i.e. the same algorithm should work on any device's preset file. I would expect that the presets for other devs are not identical, size wise, than this randomly chosen one.

Glad to help, even if we can't ultimately get this solved.

capacitor · Post by **capacitor** » Tue Apr 08, 2008 4:17 pm

Just to add another, more probable possibility: the offsets in the preset file may be stored in the header or footer of the file. In other words, a list of offsets, with an offset value for each preset.

If SC would send me the includes, that would help - however this is probably not a good idea (NDA).

Back to brute force

johndunn · Post by **johndunn** » Tue Apr 08, 2008 6:05 pm

You've taken it from not likely to maybe, which is great. Have another beer and keep it up. I'll be back at the computer tomorrow morning.

bassdude · Post by **bassdude** » Tue Apr 08, 2008 6:36 pm

If you just want the names, in unix you could run "strings <filename>" on the unpacked file to pull out all text most of which, I imagine, would be preset names.

capacitor · Post by **capacitor** » Tue Apr 08, 2008 9:14 pm

Ahh, but the devil is in the details, Grasshopper!

Thnk of the od-text-file dumps as more accurate versions of running a basic strings on the preset files. Getting strings/vi/od to expose the preset names is the first step. The next step is predictability.

The preset names/strings have become visible in a factory preset file. Now, how to pull any given factory preset file into an algorithm that spits out the preset number and the associated name.

Without run-on sentences, which are, somewhat partially, the result of the pre-assimilated beers.

hifiboom · Post by **hifiboom** » Tue Apr 08, 2008 11:52 pm

if you find out the exact file structure, i could possibly code a little preset randomizer, that does suffle the parameters of a synth with all parameters in a certain range.

so you could just generate a 200 presets bank in a second or so.... and then go into the synth load it and check out which ones sound useable..... and save them in an extra bank....

Lima · Post by **Lima** » Wed Apr 09, 2008 4:04 am

this sounds very interesting...

capacitor · Post by **capacitor** » Wed Apr 09, 2008 4:41 pm

Just a quick update. I'm looking at both possibilities (record demarcation as well as indices).

Edit: there's a third possibility - each preset has it's total record size encoded in the first few bytes of itself. Scope reads in the first preset, using that size, and the next preset is automatically there on the next fread()/read() etc.

capacitor · Post by **capacitor** » Wed Apr 09, 2008 7:32 pm

Verified that preset record sizes significantly vary from device to device (expected).

capacitor · Post by **capacitor** » Wed Apr 09, 2008 9:14 pm

PM sent. May have a working algorithm. Next is to do a rough implementation, in the form of a C program.

I'm installing my dev environment ATM. It'll be a bit, but for gunzippable preset files this may fly.

I'll have a good shot at this later this evening, or early am Friday at the latest. Stay tuned

Post by **irrelevance** » Wed Apr 09, 2008 11:15 pm

Do it man, do it!!