Timeline for Decode synth preset formats for massive (.nmsv) fm8 (.nfm8) and absynth (.nabs)
Current License: CC BY-SA 4.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 20, 2020 at 2:18 | answer | added | monomadic | timeline score: 0 | |
| Sep 9, 2020 at 18:30 | answer | added | monomadic | timeline score: 1 | |
| Nov 12, 2019 at 18:38 | vote | accept | Martin | ||
| Nov 1, 2019 at 15:43 | answer | added | Ian Cook | timeline score: 3 | |
| Nov 1, 2019 at 6:34 | comment | added | Martin | I've had a look at the main memory right after loading a preset searching for the "TESTSTRING". There seems to be an uncompressed version of the block - the plaintext strings are there and 4byte blocks which i would call the actual parameter values maybe as floats - however even with this information I'd hard to tell how the data in the compressed stream relates to the unpacked data. | |
| Nov 1, 2019 at 6:30 | comment | added | Martin | Hi Johann, I've tried zlib deflate on the data block (after last DSIN in file) before because zlib strings are in the binary but was not able to decompress it. Also the fact that plaintext strings are present made me think that its not zlib as it employs huffman coding. I have not come across zlib markers in preset files. So I thought its libpng or something that uses it. | |
| Nov 1, 2019 at 2:26 | comment | added | Johann Aydinbas |
It may be zlib. I had a quick look at my Massive in IDA and roughly in the neighbourhood where those DSIN and hsin markers are used and connecting stuff via RTTI names, I found zlib usage. According to the RTTI data they have some custom compressed stream class that appears to use zlib. Although the code also seems to check for 'zlib' or 'none' 4 byte markers which aren't in your sample preset.
|
|
| Oct 31, 2019 at 20:16 | history | edited | Martin | CC BY-SA 4.0 |
added 1478 characters in body
|
| Oct 30, 2019 at 23:40 | history | edited | Martin | CC BY-SA 4.0 |
added 118 characters in body
|
| Oct 30, 2019 at 23:32 | comment | added | Martin | I don't really understand yet how length and distance are encoded here - I thought there are definitely some "control characters" (e.g. @ 40h) which appear more frequently than other characters.I'll try to give an examples with different length strings so this might shed some light. | |
| Oct 30, 2019 at 23:12 | comment | added | Ian Cook | I've just come across LZSS more than the others. However, 11 consecutive plain text characters means it would have to be a different implementation to those I've seen before. Having some readable text in the compressed data does suggests it's a byte based method though. This likely rules out bit-stream based approaches e.g. anything using Huffman coding, or LZW with 12-bit or variable length codes. | |
| Oct 30, 2019 at 22:50 | comment | added | Martin | Hi Ian, what makes you think this would be LZSS compression? Could it be LZ77, LZ78 or LZW? I think with huffman codeing the code would look less "readable". Is there no dictionary at all or maybe a fixed one stored somewhere else? Thanks alot | |
| Oct 30, 2019 at 22:40 | history | edited | Martin | CC BY-SA 4.0 |
added 306 characters in body
|
| Oct 30, 2019 at 10:24 | comment | added | Ian Cook | This sounds very like some form of LZSS compression. A similar recent question on here is reverseengineering.stackexchange.com/questions/21981/… | |
| Oct 29, 2019 at 22:25 | review | First posts | |||
| Nov 1, 2019 at 19:32 | |||||
| Oct 29, 2019 at 22:20 | history | asked | Martin | CC BY-SA 4.0 |