You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 example
0x8A
, 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
%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 ...
(length03 48
is divisible by 4, so no padbytes, so wrapper records the same length)8C 00 00 8A ... XX XX
(length00 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.
The text was updated successfully, but these errors were encountered: