Consider possibility to read not only data before the failure occurs, but after the failure as well.
There is no guarantee that data contained inside such broken files makes any sense (it seems that in many cases it actually does not), but we may let user decide.

We can always attempt to find next FF 01, go forward and see if that's a start of new VR or just random FF 01. For manual investigation next observations usually stand:

• About 90% of all VRs have almost-constant length 20 00.
• Some go by 40 00.
• It some cases number would be slightly less than 20 00, for example 1F FE or 1F F4.
• The last VR would be of whatever length.
• Some files surround every LR in own VR, so VRs are of corresponding length.

Notes:

• This approach might require a lot of backtracking and messy code.
• Sometimes trash data seemingly stops after some reasonable amount of bytes (somewhere up to 0xC000), and sometimes goes for gigabytes.
• It might be possible to read complete fdata parts inside of broken VRs (manually recognizable by frame names).
• Amount of useful data obtained this way would be quite small (by now saw probably around 100 files which might benefit from this approach).

Resolved by #296