Update findings.txt

Author: giveabit

findings.txt

@@ -14,30 +14,7 @@ recording followed by 32 k from the overdub and so on.
 
 So everything from 138032 bytes on is audio in some interleaved format.
 
-The header (0...138031 bytes offset) contains information on audio parts start implicitly:
-- coded in dwords within offset 1300...1319 (decimal)
-- first dword value+138032 = latest end of part 01 and earliest start of part 02
-- second dword value + first dword value+138032 = latest end of part 02 and earliest start of part 03
-- ...chain goes on until part 05 (5 dword values in total)
-
-Due to the interleaved nature of the file format, checks have to be performed on those boundaried determined
-by the dword values in 1300...1319.
-
-I have not been able to figure out the correct start vaules, lenghtes or ends for the parts from the header alone.
-Thus the code (as of version 0.67) performs the boundary checks and gives out ALL possible audio chunks - i.e.:
-in case of overdub detection the earlier starting and the later starting audio chunks are both written
-to separate files. I cannot discern only from the header, which part is the 'valid one', at the moment.
-
-Further part information is stored in chunks of constant 10752 bytes starting at the address:
-part number - hex offset - dec offset
-01 - 14930 - 84272
-02 - 17330 - 95024
-03 - 00019d30 - 105776
-04 - 0001c730 - 116528
-05 - 0001f130 - 127280
-FF FF FF FF values seem to mean: This part does not exist / is not recorded. Plus some other bits. To be figured out...
-
-And there's still more I found out - but unfortunately not useful at the moment. Will add that later.
+ALL INFORMATION ON THE ADDRESSES ARE WITHIN THE 'Trio+Addresses.xlsx' - HAVE A LOOK AND CONTRIBUTE !!!
 
 Ah, and no: standard midi information is NOT within the header (in terms of messages according to the midi specs).