SEG-Y for Seismic AI: Sample Encoding, Trace Length and Time Axes

A SEG-Y offer needs more than an extension and a volume

A seismic-AI input may be an original exchange file, extracted traces or a transformed model array. The recipient must know which stage is being supplied. A proposed conversion can change sample representation and grid; retaining the original file's name does not describe those changes.

The named basis here is SEG's January 2017 revision 2.0 document. Its binary header identifies the sample format, while its trace structure distinguishes samples from headers and optional extensions. This is a reading of an explicit edition, not a claim that every .sgy file uses one fixed layout. SEG's current index also lists revision 2.1 and a later clarification. [S1,S2]

For a proposed dataset, resolve the actual producer's revision and extensions with the intended reader. Then compare what the offered output preserves. A recognized extension and plausible file size do not prove that a model will receive the intended values or axes.

References: [S1][S2]

Four bytes do not identify the numeric format

Revision 2.0's format code 1 identifies four-byte IBM floating point; code 5 identifies four-byte IEEE floating point. Appendix E gives different exponent and fraction interpretations. Equal word length therefore does not establish equal decoded values. Byte order is another field to establish; it is not selected by the storage device or the receiving workstation. [S1]

Original example SG-34 stipulates the ordered bytes 41 10 00 00. Interpreted as a big-endian IEEE binary32 word, they represent 9.0. In the document's IBM hexadecimal format, the positive word has exponent 65 with bias 64 and fraction 0x100000/0x1000000 = 1/16. Its decoded value is (1/16) × 16^(65−64) = 1.0. The same four bytes thus produce two different numbers.

This is a constructed bit-pattern comparison, not a conversion of an actual survey. The numbers are decoded sample values before any applicable weighting or unit interpretation. A successful four-byte read does not establish the right numeric interpretation, and changing a label is not a validated dataset conversion.

References: [S1]

SG-34: two traces reach four seconds on different grids

Now stipulate two time-domain traces in a revision 2.0 byte-stream file. Both begin at relative time 0, with no start-time adjustment in this example. Trace A contains 2001 samples at 2000 µs, or 0.002 s, between adjacent samples. Trace B contains 1001 samples at 4000 µs, or 0.004 s. Their fixed-length flag is 0, and their applicable per-trace counts and intervals are supplied consistently. No extended count or interval override is present.

For zero-based sample index i, the stipulated sample time is i × interval. Trace A's last index is 2000, so its last sample lies at 2000 × 0.002 = 4 s. Trace B's last index is 1000 and also lies at 1000 × 0.004 = 4 s. There are 2000 and 1000 intervals respectively, not 2001 and 1001 intervals.

The two traces have the same first-to-last time span but different value populations. At index 500, A represents 1 s and B represents 2 s. Stacking the two rows by index without reconciling their grids would align different times. The four-second description does not resolve a model's uniform-shape or temporal-alignment requirement. No resampling, padding, filtering or model-input procedure is prescribed.

The trace-length policy changes the byte account

Revision 2.0 permits varying traces when the fixed-length condition is not asserted; the applicable trace headers then matter. A binary-header summary of the primary population does not automatically describe every trace. Its time-data interval fields use microseconds; the document assigns other meanings for frequency- or depth-domain data. The time-grid example cannot be transferred to those domains merely by retaining the same numbers. [S1]

For SG-34, additionally stipulate format 5, no tape label or encapsulation, no extended textual headers, one 240-byte standard header per trace, no trace-header extensions and no trailer. The file begins with the 3200-byte textual and 400-byte binary headers. These exclusions are part of the example, not a generic SEG-Y file-size rule.

A's sample array uses 2001 × 4 = 8004 bytes; adding its 240-byte header gives 8244 bytes. B uses 1001 × 4 = 4004 sample bytes and 4244 bytes with its header. Together with the 3600 initial bytes, the file account is 3600 + 8244 + 4244 = 16088 bytes. The sample arrays alone total 12008 bytes.

Assuming both traces have A's record length instead would predict 3600 + 2 × 8244 = 20088 bytes, 4000 bytes more. That discrepancy would follow from the false uniform-record assumption; it is not evidence that SG-34 is truncated. The example does not generalize its offsets to a file with the optional structures excluded above.

References: [S1]

A model-ready array is a separately specified output

Suppose one offer supplies SG-34's original variable-length traces, while another supplies a rectangular array. The second offer needs to say how its values and time grid relate to A and B. Equal first-to-last spans do not determine the destination sample count or the value assigned at an intermediate time.

Likewise, an offer that converts IBM-coded samples to IEEE representation changes the numeric encoding while aiming to preserve decoded values. It should not preserve a contradictory original format declaration. The four-byte size can remain unchanged through that conversion, so byte count alone cannot demonstrate whether it happened or whether its result is correct.

These are two separate transformations: numeric representation and the sampling grid. A proposal can resolve one while leaving the other open. Compare an agreed representative output against the required interpretation at the consuming boundary, rather than accepting model-ready as a self-contained specification. SG-34 establishes neither a conversion implementation nor a measured reader/model result.

Decoded samples still need their scientific meaning

Knowing the encoding, count and interval does not identify a trace's complete physical meaning. Actual units, weighting, location, processing history and applicability to the intended scientific task remain separate. The 1.0-versus 9.0 example deliberately stops before a physical amplitude interpretation, and the 4 s example supplies no seismic velocity or depth conversion.

The NetCDF packed-values guide covers a different transformation: separating stored missing codes from scaled quantities. The DICOM geometry guide concerns mapping image indices into patient coordinates. Neither supplies this file's trace framing or encoding. Keep those established owners as references for their own decisions rather than treating every scientific input as the same array problem.

Assess the input contract before sizing the platform

The useful buying return is a supported statement of what the recipient receives: declared exchange format and numeric representation, actual trace populations and applicable axes, and any defined transformation into the model's required input. In SG-34, two four-second traces are 3002 values, not two equal-length 2001-value rows. Its 16088-byte file is not its destination tensor allocation or the amount transferred during training.

If the selected GPU platform needs physical installation, use the existing rack-and-stack scope for mounting, agreed IT cabling, labels and physical handoff. Seismic interpretation, data conversion and application acceptance remain with the appointed specialist teams. No survey operation, geoscience software service, dataset diagnosis, infrastructure fit or throughput result is offered by this explanation.

References: [L1]