Advice on start to reverse engineer binary file formats?

[unsimp]

Hey guys. I'm working on reverse engineering a file format for the Zero88 jester's cue showfile and im looking to see if there is any resources i should be looking at for specifically file formats.
I'm using "Imhex" for hex editing.
here is what ive documented so far if thats of any help

Jester file format notes:

Show1.jsf is just blank
show2.jsf has a single cue with channel 7 set to max
show3.jsf is the same as show2 but with channel 7 set to 28 on the monitor

byte 0x0000000C -> 0F changes from 23 02 e7 03 ---> 24 02 E8 03 (im thinking this is a date code) on show1.jsf (blank) and show2 (with a cue with channel 7 set to max)

0x00000325 - 0x00000345 changed (this is the cue itself i think) (0x00000346 i think contains the actual value, on show2.jsf its 00 and on show3.jsf its 40)

for some reason on show2 --> show3 diff 0x00000008 changes from 00 to 01. no change in 0x0000000C-0F so i dont think its a date code

00 \n 20 padding on it ig to create a max cue count
0x000047A7 - 0x000047B1 changes for some fucking reason????? what (have no fucking clue what this is prolly related to the cue)

Help is appreciated. Ive linked the showfiles here if anyone else wants to take at stab at it

[Halamix2]

Four bytes at 0xC might be actually two shorts, then they would change between Show 01 and 02/03 from 548 1000 to 547 999, perhaps some kind of counter how much space/elements are free?

I don't have much experience with this kind of files, but you could try to make the same changes you did in Show03, but for a different channel/value
For instance changing this value for channel 6 might show you how big is the place for that in the file. These values might be just single bytes back-to-back,or each channel might have some kind of struct, so you'll see more bytes between and can deduce size of the whole "Array"
Or change channel 7 but with another value than 28 (although I think in this particular instance the value is stored at 0x47B1, since it has changed from -1 to 71, and software might do something like 100-71 = 28 if the value is not -1, dunno)
I guess reversing this kind of files is mostly trial and error with some small changes between files; unless there is some kind of a software/firmware files and executables that you can decompile and see how they interact with the files

[unsimp]

setting channel 7 to max causes it to be set to 0xFF and changing it to 0x50 (80) causes it to go to 31 on monitor
decreasing by 1 to 30 causes it to change to 0x4D (77)
increasing by 1 to 32 causes it to go to 0x52 (82) a difference of 5 huh is it for every odd increase it goes up by 2 and even goes up by 3 what i dont understand

i might try and see if i can capture the saving process in ghidra and reverse engineer it that way (though im using linux and apparently debugging wine apps with it is a bitch)
ill also see if i can get some firmware files as they do exist and also try that