Bank dump format

[music.maker]

Assumed that a bank dump should be just a collection of single preset dumps, so it would be possible to quickly extract (by software) the 128 presets of a bank dump. Surprisingly, the format of bank dumps appears to be completely different. Is there a specification of the bank dump format ?

[music.maker]

Send a message to Moog support, no reply. Wonder why is the Bank dump Sysex format so secret.. Apparently SoundTower has it.

[RL]

Hi music.maker,
it's not a secret:
http://www.moogmusic.de/SysEx.pdf

Rudi

[music.maker]

@RL, yes, thanks for that.I got that one. The issue I have is that a single preset dump is a standard SYSEX format enclosed with start of sysex and end of Sysex, However, you you look at a bank dump, it is only one SYSEX which should have have all the single presets of that bank inside. That is ok, but if you further look at the bank dump data, you won't find the same data bytes of the single patch in that bank dump patch. This is what confuses me. an example from the original factory banks. Above the single preset and below the start of bank
The single Bank A and first preset starts with F0 04 01 00 03 00 where 00 s the preset number (00) and the first data byte is 01.
The bank A dump start with F0 04 01 00 01 and after that you would expect the data of the first preset, which is not the same as the single preset data.

[RL]

Hi music.maker,
there is an additional byte (the preset number) in the single preset dump. The System Exclusive format sends 7 bits instead 8 bits cause bit 7 always must be zero. And that means bit seven of the preset number is on position bit 0 of the second sysex byte (the first preset data byte).

Have fun,
Rudi

[music.maker]

Many thanks Rudi for this eye opener ! Going to do some bit crunching and check this out...

[solitud]

I have a question which might be distantly related:
How do I get the patch names out of the sysex data? All my efforts lead to scrambled names ...

The implementation chart lists Byte 102 for "preset name 1 D0" and that works for me, it's always the right ASCII char.
103 to 109 look scrambled while 110 is good again.

I think it has something to do with the D0, D1, Dn, D7 declaration from the implementation chart table head, but I don't get what that means. Is that related to device id?

May be I have a general misunderstanding how that works, can someone give me a hint how to extract the patch names?

[solitud]

In the meantime I have figured out that the data is somehow encoded in 7bits per byte and needs to be converted to 8bit/byte and via versa.
Still would be great to have a source with more information about how to do that.
Is that the "Packed Data Format" with the stripped MS bits which Dave Smith uses or something different?

[till]

...
Is that the "Packed Data Format" with the stripped MS bits which Dave Smith uses or something different?

I have not seen a Dave Smith MIDI Sysex documentation. But the way the Voyager does is the way with the least bytes needed to do this needed 7 bit format of MIDI transmission.
You have to combine the needed bits in the 7 bit words. With this sysex documentation it is easy to do if write a little code for this job.

[solitud]

...
Is that the "Packed Data Format" with the stripped MS bits which Dave Smith uses or something different?

I have not seen a Dave Smith MIDI Sysex documentation. But the way the Voyager does is the way with the least bytes needed to do this needed 7 bit format of MIDI transmission.
You have to combine the needed bits in the 7 bit words. With this sysex documentation it is easy to do if write a little code for this job.

Thanks, I think I have understand it.
Look here for explanation of the Dave Smith implementation. In contrast to the Voyagers sysex there is also some wizardry with most significant bits involved.
http://www.manualslib.com/manual/640059 ... =65#manual

[AStoker]

Can you elaborate on the 7 bit conversion? looking at the document, the characters are actually split between bytes, so you would have to stream several of the bytes together in 7 bit chucks, then unwind it in 8 bits? I'm on a slightly different track looking for something like this document for the Taurus 3, and assuming Moog used the same algorhythm, Do you have this coded such that you could provide an example?

[solitud]

Can you elaborate on the 7 bit conversion? looking at the document, the characters are actually split between bytes, so you would have to stream several of the bytes together in 7 bit chucks, then unwind it in 8 bits? I'm on a slightly different track looking for something like this document for the Taurus 3, and assuming Moog used the same algorhythm, Do you have this coded such that you could provide an example?

Check this question on Stackoverflow.
It's about the decoding (7 to 8 bit) for an Alesis synth, but I found out it works for the Voyager too.
I have added my version of an encoding (8 to 7 bit) to the same question as a comment.

[highcooley]

Hey guys

