Good point, Robertrobcfg wrote:The last byte in the block is the CRC of the block.
The structure is as follows:
0x55 Lead
0x3C Block Begin
0x?? Block Type
0x?? Block size
Size bytes of data
0x?? CRC
0x55 Trailing byte
So, most probably, the script isn't counting on the CRC byte and does mistake it for a data byte.
you're right.
Now I doubt the correctness of the block 'header' I have seen in the CAS files:
55,55,55,3C,01,FF
Assuming the first $55 is the trailing byte of previous block ...
There is an extra $55 if the header of data blocks has only a lead $55 byte, or am I wrong?
But there are 90% of files that despite that extra $55 are well loaded into Orchestra90cc
Now that is fooling me!
Acording to this data structure, a block consists of 255 bytes + 6 extra bytes
So the distance between the beginning of consecutive blocks must be:
$FF + 6 = $105 bytes
But if you look at the CAS files generated by the perl script, the blocks are extacly $106 bytes apart
that is to say 105 plus the extra $55 byte ...
Should I believe that the data input routine wil skip any byte untill it finds the synchronisation byte $3C?
This is the only explanation I can find to this numbers difference.
Anyway, even if the CRC is well calculated, the data in the example I chose is missinterpreted ...
This needs a whole revision of that file from the beginning
I think that I am going to verify it with a Java app, because manually is annoying for such an amount of bytes.
thanks a lot
cheers
pere