Fixing incorrect sampling_rate

Usage Questions
1

Is there a way for obspy to fix files that have been saved with what is obviously an incorrect sample rate?
For example, here is a report from day-long traces of 4 stations:
LA23: npts=8640000, samp_rate=100.0
LA25: npts=8640001, samp_rate=100.0
LA30: npts=8640000, samp_rate=100.0
LA32: npts=8640000, samp_rate=100.00000762939453

I’m using these traces in eqcorrscan and it throws an error because of that funny sample rate. I’m also wondering if there will be a problem with station LA25 which has one more sample than a day-long file should.
Using trace.resample is not the way to fix this. Can I just read the trace, change trace.stats.npts and proceed? I’d rather fix the input file - we have local copies, are not fetching from remote services.
What is the best way to fix it?

2

I think for LA32 I would just try

trace.stats.sampling_rate = 100

and for station LA25 you can delete one sample if you need to have the same number of data points for all day files:

tr.data = tr.data[:-1]
3

Yep, changing stats.sampling_rate is what I decided to do. Since number of samples discrepancy only issues warnings, I’ve left it alone. But if I did change it as you suggest, what about the end time that is stored in stats? I suppose I should recalc it, just in case eqcorrscan cares about it.
But ultimately I’d like to repair the mseed files, because I’m not the only one who wants to use these.

4

The end time is not stored in the trace and is calculated on demand from start time, npts and sampling rate. Should be no problem.