After a full day of bit crunching, I found this thread which seems to be pretty recent. Well, better late than never
My motivation to reverse engineer Voyager .syx files is that I designed and built my own analog synth from scratch, using old Moog schematics as well as other circuit designs. I was inspired from the Voyager when it first came out, so my synth has almost all features of its archetype as well as some alterations and extras. To load it with some initial presets as well as to be able to compare it to the original, I would like to use the Moog factory presets. Since I don't own a Voyager, I found techbuzz's dumps here: http://www.maxforlive.com/library/devic ... ory-recall

What I figured out so far was to do the 7 to 8 bit conversion and I also constructed a first simple version of a grammar file for the "Hexinator" (Mac version "Synalyze IT") hex editor according to the same Voyager SysEx format documentation as linked above. Since I am not used to binary file manipulation, I used a rather complicated toolchain including the "Text to Sysex" tool to convert the .syx to .txt which I then imported to excel to do the conversion and then the same way back to a .syx files. This lead to a number of mistakes in the conversion formulas, but I found the patch names helpful to finally see all patches and be sure to have done the conversion right. The grammar file takes care of the SysEx Start byte as well as the Message Header consisting of four bytes.

According to the documentation, there shouldn't be a "preset prog-no" byte in a full preset dump. This results in 142 bytes per preset. Converting these from packed midi bytes to 8 bit data bytes results in 125 actual bytes. However, after modulating the preset structure as a grammar file, I soon figured out that a preset is actually 128 bytes long. The patch names helped me out again, since they shifted away from the assigned 24 byte string for the name. What I figured out is that these 3 extra bytes have to be located ahead of the patch names, since this leads to the first letters of long names also being the first assigned to the name string. But other than that, it is probably guesswork where they fit in. Maybe somebody with an actual Voyager could check his settings with this example (patch name "FiltOrgNasty(WheelUp)") and find out more (keep in mind that most potentiometer settings are stored as 16 bit NRPN values, so you have to cut away the last 8 bits and convert to decimal if you want to see a normal CC value):

One thing I also don't get is what type of character encoding is used for the patch names. As you can see on the print screen, "Nasty" has a typo. Unfortunately none of the about 30 supported encodings result in the correct character.

Of course, I am happy to share my current results:
Grammar structure file https://1drv.ms/u/s!AioTq3GZKEDxowcxZsSDSK9OFq8h
Converted Bank A to 8-bit https://1drv.ms/f/s!AioTq3GZKEDxowoeILQkfnKQIZlo

I am looking forward to hear how far you got since the last post.

Regards,
Andy

[solitud]

Hey,

I am looking forward to hear how far you got since the last post.

since then I programmed a SysEx librarian for Voyager in Javascript.
You can request the soundbank via MIDI, view and edit the patch names and store them back into editbuffer or program slot.

That is fully working and you can see it on https://f0f7.net

You can import/drag'n'drop your sysex files from your hard drive and the names should be displayed.
If you have a MIDI interface attached you will also see the 7bit hex/text content of a program when you click on it. (enlarge the browser window -> top left)
Maybe that can help you debugging?

I am not sure what you trying to do with Excel and that grammar file.

I have opened your "Converted Bank A" in the MacOs SysEx Librarian and it does not look like a valid Voyager sysex program. More like random segmented MIDI messages from different manufacturers. But maybe I have understood something wrong ...

[highcooley]

Hey,

Trying to upload an original .syx file (dump from a Voyager) into your SysEx librarian resulted in the message "I expected a different amount of programs."

What I try to do is somehow extract the actual preset settings and values from SysEx dumps, so I can then generate my own SysEx files for my self made Synth. The only tools i found to be capable of doing such a thing are Hex Editors. With for example "Hexinator" I can generate grammar patterns which parse the file and output the different preset settings. Unfortunately, Hex editors don't understand 7bit midi messages and therefore I had to remove the D7 0bit and regroup the bit stream to proper hex bytes. That's what I used excel for, since I am no programmer and didn't find an out of the box solution for doing that. The "Voyager Bank A 8bit converted.SYX" file is such a corrected file. The .syx ending is probably a bit misleading, since it doesn't consist of proper midi bytes anymore. So you won't be able to properly load it with the MacOS SysEx Librarian.

Any thoughts on that as well as where the surplus 3 bytes could fit in?

Regards