[daubiParticipant]

that could be an option, but
you loose a portion of the haptic of the user interface.
I could accept it, if this software would run on a small
computer and you can transfer the scene setup via an extra
robust button (bluetooth, WLAN)

[daubiParticipant]

but how you can find the values in the lut? and how to get a 4 byte “CRC” from a byte function?
and which range in the file is included in this calculation?

[daubiParticipant]

@Rayn I missed your reply.
what makes me wonder: the CRC is 4 bytes long. your propose is byte oriented. And if they use lut (look up table) how to find that one?

I made some test with a python script
https://github.com/antonmeyer/AH_DAT_Files/blob/master/tools/calcCRC.py

no success so far.
to be fair, I even have no glue how the binascii.crc32 really works.

[daubiParticipant]

@Rayn meanwhile I’m back with the idea of CRC.
The tricky part is: how do they calculate it?
I have constructed 2 scenes with the same settings, same Name, but different scene numbers , ending up in different .DAT file names. starting with A1 00 FE 06 and the other A1 00 FE 07. They end up with the same CRC. So I guess the first 4 bytes are not within the CRC calculation.
Might be the same for the A5 makers, as there a easily to check, whether they are correct or not.

And for the math: changing scene name from Scene 1 to Scene 2, changes 2 bits, ending up in different CRC. 11 4C 68 A7 and EA B8 BE 74

By the way tricky part was to put all faders to max low, as there could be some “noise” in the position data otherwise.

Next task will be to make a CRC tool.

[daubiParticipant]

attached some files with extra bytes after the CRC. I guess this happens when you overwrite a sceen. Had to rename it to txt as the forum software does not like .DAT

Attachments:

You must be logged in to view attached files.

[daubiParticipant]

here I try to upload a file with extra data behind the CRC.
I renamed the file extension, as the forum does not like .DAT

Attachments:

You must be logged in to view attached files.

[daubiParticipant]

@danz As I can generate the table from the MS Word script, it would be fine to transfer the Mic settings to the Qu.
The Pad has a save scene function? I have not found it. But anyhow this would not transfer the table to the Qu. But would be good to know, that there is a remote way to save scenes.

[daubiParticipant]

here some files with bytes behind the CRC.
My guess, this happens if you overwrite a scene

[daubiParticipant]

@danz could you give me some starting support for the communication with a Qu-24. I’m looking for a way to program the scenes in a fast way. From the directors script I generate the table for the microphones, which needs to be open. (per scene a row) And this table I want to transfer to the Qu-24.
First idea has been to “decode” the storage file format (.dat files)
But if there is a chance to do so via MIDI or DAW, it might be the better way.
I did not found a MIDI command to store a scene.
So the work around might be a manual button push for every scene.
With 40 scenes it might still faster than entering every detail via the Qu-24 buttons.

[daubiParticipant]

I do not believe any more in the CRC. Checking all files I have, there are to many “collisions” (same value for not identical files).

There seems to be sections, started with a section number followed by a5a5a5.

Unfortunately I do not have mixer to check, which modification it would except.

[daubiParticipant]

As I do not have access to the Mixer, can someone try the following:
Make 2 scene, keep all settings identical, double check Qu can load it.
Check the CRC at position 0x651C, if it is identical.
Than start modifiying beginning of the file until it fails loading.
I recommend binary search.
By that we should be able to identifying the range for the CRC calculation
To make format analyzing more exciting my files have different length.
Some have 0x6520, others 0x6640. But CRC is at same position.

[daubiParticipant]

can someone host a Wiki, which collects all known facts about the file format?
I compared to identical scenes. In the file you can see the scene number (4. byte). And that is
the only difference. -> if there is a CRC, not all of the file is included in the calculation.

[daubiParticipant]

It is really strange, A&H does not response at all to this feature request.
As I work once a year for a very low budget production I have to lent the Qu-24
and only a little time to prepare 9 Scenes with 23 inputs, this year.

Reverse engineering their file format could be a hard job.
And they might change little details every release.
Knowing the basic idea / concept of their file store could help a lot.

The CRC issue could be checked by changing 1 piece (letter in a name or so)
and compare both files with diff.
Once you see, which values are changing you can make assumptions.

Their might be no CRC at all. Just a length field. CRC is typical on file system level.

I get my Qu-24 end of November ..but than my time is limited.
May be I will save some scenes and analyze details later.

[Author]

Posts