a Physical Record may be padded with null characters to guarantee a minimum record size.
RP66 specification says nothing on the matter.
In reality we however see many files with random(?) padbyte characters added after the record to assure that for every record (declared_record_length + size(padbytes)) % 4 == 0.
At the moment we always saw it to be 2 characters. These two characters are not included in the record length.
For example
if record length is 0x8A, 2 bytes are added after the record.
if record length is 0x8C, no bytes are added after the record.
It happens in both dlis and lis files, but looks to be more common in lis ones.
At the moment we saw these %4 padded files wrapped into 2 types of envelopes:
TIFed files
TM.next correctly skips 2 padding bytes (if they are present) and points to the start of the next TM
Unknown envelope (LIS only).
We do not have enough information to state for certain, but it looks like size of the record + size of possible padbytes is written in little endian before each record. For example:
48 03 03 48 ... (length 03 48 is divisible by 4, so no padbytes, so wrapper records the same length)
8C 00 00 8A ... XX XX (length 00 8A is not divisible by 4, so 2 padbytes are added, so wrapper counts that length)
There is however no confirmation to this and we also don't know how many such files exist.
Note:
It's unclear if these envelopes can be mixed or if %4-padded files can be not wrapped into anything at all.
According to LIS79 specification,
RP66 specification says nothing on the matter.
In reality we however see many files with random(?) padbyte characters added after the record to assure that for every record
(declared_record_length + size(padbytes)) % 4 == 0. At the moment we always saw it to be 2 characters. These two characters are not included in the record length. For example0x8A, 2 bytes are added after the record.0x8C, no bytes are added after the record.It happens in both dlis and lis files, but looks to be more common in lis ones.
At the moment we saw these
%4padded files wrapped into 2 types of envelopes:TIFed files TM.next correctly skips 2 padding bytes (if they are present) and points to the start of the next TM
Unknown envelope (LIS only). We do not have enough information to state for certain, but it looks like
There is however no confirmation to this and we also don't know how many such files exist.
size of the record + size of possible padbytesis written in little endian before each record. For example:48 03 03 48 ...(length03 48is divisible by 4, so no padbytes, so wrapper records the same length)8C 00 00 8A ... XX XX(length00 8Ais not divisible by 4, so 2 padbytes are added, so wrapper counts that length)Note: It's unclear if these envelopes can be mixed or if %4-padded files can be not wrapped into anything at all.