DLMS Translator and Association LN response with block

When processing association view object list responses, it seems that DLMS Translator can understand and display the object list when it is returned in a get-response-normal response, but can't do the same in case when the object list is returned in get-response-with-datablock response.

First, an example where it correctly parses everything. I took the essential parts from this thread: https://www.gurux.fi/node/21382

In this case, the part that comes after the InvokeIdAndPriority (leading info + the object list) is correctly interpreted down to the last detail of every object returned.

7E
...
C4 -- get response
01 -- get response normal
C1 -- invoke ID and priority
-- leading info (encoded in ASN.1?)
00 -- result
01 -- data
82 01 0F -- sequence of, 271 elements?
-- object list
02 -- structure / sequence of
04 -- four elements
...
F6 09
7E

DLMS_PDU[196] {** GetResponse **}
└──GetResponse[1] {** Get-response-normal **}
└──GetResponseNormal Sequence
├──InvokeIdPriority
│ ├──InvokeID (0..3): 1
│ ├──ServiceClass (6): confirmed
│ └──Priority (7): high
└──GetDataResult Result[0] {** data **}
└──Data[1] {** Array **}
└──SequenceOf 271 Element(s)
├──0: Data[2] {** Structure **}
│ └──SequenceOf 4 Element(s)
│ ├──0: [18] Unsigned16 = 10009 (0x2719)
│ ├──1: [17] Unsigned8 = 82 (0x52)
...

And here is the case when the object list comes in a get-response-with-datablock response. DLMS translator correctly recognizes datablock-G sequence (last block, block number and raw data), but for some reason does not attempt to interpret raw data further.

C4 -- get response
02 -- get response with data block
C1 -- invoke ID and priority
-- result: datablock-G (?)
00 -- last block (false)
00 00 00 00 -- block number
00 -- CHOICE raw-data
82 -- what is this encoding? If it's ASN.1, what's this 0x82 tag?
07 CF -- this is the byte length of all raw-data in this block
01 82 01 65 -- what's this part and why DLMS Translator does not attempt to interpret it?
-- the part below is object-list from Blue Book (DLMS Translator displays it correctly when it is inside a get-response-normal response)
-- 1st object
02 04 12 00 01 11 00 09 06 00 00 2B 01 00 FF 02 02 01 02 02 03 0F 01 16 01 00 02 03 0F 02 16 01 00 01 00
02 04 12 ..

GetResponse>
<GetResponsewithDataBlock>
<!-- Priority: High, ServiceClass: Confirmed, Invoke ID: 1 -->
<InvokeIdAndPriority Value="C1" />
<Result>
<LastBlock Value="00" />
<BlockNumber Value="00000000" />
<Result>
<RawData Value="0182016502041200011100090600... />
</Result>
</Result>
</GetResponsewithDataBlock>
</GetResponse>

I understand that, in the Green Book, raw-data is defined as IMPLICIT OCTET STRING. However, DLMS Translator certainly knows what the actual data structure is, since it was capable to interpret similar byte sequence in case of the get-response-normal request mentioned above.

Why is that? Which encoding is used for raw-data internally? What's the formal definition of the leading info sequence 82 07 CF 01 82 01 65 which precedes the actual object-list?

I know this is too many questions, but they all really refer to the same thing.

Thanks for any help and hints.