I'm reverse engineering a file format in which (amongst a whole lot of other things I have already decoded) the 'length' of the file is being stored.It is displayed to the user as minutes:seconds.Doing a little bit of experimenting by altering the file and loading it up in the program, I've gathered the following possibilities:Original:5d42: 0:55Altered:5240: 0:030000: 0:00003f: 0:000040: 0:020041: 0:180042: 0:320043: 2:080044: 8:320045: 34:081045: 38:240046: 136:320047: 564:080048: 2184:320049: 8738:08004a: 34952:32004b: invalid004c: 559240:33004d: 2236962:15004e: 8947849:00004f: 35791396:000050: 143165584:000051: 572662336:000052: 2290649344:000142: 0:320242: 0:320342: 0:320442: 0:330542: 0:330642: 0:330742: 0:330842: 0:340942: 0:340a42: 0:340b42: 0:340c42: 0:350d42: invalid0e42: 0:350f42: 0:351042: 0:361142: 0:36My guess is this is some sort of floating point, but I'm too limited in my skills to know what kind.I know all other numbers in the files are stored as little-endian.Does anyone have any clue?
What could this time format be?
file format
This seems very much like the IEEE754 format, and i'd assume each of your two byte timecodes to be preceded by two zero-bytes, which make a 4 byte (32 bit) value.You can calculate the exponent using the formulaexponent=(byte2 * 2 - 127)and the value in seconds usingvalue=2^exponent*(1+byte1/128)assuming the high-order bit of byte1 is clear; if you set the highest bit in byte1, you'll probably get a negative value. (If byte1 is zero, as in most of your examples, value is equal to the exponent, as the multiplicand is 1)Note you have a typo in your value for 0041, that should be 0:08, not 0:18, and you probably made a mistake when checking the 004b value, that should be 8388608 seconds, or 139810:08 minutes.