BLFReader with incosistent data sizes

### Describe the bug
Two bugs seem to occur with reading data from a `blf` log file (CAN FD).

1) Using `log = BLFReader(file)`, the returned data seems to skip error frames. I have used another software to analyze messages and identified `n_error` error messages. Analyzing `log.object_count` vs `len(list(log))`, I can see that `log.object_count = len(list(log)) + n_error`. This is odd since the documentation states that error frames are validly returned.

2) Some message seem to end prematurely. That is I do know the length from other software and my `dbc`-File but the lenth in the raw messages from `BLFReader()` is less, e.g.
```
messages = [(msg.arbitration_id, msg.timestamp, msg.data) for msg in log]

for msg in messages:
arbitration_id, timestamp, data = msg
try:
ret = dbc_db.decode_message(arbitration_id, data)
except KeyError:
...
```
where `dbc_db` is a `cantools.Database()`. This raises the exception during unpacking that the data is missing 8 bytes, which is indeed the case looking at the core message data. Any other software correctly identifies the data at the given arbitration ID to be 8 bytes longer, thus allowing the unpack:
`Error: unpack requires at least 256 bits to unpack (got 192)`
The bytearray looks a bit strange with some \x seemingly translated(?)
` bytearray(b'\x0c[\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00SS\x00\xd8G')`

### To Reproduce
Im sorry but I cant share the file

### Expected behavior
consistent messages in length and data content

### Additional context

OS and version: `Win10`
Python version: `3.10.10`
python-can version: `4.1.0`