In pod5 files the number of samples prior to the adapter/sequence should be encoded in the metadata, and can be looked at using ONT's `pod5 inspect` tool:

```
$ pod5 inspect reads pod5_file.pod5

read_id,channel,well,pore_type,read_number,start_sample,end_reason,median_before,calibration_offset,calibration_scale,sample_count,byte_count,signal_compression_ratio
00445e58-3c58-4050-bacf-3411bb716cc3,908,1,not_set,100776,374223800,signal_positive,205.3,-240.0,0.1,65582,58623,0.447
00520473-4d3d-486b-86b5-f031c59f6591,220,1,not_set,7936,16135986,signal_positive,192.0,-233.0,0.1,167769,146495,0.437
...
```

The average translocation speed can be worked out by comparing the `sample_count` to the number of called bases.

More details [here](https://pod5-file-format.readthedocs.io/en/latest/docs/tools.html#pod5-inspect).

Unfortunately, due to the way the basecaller models work, I don't think there's any easy way to create a 1-sample lookup table for precise instantaneous translocation calculations.

If it is just an out of memory error, then it should work (but very slowly) if you set the basecaller batch size to 1 (i.e. `-b 1`). If even that doesn't work, something else is going on and it's unlikely to be a memory problem.