Nord User Forum

Hi, has anybody attempted at deciphering the ns2p format?
what I feel is missing in the nord sound manager is the slots status.
this is surely stored in the ns2p file somewhere.
I'm writing a python tool to handle and rename ns2p filee offline ( more news to come ) but i am having difficulties figuring it out.
I'm currently using a hexadecimal binary editor and running some tests and any help to point me in the right direction would be most welcome.

thx

Nord Sound Manager is a Librarian, not an Editor, apart from the ability to manage Samples associated to a Program; that's why you can't see in it any other Program parameter, including the Slots saved status.

The .ns2p format may be flat or encrypted, an hex editor with a comparison feature is the correct way to attemp to reverse engineer it, by moving 1 parameter at a time. But if encryption and/or validation checksum(s) are in the file this may become a very tough task to accomplish. Good luck...

maxpiano wrote:Nord Sound Manager is a Librarian, not an Editor, apart from the ability to manage Samples associated to a Program; that's why you can't see in it any other Program parameter, including the Slots saved status.

The .ns2p format may be flat or encrypted, an hex editor with a comparison fetaure is the correct way to attemp to reverse engineer it, by moving 1 parameter at a time. But if encryption and/or validation checksum(s) are in the file this may become a very tough task to accomplish. Good luck...

thanks, i think I'm making progress!

Hi Varignet, any luck with this? I would love to be able to have a ns2p "viewer", so I can reprogram my sounds into the NS3. I should have never traded-in my NS2 before getting the NS3, but I wasn't aware that you loose all patches...((

Also interested to share ideas and where you're at.

I'm trying to find a way to see all programs that are duplicates, meaning not the name but the content of the entire program.
Idea is to extract from a backup file (which is a ZIP file) all the ns2p from the program directory (with sub-directories "Bank A"...) and do some recursive "FC /B file1.ns2p file2.ns2p".
I have 27 bytes different in 2 ns2p files I believe are the same.

I'll make further tests but would be happy to share info if any.

Fred

Hm... the format is not open, so I doubt that you will be able to do this reliably. Even a binary file comparison might have differences if only the patch is named differently.
Or imagine the same patch with a different part volume, or an effect switched on or off, would show a difference.

Mr_-G- wrote:Hm... the format is not open, so I doubt that you will be able to do this reliably. Even a binary file comparison might have differences if only the patch is named differently.
Or imagine the same patch with a different part volume, or an effect switched on or off, would show a difference.

Agreed.
My idea is to have a list of "identical" programs so I can make some cleaning.
Identical means exactly the same program parameters except the location #.

I'm making progress on the binary comparison but still digging.

Fred

OK, this turns out to be more simple than expected but hard to explain here.
Let me give it a try and go directly to the conclusion : you can identify 2 .ns2p files that contain the same program by comparing the binary files together.

I'm working now on the backup file which is a ZIP file and extracted the Program directory with the 4 sub directories (Bank A, Bank B...).
All files are 547 bytes.

I found out that the bank location of the program is located at position 000C.
A is coded 00, B is 01, C is 02 and D is 03

Page and Program locations are at position 000E. Remember always hexadecimal.
Let me show you an example if you want to get the Page and Program numbers (in decimal) from the value (in hexadecimal) found at 000E.
Say we have "3F" in 000E : 3F is 63 in decimal (=HEX2DEC in Excel)

Remember we had the formula to get the Program change from the Page and Program # : PCC = (PAGE-1)*5+(Program-1)
Back to our 63 decimal, some reverse math and we have :

Page = Quotient (63/5)+1 = 12+1 = 13
Program # = 63-(Page-1)*5+1 = 63-(13-1)*5+1=63-60+1=4

For identical sounds, there are also 2 different values in the 2 last positions at 0221 and 0222.
I believe this must be some CRC as there is no consistancy.

Therefore, I can now run a comparison binary program on all the ns2p files and identify those who have differences ONLY on those 4 positions, all others are different.
This is my first step : to clean identical programs in different bank/page/program.

Next step is to work on the comparison that shows few differences, say 1 byte more.
For info, I Identified while making tests that the leslie slow/fast is located at position 002C with hex values : 56=fast and 54=slow.

Hope that helps,

Fred

Mr_-G- wrote:Hm... the format is not open, so I doubt that you will be able to do this reliably. Even a binary file comparison might have differences if only the patch is named differently.
Or imagine the same patch with a different part volume, or an effect switched on or off, would show a difference.

I disagree.
I know it has been done for the DX-line of synths which has a propriety format as well.
It takes *a lot* of effort but if it's done by a human another human can figure it out (we're not talking about something like DNA ).

And if the formats are known you can build anything you want as Clavia won't change the layout and if it does you can simply compare the "before" and "after" results and amend your software.
There's bound to be a versioning or something in the patches or Clavia wouldn't be able to run conversions themselves (as happens sometimes between OS-releases).

You could build alternative librarians or filter out duplicates or even a generator that randomly assigns values to the synth part as a starting point for a new sound.

I know that for the DX7 there are tons of patches around so to filter out exact duplicates (regardless of name) is a big help, or group alike sounds based on certain parameters.
We're probably nowhere near that with the Nord sound-libraries right now but you'll never know.

cookie wrote:OK, this turns out to be more simple than expected but hard to explain here.

I think you're doing quite well
But then again I used to be a programmer.

cookie wrote:I believe this must be some CRC as there is no consistancy.

As I said in my comment to Mr -G- that's what they did in the DX7 and the simplist way to determine if the data is valid at all.
Probably a CRC32 or something

cookie wrote:For info, I Identified while making tests that the leslie slow/fast is located at position 002C with hex values : 56=fast and 54=slow.

There is a chance that certain parameters are bit-mapped instead of a complete byte if they only have an on/off situation.
or that part of a byte is used for a limited range (so 0,1,2,3 would be 00,01,10,11 in binary).
But you probably know this