How do you translate SEG-Y seismic data descriptions without accidentally shifting a survey, confusing a reflection time with depth, or modifying thousands of traces? SEG-Y is an exchange format for seismic traces and the information needed to interpret them. Its textual header may look like an ordinary document, but its binary file header, trace headers, sample encodings and coordinate conventions are the parts that keep survey evidence coherent. Clear localization respects that distinction.
Searches for SEG-Y Rev 2.1 explained, 3200-byte textual header, 400-byte binary header, 240-byte trace header, sample interval, IBM versus IEEE floating-point samples, seismic inline crossline, coordinate scalars, extended textual headers and SEG-Y translation all point to the same issue: a field’s physical or computational meaning is more important than whether its label appears in English. A survey can be made readable internationally without changing the source geometry.
This educational longform guide helps geoscience translators, energy and offshore project teams, seismic processors, researchers, archivists and data engineers explain SEG-Y files accurately. It does not replace a technical implementation of the specification or the professional interpretation of subsurface geology. Read the revision actually used by a file, preserve an untouched copy, and validate concrete samples and coordinates instead of trusting a translated header in isolation.
A seismic file is an organized measurement record
An individual seismic trace is a series of amplitude samples associated with acquisition and positioning context. It does not by itself say what rock exists underground. Interpreters need sample timing, geometry, instrumentation, processing and coordinate information before they can connect many traces into an image or inference.
A translator who sees a display labelled horizon should not convert it into confirmed geological layer. The image may represent a picked seismic reflector, which requires interpretation and uncertainty.
Preserve the distinction between sampled measurements, processing outputs and geological claims. Explain the role of each term while keeping numeric traces and indexing relationships unchanged.
The familiar 3200-byte textual file header
SEG-Y traditionally begins with a 3200-byte textual file header. It can describe a survey, processing sequence, geometry conventions or other metadata. Even though parts may be human-readable, its prescribed location and size belong to the file format, so editing it as an unrestricted page of prose is unsafe.
A long translation may overflow the intended area or disturb following bytes. Replacing a technical field description with a vague word may also hide assumptions that processors need.
Extract and review the header text separately, record encoding and revision, and write it back using a conforming tool. Prefer a translated companion guide when the original header must remain stable.
The 400-byte binary file header
The binary file header follows the initial textual header and carries values relevant to the overall file, such as sample characteristics and format indicators. It is not a glossary. Its integers must be interpreted using the applicable revision and byte ordering.
Changing a byte while trying to replace an English word in the surrounding file can change a sample interval or format code and make the entire dataset appear different.
Compare the parsed binary-header values before and after any conversion. Confirm the sample format, revision information and trace-layout assumptions with dedicated SEG-Y software, not a text editor.
Each trace has its own header
Individual traces conventionally have a 240-byte trace header before the corresponding sample values, with extensions possible under later format revisions. These fields can describe trace-specific timing, location, acquisition relationships and sample details. The scope is different from the global binary file header.
A global sampling assumption may not hold for all unusual datasets. A trace-specific value can affect how one line of measurements is interpreted even if most other traces share the same configuration.
Validate representative traces at the beginning, middle and end of the file. Ensure that translated documentation describes header scope correctly and does not collapse per-trace fields into global claims.
Data samples follow the trace header
After a trace header, the file stores sample values in the representation declared by its metadata. Those values are not text, even if a binary viewer happens to show recognizable characters. The shape and order of samples matter to every later seismic display.
Suppose a translation tool interprets bytes as characters and normalizes them. A few changed bytes can produce extreme amplitudes or unreadable sections while leaving the English survey description intact.
Never run text conversion over the raw trace sample region. Read and write with appropriate format-aware libraries, then compare numerical samples or checksums where the intended operation is metadata-only.
Different revisions demand different assumptions
SEG-Y has evolved from early exchange practice to later revisions, including revision 2 and revision 2.1. Support for extended headers, additional encodings, metadata and conventions has changed over time. A tutorial should not treat every file as though it used all modern features or, conversely, forbid a legitimate later extension.
An old viewer may misinterpret a legitimate extension as data or may ignore a field needed to reconstruct survey layout. It could then present an apparently plausible but incorrect geometry.
Identify revision bytes and the producer’s documentation. Use the corresponding official specification and note software limitations in multilingual release materials.
Textual character encoding can vary
Historical SEG-Y textual headers are often associated with EBCDIC, while ASCII also appears in practice. A readable interpretation depends on the actual encoding. Guessing based solely on the file extension can turn letters into strange symbols or erase valid content.
An editor might receive a header where the first line appears as nonsense until decoded correctly. Translating those symbols as if they were technical jargon would produce a fabricated description.
Detect or confirm the header’s character encoding, preserve an original-byte copy, and test round-trip conversion. Clearly distinguish the encoding of the textual header from numeric sample byte order.
Binary byte order affects every number
The ordering of bytes in multi-byte numeric fields is essential. Reading a two-byte or four-byte integer with the wrong endianness can yield absurd values. SEG-Y revision details and producer conventions matter; real-world files are not uniformly perfect.
A claimed sample interval of several million microseconds might be a warning that byte order was misread rather than evidence of unusually slow data acquisition.
Compare values against physically plausible ranges and known survey documentation, while remembering that plausibility alone cannot prove correctness. Verify with actual format conventions and independent software.
Sample format codes are numeric contracts
SEG-Y supports defined sample representations, including historical IBM floating point and IEEE formats in relevant contexts. The sample-format code determines how raw bytes become numerical amplitudes. One cannot replace that code simply to satisfy a software reader without actually converting the values.
The same four bytes decoded under incompatible floating-point conventions may not represent the same number. A graph could be compressed, saturated or nonsensical after a false format declaration.
Document the actual stored format and the exact conversion if one occurs. For a translation-only workflow, preserve both the code and the samples without numerical transformation.
Sampling interval gives the time step
A seismic trace is usually indexed by a sample interval, which has an associated unit and defined field representation. That interval helps convert a sample index into time, though trace start and other processing context can also matter. A mismatch changes the apparent positions of seismic events.
For example, multiplying the interval by a thousand by misreading microseconds as milliseconds can make reflections appear far later than observed. That would distort every educational figure derived from the file.
Check the units and field definitions applicable to the revision. Reconstruct a few known sample times from index and interval and compare them to the source interpretation.
Sample count and trace length
A file may specify nominal or trace-specific sample counts depending on revision and characteristics. A reader needs this information to know where one trace ends and the next begins. A wrong count can desynchronize everything after the first affected trace.
If the software assumes 1000 samples where 1024 are actually present, bytes from the remaining samples may be mistaken for the next trace header. The resulting geometry can become meaningless.
Inspect trace lengths, fixed-length flags and revision-dependent definitions. Compare several trace boundaries and report any nonstandard producer behaviour rather than quietly smoothing it away.
Fixed-length traces help, but do not prove simplicity
A fixed-length trace flag can tell compatible readers that traces share certain layout properties. This may support more efficient indexing and random access. However, a file that violates its own declaration remains problematic, and an extension-aware layout may require additional interpretation.
Declaring all traces fixed merely to satisfy a convenient importer does not convert an irregular dataset into regular data. It can simply conceal the importer’s inability to read the original.
Check the flag against actual trace lengths and headers. If a repair is necessary, document it as a technical transformation with before-and-after validation, not a translation adjustment.
Extended textual headers add context
Later SEG-Y revisions allow extended textual headers. These can hold more information than the initial textual block, including structured metadata in relevant workflows. The location, count and terminators have defined meanings that readers use to find the trace data.
A translator who removes an apparently blank ending stanza can cause a parser to mistake a later header for trace samples. Conversely, a translated passage may need more space than a single fixed block permits.
Use the revision-specific method for reading and writing extended headers. Preserve terminators, declared block counts and any structured schema until verified by a compliant reader.
Revision 2.1 clarification matters
The SEG technical standards community issued guidance clarifying aspects of extended textual headers after the 2023 revision 2.1 publication. That is a reminder that even widely used standards require precise implementation details, particularly when optional structures vary across producers.
A project may discover that two software packages interpret the same optional header differently. Translation should not silently choose one interpretation and present it as certainty.
Refer to the official revision and subsequent clarifications, record which reader was used and retain ambiguous source metadata for specialist adjudication.
The 240-byte trace header is not an optional caption
Traditional trace headers occupy a defined 240-byte region and contain many fields with specific positions. The fact that a geophysicist might describe one field in English does not make its bytes free text. A trace header can govern geometry, offsets and timing used by downstream workflows.
A developer who renames a binary field in documentation is harmless if the file remains unchanged. A developer who rewrites the corresponding byte range to store the translated text can destroy the value.
Keep descriptions in code comments or external documentation and map them to their exact technical fields. Inspect raw bytes only with tools designed for the format.
Source and receiver geometry
Seismic surveys commonly involve sources that generate energy and receivers that record the response. Their positions, relationships and separation influence how traces are processed and interpreted. Geometry fields should not be translated into general geographical descriptions without respecting the survey coordinate model.
A source coordinate is not interchangeable with a receiver coordinate. If a bilingual export swaps them, offset calculations and common-midpoint grouping can become incorrect.
Preserve source/receiver roles, original coordinates and positional references. A clear public explanation can describe the difference while leaving numerical geometry untouched.
Coordinate scalars can multiply or divide
SEG-Y trace headers may use scalars that change how coordinate numbers should be interpreted. Depending on the scalar’s sign and the specification, the operation can involve multiplication or division. Treating the scalar as a mere label produces large spatial errors.
An integer coordinate paired with a negative scalar can imply a much smaller real-world quantity than the integer alone. A translated GIS note that ignores this may shift a shotpoint far outside the survey.
Decode coordinates using the applicable scalar rules. Test several known source and receiver points and compare the reconstructed geometry with trusted survey control.
Coordinate units and reference systems
Survey coordinates may be expressed in different units and reference frames. The word coordinate alone does not tell a reader whether the values are projected positions, geographic positions or some project-specific system. Translation is not allowed to invent a coordinate reference system.
A field engineer may hand over eastings and northings while the receiving team expects latitude and longitude. Substituting translated axis names cannot perform the mathematical transformation.
Preserve the stored numbers and declarations. If a coordinate conversion is explicitly required, carry out a documented geospatial operation with known datum, units and transform parameters.
Inline and crossline labels
Three-dimensional seismic interpretation often organizes traces by inline and crossline coordinates or indices. These can be used to build volumes and retrieve locations. Their precise semantics depend on the survey and processing arrangement; they are not universal synonyms for north and east.
An educational image that calls inline east-west without checking the acquisition orientation may be wrong. It can cause a reader to invert a volume when attempting to reproduce a section.
Use the source survey geometry to explain inline and crossline. Keep identifiers and trace indexing stable and validate at several intersection points.
CDP, CMP and processing vocabulary
Terms such as common depth point and common midpoint appear in seismic acquisition and processing literature. They carry specific historical and technical contexts. A translator should not treat them as interchangeable simply because both lead to grouped traces and stacked sections.
A document saying CMP gather refers to a particular processing grouping, not a finished geological map. Calling it a confirmed subsurface structure overstates the result.
Retain standard acronyms with explanatory glosses. Ask a geophysicist to review places where the source changes between acquisition, processing and interpretation.
Offset and sign conventions
Source–receiver offset can be stored or interpreted under conventions that matter for geometry, processing and polarity. A number without its sign and unit may mislead. Different processing stages may also use nominal and calculated offsets differently.
An offshore dataset might include signed offsets to distinguish orientation. Changing them all to positive values for a friendlier display discards information that processing tools may need.
Document the convention used in the file. Compare computed offsets from positions with stored fields and do not normalize signs as a language-editing shortcut.
Two-way travel time is not depth
Many seismic sections are shown in two-way travel time: the elapsed time for energy to travel into the Earth and return to receivers. Depth interpretation generally requires a velocity model and additional assumptions. A translation that calls a time axis depth converts a measurement presentation into a geological claim.
A reflection at 1.5 seconds is not universally 1.5 kilometres deep. Different velocities and paths change the relationship, and processing may include time shifts or migration.
Keep axes explicitly labelled with the correct physical quantity and units. If a depth conversion is included, identify the velocity model and its uncertainty.
Amplitude sign and polarity
Seismic amplitudes can carry sign and polarity conventions related to acquisition and processing. A plotted colour change or reversed trace can represent a display choice rather than a new geological boundary. The underlying numerical sign remains part of the stored sample.
A translated legend that reverses positive and negative amplitudes can teach the wrong relationship even if every trace sample remains untouched. A true numerical sign reversal is more serious.
Check the legend against known values and processing documentation. Preserve signal sign and clarify whether an illustration uses variable area, wiggle or colour display conventions.
Gains and normalization are processing steps
Automatic gain control, balancing and normalization can make seismic displays more readable. They also alter visual emphasis and may hide absolute amplitude differences. These are not language edits, and a translated educational guide should not imply that a processed section is identical to unprocessed measurements.
A bright reflector after gain adjustment may not represent an increase in recorded energy comparable across all traces. Calling it a stronger geological layer could therefore be misleading.
State when display or processing gain has been applied. Keep the relationship between raw data, processed data and interpretation explicit in captions and filenames.
Trace order and geometry sorting
Seismic traces may be ordered by acquisition, shot, ensemble, inline, crossline or another scheme. Reordering can be useful for analysis but must be coordinated with all headers and indexing information. A localization tool should not sort records merely to improve label order.
If the translated metadata table is alphabetized but trace data stay in the original order, a viewer might attribute one location’s amplitude to another survey point.
Preserve trace-level identity and test a round-trip using known trace identifiers. Treat any deliberate resampling or sorting as a documented data-processing operation.
Textual headers may describe uncertain conventions
Not all historical SEG-Y files document their geometry, encoding or processing consistently. Some contain local practices, nonstandard byte uses or incomplete descriptions. A translator’s task is to preserve uncertainty and make the absence of information visible.
A header might say approximately located or presumed coordinates. Rewriting it as verified positions would turn a tentative remark into an unjustified guarantee.
Translate qualifiers accurately and ask the data owner for clarification when needed. Record unresolved fields instead of inventing a standard interpretation.
Bilingual metadata should use an external mapping
The safest localization often leaves the binary file unchanged and supplies a translated data dictionary, readme, viewer help text or project report. That mapping can explain sample format code, coordinate scalar, receiver location and trace index without substituting prose for the on-disk values.
An international survey archive could publish side-by-side English and another language while retaining one canonical SEG-Y source. Researchers can then reproduce the same processing steps.
Make the mapping field-specific: original token, meaning, translated explanation, scope and reviewer. Prefer stable identifiers over translated labels as joins.
Versioned documentation and reproducible processing
A SEG-Y file has technical properties that are not completely described by a title alone. Release notes should include its revision, production software where known, major processing history, coordinate system assumptions and any nonstandard conventions that affect reading.
Two copies may have identical survey titles but different sample formats or processing levels. A translator who publishes only a friendly title risks making them appear equivalent.
Record file checksums and the exact source used. Link a translated guide to that version so readers can recover the underlying evidence.
Licensing and confidential subsurface information
Geophysical surveys can involve proprietary data, energy infrastructure, environmental investigations or restricted subsurface locations. The ability to parse a file does not imply permission to publish it, its coordinates or every textual field. Translation is subject to the same rights and confidentiality constraints as source material.
A public teaching example should use synthetic or appropriately licensed data. A company should not translate and expose sensitive source coordinates merely because it wants a multilingual training guide.
Check permissions, remove restricted details only through an authorized release workflow, and distinguish redaction from translation in the audit trail.
A hypothetical sampling example
Consider a trace with 2,000 samples and a 2-millisecond sampling interval. The interval means that successive sample positions are separated by 0.002 seconds. The sample-index span between its first and last sample is 1,999 intervals, not 2,000 intervals.
A translated caption saying 2,000 seconds of data because the trace contains 2,000 samples confuses count with duration. Calling the interval 2 microseconds would be a different error.
Calculate selected sample positions independently and compare plotted axis labels. State whether a displayed trace also has an initial time offset.
A hypothetical coordinate-scalar example
Suppose a legacy trace contains a large signed coordinate integer and a scalar that tells the reader to divide. Reading the integer as final metres can displace the survey by orders of magnitude. The exact numerical outcome depends on the stored value, scalar and unit convention.
A translated acquisition note that omits the scalar can be more harmful than no translation because it looks authoritative. Users may import incorrect positions into a GIS.
Decode three points using the actual field definitions and compare them against an independent survey map. Record the rule explicitly in the bilingual guide.
A hypothetical sample-format mismatch
Imagine a file whose header declares a floating-point encoding that the samples do not actually use. A parser may display enormous or tiny amplitudes, even when trace timing and coordinates are correct. The translation team should not conclude that the Earth produced abnormal signals.
Before offering an explanation, investigate file provenance, sample-format declarations and known software behaviour. Real-world datasets sometimes need technical repair unrelated to language.
Keep such repair separate from the localization workflow. Record the diagnosis and evidence for the change, then verify numeric values after a controlled conversion.
A hypothetical 3D volume misunderstanding
A team creates two orthogonal seismic sections from an inline and crossline grid and wants captions in several languages. A literal translation may describe them as north-south and east-west slices, but the survey coordinate grid may be rotated relative to geographic directions.
A student could then misunderstand the orientation of a structural feature. The problem arises not in the amplitudes but in the written interpretation of the axes.
Describe inline and crossline as survey-grid directions unless their geographic bearings are verified. Use a small orientation diagram and stable intersection identifiers.
A hypothetical two-way-time conversion
A reflection appears at 1.2 seconds two-way time in a synthetic training section. A learner wants to assign a depth. Without a suitable velocity model, the number does not uniquely define depth. Assuming a velocity may produce an illustrative estimate, not a measured rock interface.
A translator must not turn that illustrative estimate into a certain depth in the published caption. Even a perfectly fluent explanation can misrepresent the method.
Keep measured time, assumed velocity and calculated depth as separate quantities with units and uncertainty. Record the basis of any transformation.
A safe translation workflow
Begin with an untouched SEG-Y file and preserve its checksum. Inventory revision, encoding, textual and binary headers, extensions, trace count, sample format, time interval, sample count and representative trace coordinates. Classify candidate texts as fixed tokens, permitted descriptions, private metadata or unresolved technical content.
Translate human-facing descriptions in a controlled sidecar document or through a compliant serializer if native edits are required. Use glossary terms consistently and preserve uncertain statements instead of smoothing them away.
Reopen with an independent reader and compare trace values, positioning, time bases, header counts and file layout. Any authorized numerical transformation belongs in a separately approved change record.
Why a successful file open is not enough
Software may accept a SEG-Y file while silently guessing byte order, sample format, coordinates or trace ordering. The result can still look like plausible seismic data because geological reflections have broad patterns. This is why an independent numerical and geometric reference is necessary.
Inspect representative traces, including edge cases and files with extensions. Compare known source locations and a set of amplitudes after export. Confirm the physical units shown on every axis.
Combine automated field tests with an expert’s interpretation check. Structural validity, visual plausibility and correct subsurface meaning are three different levels of confidence.
What readers should take away
SEG-Y is a transport structure for seismic evidence, not a self-interpreting map of the Earth. Its header bytes, trace positions, sampling conventions and numeric values must remain coherent. A good translation makes those rules understandable without silently substituting another geometry or processing history.
Use accessible language and concrete examples. Be explicit about source versus receiver positions, measured time versus depth, raw versus processed amplitudes and metadata versus sample bytes.
Maintain a verifiable connection to the original survey. The purpose of an international description is shared understanding, not an attractive replacement for technical precision.
How to read an unfamiliar vendor file responsibly
When the provider is unknown or a dataset is decades old, start by recording the exact bytes rather than choosing an interpretation immediately. Try the expected revision, sample encoding, header fields and byte order with a tool that reports assumptions. If readings conflict, document alternatives and ask for survey documentation.
Use plausibility checks cautiously. A realistic coordinate is not proof of a correct datum, and realistic-looking seismic wiggles are not proof of a correct sample encoding. Multiple independent facts should converge before a translation makes a definitive claim.
Preserve the original and the parsing report, including warnings. For students, showing why uncertainty remains is more educational than printing a confident but unverified map.
Distinguish technical corrections from editorial corrections
A misspelled word in a textual header, a missing coordinate reference and a wrong sample format are different problems. Fixing spelling may be an editorial change. Reconstructing coordinates or converting sample bytes is a scientific-data intervention that requires controlled procedures.
A translator may identify an inconsistency without possessing authority to change the source. They should raise it with the data custodian and provide the relevant byte positions and competing interpretations.
Publish the translated wording only after the owner clarifies the interpretation or marks uncertainty. Keep an explicit change log so later analysts can distinguish language edits from repairs to evidence.
A reviewer checklist for the first and last traces
Many conversion errors occur at boundaries. The first trace may follow optional extended headers, while the last trace may be followed by additional trailer material in some revisions. A parser that assumes a simpler layout could treat one region as another.
Inspect the first trace header offset and confirm that the declared sample count reaches the expected next boundary. At the end, check whether the final sample is followed by legitimate trailer content rather than stray corrupted bytes.
Document the revision-specific calculation and compare with a second tool. This simple practice often detects mistakes that remain hidden when only a middle-of-file section is visualized.
How to teach seismic metadata to non-specialists
Start with a thought experiment: the survey is a collection of measurements made at known source and receiver positions, sampled at known times. Then explain that the textual header is a note, the binary file header describes global properties, and trace headers link individual measurements to geometry.
A learner can translate the note while leaving the measurement positions and amplitude bytes unchanged. This analogy makes an important distinction without requiring advanced geophysics.
Use a small synthetic example to teach the difference between sample index, travel time, source coordinate, receiver coordinate and a later geological interpretation.
A bilingual handoff that another team can audit
A defensible international release should contain the original filename and checksum, format revision, metadata glossary, authoritative coordinate definition, any allowed text changes, parser version and validation outcomes. It should also identify who reviewed technical meaning and any remaining unresolved conventions.
A geoscientist receiving the package should be able to reproduce a sample time, a source-receiver offset and a selected trace amplitude without consulting the translator. That is a practical test of whether meaning survived.
If two tools disagree, report the disagreement rather than silently choosing the cleaner image. Shared uncertainty is better than false interoperability.
Frequently asked questions
Can I translate the 3200-byte header? Translate a separate display or use a compliant revision-specific editor for permitted text; do not shift byte positions. Can I change IBM floating point to IEEE by changing a label? No. That requires a genuine numerical conversion and validation. Are seismic travel times depths? Not without a velocity model. Does SEG-Y guarantee a coordinate reference system is unambiguous? No; the producer’s metadata and conventions still matter.
Does a valid SEG-Y file prove a geological interpretation? No. It packages traces and context; interpretation requires assumptions and evidence. Is revision 2.1 identical to older files? No, revisions have different features and permitted structures. Should a translation revise trace order or coordinates? Not unless a separately authorized technical transformation is documented and checked.
Authoritative sources
Society of Exploration Geophysicists SEG-Y overview and revision history: https://wiki.seg.org/wiki/SEG-Y
SEG Technical Standards and specifications: https://seg.org/resources/technical-standards/
Reader-oriented SEG-Y file structure: https://cigsegy.readthedocs.io/en/stable/aboutsegy.html