Hi Christof and Lion,
Thanks for your responses! Sorry it took a while to get back to you.
I have uploaded the two miniseed files I used as examples to this folder - please let me know if you can’t access it!
One of the peculiarities of the issue I’m having is that the large miniseed file (spanning 2007-2017) downloaded from IRIS itself cannot be read by mseedinfo or mseedcut - it returns the same error. If I try to read it with mseedhdr (from PASSCAL) it gives the error “Non-Default Blocksize detected 1, 4096” and fails to read the file properly. The only think I can read it with successfully is obspy.
When I have read it with obspy, sliced it, then saved it as daily mSEED files, some of the resulting day-long mSEED can be read by GIPPTOOLS, some cannot. The two example mSEED files are consecutive days of data, but 2015-113 does work, while 2015-114 does not. All days following 2015-114 then don’t work for the Z component.
On further investigation, this corresponds to a change in the encoding method of the mSEED downloaded from IRIS - from STEIM1 to STEIM2. I think this is perhaps why the large mSEED files can’t be read by other programs - they contain data with mixed encodings. This change happens partway through the day on day 2015-113 for the Z component - the file I have uploaded only includes the first part of that day’s data so as to not mix encodings. For the E and N components the same is the case - all data from 2007 to around this date in 2015 is encoded as STEIM1 and the day-long mSEED files produced by slicing work. After the change to STEIM2 they don’t. However this is not generally a problem - we have other data in STEIM2 format that works fine with the GIPPTOOLS programs.
I wondered if the download may have been the issue, so re-downloaded a portion of the encoding change (so the large mSEED file did not have mixed encoding). This large mSEED file could be read successfully by all programs, but when sliced with obspy and written to day files the same issues returned - this indicates to me that the download was not part of the problem, but something about how this mSEED is written by obspy, and this clashing with the GIPPTOOLS programs. All the day files output by obspy can be read by mseedhdr, from the PASSCAL software suite, so perhaps this is an issue specific to the GIPPTOOLS programs. Either way you two seem best placed to answer this query - thanks for looking at it!
Cheers,
Tom