Seismatters

As is usually the case, soon after I published the first draft of SaneSeis, I realised I was missing things, and that with a few additions could make it better.
The biggest change in this updated version is the addition of a Receiver Table after the Source Table.
I was very reluctant to add another variable length block, but the advantages outweigh the drawbacks. And in any case each entry within a table is fixed length, and the number of entries are defined in the file header, so, unlike SEGD it is very easy to calculate memory requirements and start of data.

The latest updates can be seen here: http://seismatters.com/SaneSeis.html

Other notable additions

• Record type. Currently based on Sercel’s 428 definitions, there is plenty of room to add more
• Recorder position. This seems to have been forgotten these days, but is still good information to have. SaneSeis records the Low Line/Point of where the recorder connects to the spread.
• Source position mode in the source table. We need to know if the source position is the true position from the source navigation system or preplanned or something else.
• Limits have been removed from the trace header – they are now in the Receiver table. This saves 20 bytes per trace header which on a big survey can add up to a useful saving. Resistance/Tilt/Capacitance errors are now indicated by 255=low, 0=in range, 1=High

So far very little feedback. PS has suggested that I incorporate EPSG codes. I am looking at this, but I do want to keep everything metric, so will not support feet, yards, miles etc. It is only the US that still uses these and it is about time they moved into at least the 18th century. SaneSeis coordinates must also remain Cartesian, so not all EPSG codes would be valid.
Comments and suggestions welcome.
http://seismatters.com/cgi-bin/feedback.cgi

I have been quite critical of the SEG file formats over the years. And with good reason. SEGD, SEGY and SEG2 should have been retired years ago. They are based on decades old ideas that perhaps suited the equipment at the time. Unfortunately, the SEG does not seem to have realised that time has moved on – recording systems, methods and requirements have changed (for the SEG – actually they changed a long time ago!). When SEGD and SEGY were first released, they arguably were suitable for use at the time. No Longer. And SEG2 of course should never have been released at all, but that is another story for another time.

 
The problem is that SEGY and SEGD were ‘extended’ by the SEG instead of replaced. I can maybe understand the first revision SEGD V1 to V2 for example, but now we have an abortion called SEGD V3. There is absolutely no excuse for its existence. Unfortunately there are people starting to use it (I don’t know why) and people who plan to use it (again, I don’t know why).

 
Some years ago, I proposed in a very basic way what a modern seismic acquisition file format should look like (IMNSHO). It was based around flat headers and no optional sections. So, instead of just complaining about SEGD V3, I have sat down and actually defined an alternative based on discussions and thoughts I have had. I will not claim it is perfect or even ready for use just yet, but it does solve the problems with SEGD V3 and does match the requirements of high production, high channel count multiple source recording. It does borrow a little from the existing formats, but only the good parts.

 
For anyone interested, see here, I call it SaneSeis: http://seismatters.com/SaneSeis.html
I will welcome constructive criticism, and distribution of the ideas.