Structure of the LiveSet RDS-File

[dalemmi]

Hi all,
would anyone be interested in some reverse engineering on the structure of the LiveSet RDS-File? As I understand, Roland does not intend to lay open the data structure - so maybe we have to take things into our own hands. After all, we purchased these expensive machines and should not be prevented from operating them at their full potential...

If we could find out a little more about the structure it might well be possible to create a RDS-Librarian software that would allow swapping and storing (and sharing) individual LiveSets. It might also open a possibility of replacing (some of the less favorable) quick access "preset" SN-Pianos, since their data is also contained within the file and could therefore be manipulated.

I did a little bit of number crunching today by means of a crude hex-editor and -comparer and found some basic structures, that might help further exploration (These findings probably only apply to firmware versions >= 2.0):

File size is constant 561762 bytes
Contents: 260 blocks of each 2160 bytes + 162 bytes of footer
Data of LiveSet 001 starts at file offset 0x00000
Data of LiveSet 200 ends at file offset 0x6977f
From file offset 0x69780 there are 60 further 2160-byte-records for the SN Piano Presets
After this follows the footer of 162 bytes (probably containing some general system settings), closing with the firmware version ("RD-700NXV02.000") and appearently a 2 byte checksum at the end.

From making some parameter changes and comparisons between the contents of the file I was able to identify a few positions, where certain parameters are stored within each 2160 byte record. Finding out the whole parameter set and dependencies still seems to be a long way to go (any volunteers?). For a next shot I would be happy to find out:
1.) How and at what offsets the LiveSet names are encoded and
2.) How the checksum at the file end is calculated (MD5, CRC, simple parity, ...)
With this information, it would be possible to create a simple librarian application.

Who would like to join the effort?

[dalemmi]

In the meantime I found out that the RDS-file is not really encrypted, as suggested elsewhere. Appearently the data is simply not stored in a conventional 8-bit pattern, that would be easily readable in a hex-editor. Instead, the letters of the LiveSet names are coded as ASCII, but in 7-bit chunks, so the max. 16 letters of a LiveSet name are squeezed into the first 14 bytes of each LiveSet data block (16 * 7 bit= 112 bit = 14 byte).
Possibly also other portions of the data are compressed this way - I had the impression on some occasions, but have not checked in detail yet.
So, this problem solved - I just need to find out, how the checksum at the file end is generated. It seems there is one checksum byte at the end of each LiveSet-Block, possibly the checksum byte at the end of the file is generated from these. Maybe MarcoPolo can help out on this one?

[MarcoPolo]

The final check sum is not based on a check sum of other check sums. It works like this:

Take the LiveSet File area 0x00000 - 0x8925F and sum the individual
bytes. If the result is 0x012345AB then the lower 2Byte i.e. 45AB will
be the checksum.

Easy to see if you look at the sum of the other bytes in hex.

[dalemmi]

That helps - thank you! Am I right in assuming that each LiveSet also has an individual checksum-byte at relative offset 0x87F? If so, how is it calculated?

[Benoit]

Hi guys,

I looked to find some information about the RDS-file format library and I just found this thread.
I would like write a simple RD settings editor and thus a RDS library.
I would like to join the effort. Did some of you make any progress since December ? We should just start by writing a simple RDS specification document. What do you think? Are you always interested in it ?

[dalemmi]

Hi Benoit,
I contacted MarcoPolo in December. He stated that he had created a basic librarian but wanted to add a few of the requested features before releasing it. Unfortunately he needed to shift priorities for personal reasons, explaining the long silence. As I understand, the librarian he made would "only" be able to move livesets around and save them seperately. This would be great already, but still far away from a patch editor (which I would dream of).

For looking deeper into the structure of the RDS-file and fixing the spec I could share a spreadsheet with my first findings on byte-offsets that could be amended every time we identify more parameters. What do you think?

Since I am not running Windows, I would be most interested in a cross-platform application development - but anything would be fine for a start. Unfortunately my last programming experience was on MS VB... :-(
So I will probably not be of much help for the coding.

DaLemmi

[janvdbergh]

I realise this is an old thread, but does anyone know if any more work has been done on the RDS file format?

I recently bought an RD-2000 and the file format looks similar: repeating blocks, 7 bit ASCII characters. The file size is not the same though: for the RD-2000 it is 2041304 bytes long.

When I have some time I'm interested in investigating this further and writing / updating software tools to manipulate the files.

[davidlang42]

Hi everyone,

Sorry for reviving an old thread, but I've been meaning to do this for a while and I've actually done it!
It's a work in progress, but the latest release v0.3.0 makes it useful enough I thought I'd share it around.

https://github.com/davidlang42/roland-rds

Currently set up for RD300NX but minimal work required for 700NX or potentially RD-2000.

David.