SEG-D Rev3 0 Format Jun2012

SEG-D, Rev 3.
0
SEG Field Tape Standards
June, 2012
Table of Contents
1.0 INTRODUCTION................................................................................................. 5
1.1 CONTROLLING ORGANIZATION................................................................................. 6
2.0 CHANGES INTRODUCED IN REVISION 3.0 ................................................... 7
2.1 CHANGES INTRODUCED IN REVISION 2.1................................................................ 10
2.2 CHANGES INTRODUCED IN REV 2.0 ........................................................................ 11
2.3 CHANGES INTRODUCED IN REV 1 ........................................................................... 13
3.0 FORMAT OVERVIEW ........................................................................................... 17
3.1 SEG-D TIMESTAMP ........................................................................................... 25
3.2 MULTI-COMPONENT DATA ................................................................................ 28
3.3 EXTENDED RECORDING MODE .......................................................................... 28
3.4 PERMANENT RECORDING SYSTEMS ................................................................... 28
3.5 TIME DRIFT ........................................................................................................ 29
3.6 POSITIONS IN SEG-D ......................................................................................... 29
4.0 SEG-D, REV 3.0 STRUCTURE .............................................................................. 31
4.1 REV 3.0 STORAGE UNIT LABEL (TAPE LABEL) ................................................. 31
4.2 REV 3.0 TABLE OF CONTENTS (TOC) FILE (OPTIONAL) ................................... 33
4.2.1 TOC Header .................................................................................................. 34
4.2.2 TOC Record Entry ........................................................................................ 36
4.2.3 Using the TOC with SEG-D on disk ............................................................. 37
5.0 HEADER BLOCKS .................................................................................................. 39
5.1 GENERAL HEADERS (GENERAL HEADER BLOCK #1, #2 AND #3 ARE REQUIRED) .. 39
5.2 SCAN TYPE HEADERS ............................................................................................. 41
5.3 DEMUX TRACE HEADER (REQUIRED) ..................................................................... 42
5.4 EXTENDED HEADER (OPTIONAL) ............................................................................ 44
5.5 EXTERNAL HEADER (OPTIONAL) ............................................................................ 44
5.6 GENERAL TRAILER (OPTIONAL) .............................................................................. 44
5.6.1 Edit (SEG-D Trace Edit v1.0) ....................................................................... 44
5.6.2 Navigation data backup ................................................................................. 47
5.6.3 Text Comment............................................................................................... 47
5.6.4 Observer log .................................................................................................. 48
5.6.5 User defined .................................................................................................. 48
6.0 DATA BODY ............................................................................................................. 49
6.1 DATA RECORDING METHOD ................................................................................... 49
6.2 DSM FACTOR CALCULATION AND PHYSICAL UNIT ................................................ 54
6.3 SENSOR CALIBRATION............................................................................................. 56
7.0 HEADER TABLES ............................................................................................. 58
7.1 GENERAL HEADER BLOCK #1 .................................................................... 58
7.3 GENERAL HEADER BLOCK #3 (TIMESTAMP AND SIZE HEADER) ............... 60
7.4 GENERAL HEADER BLOCK #4 (VESSEL/CREW IDENTIFICATION) (OPTIONAL) 60
7.5 GENERAL HEADER BLOCK #5 (SURVEY AREA NAME) (OPTIONAL) .......... 61
7.6 GENERAL HEADER BLOCK #6 (CLIENT IDENTIFICATION) (OPTIONAL) ..... 62
7.7 GENERAL HEADER BLOCK #7 (JOB IDENTIFICATION) (OPTIONAL) ............ 63
7.8 GENERAL HEADER BLOCK #8 (LINE IDENTIFICATION) (OPTIONAL) .......... 64
ii
7.9 SOURCE DESCRIPTION BLOCK (OPTIONAL) .............................................. 64
7.9.1 VIBRATOR .................................................................................................. 65
7.9.2 EXPLOSIVE ................................................................................................. 65
7.9.3 AIRGUN ....................................................................................................... 66
7.9.4 WATERGUN ................................................................................................ 67
7.9.5 ELECTROMAGNETIC SOURCE ............................................................... 68
7.9.6 OTHER SOURCE ......................................................................................... 69
7.10 ADDITIONAL SOURCE INFO (OPTIONAL) ................................................... 69
7.11 SOURCE AUXILIARY CHANNEL REFERENCE (OPTIONAL) .................... 70
7.12 COORDINATE REFERENCE SYSTEM IDENTIFICATION (CONDITIONAL)72
7.13 POSITION BLOCKS (OPTIONAL) .................................................................... 72
7.14 RELATIVE POSITION BLOCK (OPTIONAL) .................................................. 75
7.15 SCAN TYPE HEADER (CHANNEL SET DESCRIPTOR) .................................... 75
7.16 DEMUX TRACE HEADER ............................................................................. 79
7.17 TRACE HEADER EXTENSION #1................................................................. 80
7.18 SENSOR INFO HEADER EXTENSION (OPTIONAL) ..................................... 80
7.19 TIMESTAMP HEADER (OPTIONAL) ............................................................... 81
7.20 SENSOR CALIBRATION HEADER (OPTIONAL) ........................................... 82
7.21 TIME DRIFT HEADER (OPTIONAL) ................................................................ 83
7.22 ORIENTATION HEADER (OPTIONAL) ........................................................... 83
7.23 MEASUREMENT BLOCK (OPTIONAL) .......................................................... 84
7.24 ELECTROMAGNETIC SRC/RECV DESC BLOCK (OPTIONAL) .................. 85
7.25 GENERAL TRAILER DESCRIPTION BLOCK (OPTIONAL) ......................... 86
8.0 HEADER BLOCK PARAMETERS ................................................................. 87
8.1 GENERAL HEADER, BLOCK #1 ................................................................... 87
8.3 GENERAL HEADER BLOCK #3 (TIMESTAMP AND SIZE HEADER) ............... 91
8.4 GENERAL HEADER BLOCK #4 (VESSEL/CREW IDENTIFICATION) (OPTIONAL) 92
8.5 GENERAL HEADER BLOCK #5 (SURVEY AREA NAME) (OPTIONAL) .......... 92
8.6 GENERAL HEADER BLOCK #6 (CLIENT IDENTIFICATION) (OPTIONAL) ..... 93
8.7 GENERAL HEADER BLOCK #7 (JOB IDENTIFICATION) (OPTIONAL) ............ 93
8.8 GENERAL HEADER BLOCK #8 (LINE IDENTIFICATION) (OPTIONAL) .......... 93
8.9 SOURCE DESCRIPTION BLOCK (OPTIONAL) ............................................. 94
8.9.1 VIBRATOR .................................................................................................. 94
8.9.2 EXPLOSIVE ................................................................................................. 96
8.9.3 AIRGUNs...................................................................................................... 98
8.9.4 WATERGUN .............................................................................................. 100
8.9.5 ELECTROMAGNETIC.............................................................................. 101
8.9.6 OTHER SOURCE....................................................................................... 103
8.10 ADDITIONAL SOURCE INFO (OPTIONAL) ................................................. 105
8.11 SOURCE AUXILIARY CHANNEL REFERENCE (OPTIONAL)................... 105
8.12 COORDINATE REFERENCE SYSTEM IDENTIFICATION (CONDITIONAL)107
8.13 POSITION BLOCKS (OPTIONAL) .................................................................. 107
8.14 RELATIVE POSITION BLOCK (OPTIONAL) ................................................ 110
8.15 SCAN TYPE HEADER (CHANNEL SET DESCRIPTOR) .................................... 111
8.16 CHANNEL SET DESCRIPTOR .................................................................... 111
8.17 DEMUX TRACE HEADER ........................................................................... 115
8.18 TRACE HEADER EXTENSION #1............................................................... 116
8.19 SENSOR INFO HEADER EXTENSION (OPTIONAL) ................................... 118
8.20 TIMESTAMP HEADER (OPTIONAL) ............................................................. 118
8.21 SENSOR CALIBRATION HEADER (OPTIONAL) ......................................... 119
iii
8.22 TIME DRIFT HEADER (OPTIONAL) .............................................................. 120
8.23 ORIENTATION HEADER (OPTIONAL) ......................................................... 120
8.24 MEASUREMENT BLOCK (OPTIONAL) ........................................................ 123
8.25 ELECTROMAGNETIC SRC/RECV DESC BLOCK (OPTIONAL) ................ 124
8.26 GENERAL TRAILER (OPTIONAL) ................................................................ 125
8.26.1 GENERAL TRAILER DESCRIPTION BLOCK (optional) ...................... 125
APPENDIX A: MANUFACTURERS OF SEISMIC FIELD RECORDERS ......... 127
APPENDIX B: GLOSSARY ........................................................................................ 131
APPENDIX C: API PRODUCER ORGANIZATION CODE.................................. 133
APPENDIX D: COORDINATE REFERENCE SYSTEM IDENTIFICATION .... 137
D.1 LOCATION DATA .................................................................................................. 137
D.1.1 Location Data stanza ...................................................................................... 138
D.1.2 Example Stanzas for Location Data ............................................................... 145
D.1.3 Location Data Coordinate Transformation stanzas ........................................ 150
D.1.4 Example Stanzas for Location Data Transformation ..................................... 157
APPENDIX E: EXAMPLES AND CALCULATIONS ............................................. 159
E.1 SAMPLES PER SCAN TYPE...................................................................................... 159
E.2 SKEW FIELDS PER SCAN TYPE ............................................................................... 159
E.3 FILTER SLOPE CALCULATION ................................................................................ 160
E.4 SEG-D FILE STORAGE ON NON-TAPE MEDIA ........................................................ 160
E.5 SEG-D RECORD INDEX INTERPRETATION FOR MARINE, LAND, SEABED, TRANSITION-ZONE, AND VSP SURVEYS
.................................................................................................................................... 161
E.6 TRACE EDIT EXAMPLE .......................................................................................... 164
E.7 SOURCE INFORMATION IN GENERAL HEADER OR TRACE HEADER ...................... 165
E.8 EXTENDED RECORDING MODE EXAMPLE ............................................................ 167
E.9 SEG-D TIMESTAMP CALCULATION ...................................................................... 168
E.10 ELECTROMAGNETIC (EM) SURVEY ................................................................... 174
E.11 EXTENDED RECORDING MODE 2 ....................................................................... 177
APPENDIX F: ENERGISTICS UNIT OF MEASURE INTEGER CODES .......... 181
iv
1.0 Introduction
For several years now there has been talk of the need for a new revision of the SEG-D standard for seismic field data. The
last major revision of the standard, Rev 2.0, was published in 1996 with an incremental update Rev 2.1 in 2006. This new
Revision 3.0 recognizes the significant developments in acquisition and computer technologies and brings the standard
into line with current, and many envisioned future, industry techniques and practices. It also resolves longstanding
ambiguities and corrects both typographic and factual errors that have been reported against the existing SEG-D
standards. (It does not, we admit, contain the prescription for RODE encapsulation promised in the Rev 2.0 introduction.
It has been decided to keep the mapping of seismic data to RODE separate from the SEG-D format.) While not fully
100% backwards compatible to prior revisions, the only significant changes required to existing software that creates
SEG-D output is the generation of a third General Header block, and updating the channelset descriptors to 96 bytes. Most
other additions are optional.
Among the major upgrades that can be encoded in new header and trailer blocks are microsecond accurate timestamps,
detailed source and sensor (multicomponent included) description, extended recording modes that allow for nearly 9 years
of continuous recording by permanent emplacements, electromagnetic survey support, post-acquisition edits, coordinate
reference system datum and projection, microsecond sample rates, and negative start times.
At the SEG convention in Houston in 2005, the SEG Technical Standards Committee decided to revive the SEG-D
Format Subcommittee, with Stewart A. Levin of Halliburton Energy Services, whose passions include maintenance and
improvement of SEG-D input software packages, volunteering to chair the subcommittee and provide the necessary
energy to drive it forward. Since then there has been considerable activity to ascertain what should be contained in the
new revision, with email discussion lists, subcommittee activities, progress reports in The Leading Edge and First Break,
and meetings of interested parties at the EAGE and SEG annual meetings. This updated standard explicitly incorporates
items and codes from the industry standards groups such as Energistics and the International Association of Oil and Gas
Producers (OGP).
The following individuals have been active participants in this effort:
Jill Lewis Troika International Technical Standards Chair

Stewart A. Levin Halliburton SEG-D Subcommittee Chair
Rune Hagelund Roxar Technical Standards Vice Chair
Barry D. Barrs ExxonMobil
Roger Lott Consultant
Tore Nilsen Schlumberger WesternGeco
Francois Daube Schlumberger WesternGeco
Paul Maton Sillimanite Consultants
Nils Aatland Fugro Seismic Imaging
Jacques Hamon Sercel
Angus Stott Petroleum Geo-Services
Peter Green Saudi Aramco
Joseph Cignoli Saudi Aramco
Bob Firth Troika International
Numerous other people have also participated at various times.
SEG-D Rev 3.0 5 June 2012

1.1 Controlling Organization
The SEG-D rev 3.0 is administered by the SEG Technical Standards Committee. Any questions, corrections or
problems encountered in the format should be addressed to:
Society of Exploration Geophysicists

P.O. Box 702740
Tulsa, Ok 74170-2740
Attention: SEG Technical Standards Committee

Phone: (918) 497-5500
Fax: (918) 497-5557
Internet site: www.seg.org

2.0 Changes Introduced in Revision 3.0
Revision 3.0 introduces format changes to better handle the requirements from modern seismic acquisition and processing
systems. Revision 3.0 attempts to be an improved format for information exchange between the data acquisition and
processing system by including important metadata like equipment positions and trace edits.
The following list is a summary of the specific changes made in Revision 3.0 compared to 2.1:
1. Revision number changed from 2.1 to 3.0, see

a. Chapter 4,1 (Storage Unit Label, field number 2), and
b. Chapter 8.2 (General Header #2, byte 11 and 12).
2. The following headers are left mostly unchanged to allow e.g. pattern matching, i.e. searching for recognizable
patterns in a stream of data. The minor changes are:
a. Tape Label (updated the SEG-D version number),
b. General Header #1 (allow FF16 as value of byte 23, to support different base scan intervals), and
c. Demux Trace Header (allow FFFF16 as value in bytes 5 and 6, to support extended trace number).
3. Rev 3.0 no longer requires a channel set to be present, making it possible to store a SEG-D record without any
data. This supports creating a SEG-D record with only header data, e.g. only External, Extended, and/or General
Trailer, which is useful for transferring metadata between systems.
4. Rev. 3.0 allows traces of zero length (no samples). This is done by setting start and end time to the same value,
and setting number of samples to 0 (Byte 13–16 of Channel Set Descriptor). This supports transfer of Trace
Header meta data between systems without any data attached.
5. Rev 3.0 is still a shot domain format; however a separate mode, Extended Recording Mode, has been added to
partially support non-shot domain data.
6. A high-resolution timestamp is introduced to accurately determine the time in SEG-D. The time of first sample in
record is entered in General Header #3 (Bytes 1–8). Position measurements, orientation measurements, source
events, etc. all have a timestamp attached, which allows multiple measurements of the same type to be stored
within the same record and trace header. This gives the manufacturer a much more fine grained control over, for
example, the movement of equipment during the record, and allows the use of modern, more powerful filtering
techniques to be applied to the data traces.
7. A SEG-D positioning format has been defined, and Position blocks may be inserted into Trace Headers. The
datum and projection information is inserted as part of the General Header. A single SEG-D record should only
contain one datum/projection, though a second geographic coordinate system (with same datum) may also be
used. Multiple datums/projections may exist for a given storage unit (tape), however it is recommended to not
vary the coordinate system definitions as this increases the likelihood of errors in usage of the data.
8. Rev 3.0 has an extended indexing structure, allowing more advanced logical addressing of traces, and better
grouping of information. The following indexes are supported for sources and receivers: Line, Point, Point Index,
Depth, Group and Re-shoot index.
9. An orientation header has been defined to properly support multi-component data. The format supports rotation to
a global reference system as part of acquisition, or to be applied later in processing. The rotation specified in the
orientation header may or may not be applied as part of acquisition. The Trace type and Line, Point and Group
indexes are used to determine which traces should be rotated together.

10. Rev 3.0 supports an increased range of sampling intervals, record lengths, number of channels, filter resolution,
etc. compared to Rev 2.x, to be able to handle the requirements of modern acquisition systems. In addition
negative times for start of trace are now supported.
11. The size of header, data, record etc. are now explicitly stated in General Header to facilitate quick data access and
facilitate error recovery.
12. All header blocks have an enumerated type attached (byte 32 of all blocks), both to increase flexibility of the
format to and simplify decoding. This also allows all information to be optional, simplifies error recovery and
increases the robustness of the format. In addition, it allows information to be inserted in the header and order
deemed most useful by the recorder.
13. The Channel Set Header has been extended to 96 bytes to support extended sampling intervals, trace lengths, etc.
All values are now explicitly stated, no complex calculation is required to determine, e.g., sampling interval or
descale multiplier. In addition derived values, such as the number of samples per channel, are also explicitly
stated to avoid ambiguities of prior versions of the SEG-D standard. A recorder-defined textual description has
been added to the channel set descriptor to increase the flexibility of the storage format and increase the efficiency
of information transfer between acquisition and processing.
14. The number of channels per channel set has been extended to 16,777,215.
15. General Header blocks for common acquisition information like Client, Job, Survey Area, Vessel/Crew and Line
information have been defined. The information in these General Header blocks is intended to be a short, textual
description of the specific item, not a complete, detailed description. To give a complete definition of the survey
area, or store the complete client contract, the External or Extended header may be used. The General Header
blocks #4–8 are basically defined to simplify data management and information identification.
16. The size of all recorder-defined headers (Extended, External and General Trailer) has been increased. The
maximum size of an External/Extended header is now 512 MB and a General Trailer may contain up to 128 GB.
17. The maximum Trace Header size has been increased to 8180 bytes to allow multiple positions or other
measurements to be inserted in each trace. The space may also be used by the recorder to store an increased
amount of recorder-defined blocks.
18. The source information is far more comprehensive than in Rev 2.x. A different General Header block type exists
to describe each source type (Vibrator, Airgun, etc.), replacing the General Header Block N of Rev 2.x. The
information contained in the source description blocks basically aligns the information in SEG-D with SPS.
19. An additional source information block has been defined to allow specification of the actual firing time of the
source (with microsecond accuracy), and the status of the source.
20. Compound sources can be created, i.e. sources containing other sources, allowing SEG-D to store information
about, e.g., single airguns and the combined source or single vibrator trucks and the combined vibrator group.
21. Auxiliary trace reference blocks may be attached to the source information, listing which auxiliary traces contain
relevant information for the specified source.
22. The source information may be inserted into the General Header or Trace Header depending on what is most
useful. For records with multiple source events (like slip-sweep acquisition), storing the source information in the
source related auxiliary traces (e.g. source reference signal), is recommended.
23. Allow recording data in 64 bit IEEE

Additional Valid Format Code for bytes 3 & 4 of the General Header #1 is:
8080 64 bit IEEE float demultiplexed
24. To support acquisition systems where sensors are deployed for longer periods of time without external clock
synchronization, a special Time drift header block have been added. This allows storing information about
drifting clocks (for quality control and more advanced clock corrections post acquisition). It must be noted that
even though SEGD supports logging of the information, SEGD does not support storing data from multiple
drifting time reference systems. Traces must be clock drift corrected prior to record creation if data from multiple
sensors are stored in one record.
25. Support for Electromagnetic surveys has been added, including Electromagnetic source description and
Electromagnetic receiver description.
26. Sensor calibration information may now be added. SEGD supports an individual scaling factor, as part of the
sensor sensitivity value, and a more complex calibration function in frequency or time domain. The function can
either be specified as part of the trace header (frequency domain), or as a separate calibration “trace” (time
domain).
27. A set of standard measurements may now be added to a special Measurement header block, which may be
inserted into a trace header. Multiple measurement blocks may be used in any trace. Supported measurements are
depth, temperature, pressure, wind speed, altitude, uphole time, etc. Note: The format of the Measurement block
is still not finalized, discussions still ongoing with Energistics regarding the contents.
28. The General Trailer format has been completely changed from that of Rev 2.x. The new General Trailer format
consists of a number of blocks of data, each a multiple of 32 bytes, and starting with a 32 byte description header.
Any binary or ASCII block data may be stored unmodified as part of the General Trailer, as long as the block is
padded with zeros (0x00 – for binary data) or spaces (0x20 – for ASCII data) until it is a multiple of 32 bytes
long.
29. An edit format has been defined as part of the General Trailer, to simplify addition of post acquisition edit records
(e.g. by quality control or processing systems), to standardize transfer of edit information between acquisition and
processing. The format is based on the SEG ADS Trace Edit format (Norris et. al. 1999).
30. Storing positioning files like P1 and P2 as part of the General Trailer (for backup purposes), has been
standardized.
31. Some other simple Trailer blocks, like Observer Log and Text Comments have also been defined.
32. Several examples have been added to Appendix E.
33. Revision 2.x Appendix D “Header Descriptors” has been removed.
34. Appendix F, which previously listed specific tape drives and corresponding maximum block sizes, has been
removed. SEG-D revision 3.0 supports data on any fixed block, variable block and byte stream device including
tapes, disks, DVDs, and network connections with record sizes up to any specific device, operating system, file
system, or network limits. The plan is to keep information regarding specific devices, their block sizes and
recommended usage in the Technical Standards pages on http://www.seg.org. This will allow keeping the
information up to date without modifying the standards document.

2.1 Changes Introduced in Revision 2.1
The following list discusses each of the specific changes made in Revision 2.1 compared to Revision 2.0.
1. Revision number changed from 2.0 to 2.1, see
- Chapter 4, field number 2
- Chapter 8.2 (General Header # 2, byte 11 and 12).
2. Since Rev 2.1 is intended to handle ultra high density tapes, acceptable media is expanded to include:
STK 9940B, IBM 3592 (Jaguar-1) and IBM TS1120 (Jaguar-2).
For further details, see Appendix F.
3. More than one production line per tape is allowed, as long as a unique combination of field file number and a new
line sequence number are used per storage unit.
The sequence number was added to General Header # 2, byte 21–22. Range is 1–65535 (Set to 0 if not valid).
4. Appendix A is updated (Manufacturers of Seismic Field Recorders).
5. Appendix C is updated (API Producer Organization Codes). Organization codes are now assigned by POSC which
maintains the current list of codes (API in previous revision).
6. Producer organization code is no longer a required field.

2.2 Changes Introduced in Rev 2.0
The following list discusses each of the specific changes made in Revision 2.0 compared to Revision 1.0. Also
mentioned are changes which were discussed as potential changes to be included in Rev 2.0, but were not included in
Rev 2.0.
1. Since Rev 2.0 is intended to handle higher density tapes, acceptable media is expanded to include: 3490/3490E,
3590, D2, and D3.
2. It is not anticipated that the higher density drives will be used to record multiplexed data. Rev 2.0 does not
support multiplexed data.
3. No specific changes will be made to SEG-D to handle “non-shot domain” data. Either a new committee should
be formed, or the charter of this committee should be extended to develop a new format for this application. It
does not appear practical to extend SEG-D to fit this application.
4. No special arrangements will be made to provide a standard method of recording SPS in the SEG-D header. The
relevant portions of SPS can be put into existing header extensions in user defined positions.
5. The MP factor description will be modified to clarify the meaning for fixed bit data (see MP discussion in
section 7).
6. The description of byte 12 in the General Header is being clarified to clearly state that the byte defines the
number of additional blocks. Figure 4 in the SEG-D Rev 1 document will be changed from # BLKS IN GEN
HDR to “# Additional blks in Gen Hdr”. Another correction will be made to correctly state, for byte 1 of the
General Header, “File number of four digits (0–9999) set to FFFF (Hex) when the file number is greater than
9999.
7. The RECEIVER LINE NUMBER (bytes 1–3) and RECEIVER POINT NUMBER (Bytes 4–6) in the Trace
Header Extension have been modified to include a fractional component. An all one’s pattern (FFFFFF16) in
either of these fields, will serve as a flag to indicate that the complete five byte value will be located in newly
defined locations in the Trace Header Extension. See Trace Header Extension table below.
8. The maximum number of Trace Header Extensions is now limited to 15.

9. Channels within the same Channel Set must now have the same number of Trace Header Extensions. Since all
traces within a Channel Set will now contain the same number of Trace Header Extensions, the number of
Trace Header Extensions will be indicated in the Channel Set Descriptor. The previously unused nibble of Byte
29 in the Channel Set Descriptor will now be defined to be a 4 bit binary parameter that defines the number of
Trace Header Extensions for that Channel Set. Byte 29 of the Channel Set descriptor will now be:
0 1 2 3 4 5 6 7
EFH3 EFH2 EFH1 EFH0 THE3 THE2 THE1 THE0
As a result of this limitation the Trace Header Extension field in Byte 10 of the Trace Header will also be
redefined as a 4 bit value limited to a maximum of 15 Trace Header Extensions.
10. The length of each trace within a Channel Set is now restricted to be the same value. This limitation and the
restricting the number of Trace Header Extensions to the same number within a Channel Set will result in each
trace within a Channel Set being recorded with the same number of bytes.
11. A tape label will be required on each tape. The details of this label format are described in section 4.

12. Data may be recorded in large logical blocks to maximize the transfer rates with high density tape systems. 3
types of device structures are supported:
A) Variable block length devices.

Every shot record must be aligned on a block boundary (i.e. each block will contain data from only one shot
record). Multiple channel sets may be included in each block. When the data to be recorded in a block contains
less than the maximum number of bytes in the block, there will be no padding characters to fill the block.
Storage Unit Structure in field 3 in Storage Unit Label must contain the text “RECORD”
B) Byte stream devices
There is no concept of a block, even though there is a hidden underlying physical block structure. Within each
file, one or more shot records are written consecutively without any gap.
C) Fixed block length devices

record). Multiple channel sets may be included in each block. Typically the last block in a shot record will
contain less data than the block size, the remaining part of this block will be padded with characters without any
information.
Storage Unit Structure in field 3 in Storage Unit Label must contain the text “FIXREC” and the block size is
found in field 5 in Storage Unit Label.
Note: Structure A can be mapped to a file directly but one can not re-generate the same interblock gaps and
File Marks from data stored on a file. Structure B and C can be mapped to a file directly and the structure can be
re-generated apart from the original position of the File Marks.
13. An appendix will be added to indicate the maximum allowable block size for accepted types of media. It is
expected that this table will need to be updated approximately once per year.
14. Byte 12 of the Trace Header will have an additional option, TR= 03 Trace has been edited. This parameter will
indicate the acquisition system has modified one or more samples of this trace. During data acquisition, if a
telemetry error occurs, a sample may be corrupted. Some radio acquisition systems fill in this missing data with
a copy of the previous sample, or interpolate to fill in the missing sample. Trace edit can also occur when a
noise edit process is applied by the acquisition system. The TR=03 flag should be set for those traces which
have been modified by the acquisition system.
15. The SEG-D, Rev 2.0 format treats data going to tape as a byte stream. File Marks are not required to separate
shot records, however File Marks may be included in between shot records where appropriate to ease error
recovery and/or to provide logical partitioning of the data. If used, File Marks may only be recorded at shot
record boundaries. For field tapes, File Marks should be written as frequently as possible, preferably for every
shot. If data is staged on disk, many shots can be stored in each file. When SEG-D, Rev 2.0 data is recorded on
tape, an EOD mark must be recorded after the last valid record and prior to the end of tape
16. The time standard referenced by byte 14 of the General Header has been changed from GMT to UTC.
17. Partitioning of a tape or other type media volume is now allowed. Each partition, or each tape if not partitioned,
constitutes one storage unit. The storage unit label shall consist of the first 128 bytes of the first user-writable
tape record in the first user-writable physical block and may, optionally, be followed by a File Mark. No File
Mark shall be written before the storage unit label.

18. Added a field in the Trace Header extension to indicate the type of sensor used for that trace (Byte 21).
2.3 Changes Introduced in Rev 1
In 1994, several changes were introduced to SEG-D to increase flexibility. These changes are listed below.
1. To allow for additional defined fields in SEG-D headers, additional blocks are allowed for the General Header and
Demux Trace Header.
2. Added provision for an optional set of General Trailer blocks. This type header allows provisions for recording
auxiliary seismic system and real-time navigation related data in the trailer. The trailer is optional and typically
follows all other recorded data.
The addition of the trailer will allow the accumulation of system faults, data QC information, real-time navigation
position, and timing information on the same tape, and contiguous with, the shotpoint that it relates to. By
recording this data after all of the other data, additional time is provided for collecting the data and transferring it to
the recording system.
The Trailer blocks take the same general form as the Channel Set Descriptor. Byte 11 uses the "Channel Type
Identification" set to 1100 to indicate a Trailer block. Bytes 1 and 2 indicate the number of the General Trailer
block, with the first block numbered as 1.
All other information in the trailer is optional and may be formatted as desired by the manufacturer/user.
The number of General Trailer blocks is indicated in bytes 13 and 14 of General Header Block #2.
3. Provide provision to include the revision of SEG-D format. Added to Bytes 11 and 12 of General Header Block #2
contain the SEG-D Revision Number. The revision number is a 16 bit unsigned binary number. The Revision
number is 1 for the proposed version.
In addition, in the General Header Block #1, nibble 1 of byte 12 contains the number of additional blocks in the
general header. Nibble 1, byte 12 is an unsigned binary number. This number will be 1 or greater for SEG D Rev
1.
4. Added provision to include the source and receiver locations for each source and receiver location. Source
locations are included in the General Header Blocks. Block #3 contains the position for Source Set #1. Additional
General Header Blocks may be included to allow for additional Source Sets.
Source positions are defined by a Source Line Number (three bytes integer and two bytes fraction), a Source Point
Number (three bytes integer and two bytes fraction), and a Source Point Index (one byte). This index allows several
locations for the source in the grid, the original value is 1 and that value is incremented by 1 every time the source is
moved, even when it is moved back to a previous location).
Receiver locations are included in Trace Header Extensions to be used with Demux Trace Headers. Receiver
positions are defined by a Receiver Line Number (three integer bytes and two fraction bytes), a Receiver Point
Number (three bytes integer and two bytes fraction), and a Receiver Point Index (one byte). This index allows for
defining the receiver group in the grid, the original value is 1 and that value is incremented by 1 every time the
receiver is moved, even when it is moved back to the previous location.
5. Provide for the use of File Numbers greater than 9999. Bytes 1, 2, and 3 in General Header Block #2 allow for a
three byte, binary file number. When the file number is greater than 9999, bytes 1 and 2 in the General Header
Block #1 must be set to FFFF.

6. Provide for Extended Channel Sets/Scan Types. General Header Block #2 allows for a two byte, binary number of
Channel Sets/Scan Types in bytes 4 and 5. When using the Extended Channel Sets/Scan Types, byte 29 of General
Header #1 must be set to FF.
7. Provide for additional Extended and External Header blocks. General Header Block #2 bytes 6 and 7 (for Extended
Header blocks) and Bytes 8 and 9 (for External Header blocks) allow the use of a two byte, binary number to allow
more than 99 blocks. When using these capabilities, General Header Block #1 byte 31 (for extended) and byte 32
(for external) must be set to FF.
8. Provide a mechanism for recording additional information about vibrator sources. Byte 15 of the General Header
Block #N indicates the signal used to control vibrator phase. Byte 16 indicates the type of vibrator (P, Shear,
Marine). Bytes 28 and 29 contain the phase angle between the pilot and the phase feedback signal.
The additional vibrator information may be recorded for multiple sets of sources by using additional General
Header blocks.
9. Provide for larger number of samples per trace. Using bytes 8, 9, and 10 of the Trace Header Extension.
10. Provide provisions for using 1/2" square tape cartridges. (ANSI X3.180 1989).
11. Allow recording data in IEEE and other new formats.

Additional Valid Format Codes for bytes 3 & 4 of the General Header are:
0036 24 bit 2's compliment integer multiplexed

0038 32 bit 2's compliment integer multiplexed
0058 32 bit IEEE multiplexed
8036 24 bit 2's compliment integer demultiplexed
8038 32 bit 2's compliment integer demultiplexed
8058 32 bit IEEE demultiplexed
The IEEE format is fully documented in the IEEE standard,

"ANSI/IEEE Std 754 - l985", available from the IEEE.
The IEEE format is summarized as follows:

Bit 0 1 2 3 4 5 6 7
Byte 1 S C7 C6 C5 C4 C3 C2 C1
Byte 2 C0 Q−1 Q−2 Q−3 Q−4 Q−5 Q−6 Q−7
Byte 3 Q−8 Q−9 Q−10 Q−11 Q−12 Q−13 Q−14 Q−15
Byte 4 Q−16 Q−17 Q−18 Q−19 Q−20 Q−21 Q−22 Q−23 (see Note 1)
The value (v) of a floating-point number represented in this format is determined as follows:
if e = 255 & f ≠ 0. .v = NaN Not-a-Number (see Note 2)

if e = 255 & f = 0. .v = (−1)s ×  Overflow
if 0 < e < 255. . . . . v = (−1)s × 2e−127 × (1.f) Normalized
if e = 0 & f ≠ 0 . . . v = (−1)s × 2e−126 × (0.f) Denormalized
if e = 0 & f = 0 . . . v = (−1)s × 0 ± zero
where e = binary value of all C's (exponent)

f = binary value of all Q's (fraction)
NOTES: 1. Bit 7 of byte 4 must be zero to guarantee uniqueness of the start of scan in the Multiplexed
format (0058). It may be non zero in the demultiplexed format (8058).

2. A Not-a-Number (NaN) is interpreted as an invalid number. All other numbers are valid and
interpreted as described above.
12. Allow for the use of blocked records. Allow blocked demultiplexed data (integral number of traces in a block).
Headers will not be blocked. All records in a block will be the same size. Not all blocks will be the same size.
Byte 20 in the general header (B1 = 1) will indicate blocked data. Blocks will be limited to 128 kilobytes. All
traces in a block are in the same Channel Set.
13. Added the effective stack order (unsigned binary), in byte 30 in the Channel Set descriptor. Set to 0 if the trace
data was intentionally set to real 0. Set to 1 if no stack. Set to the effective stack order if the data is the result of
stacked data (with or without processing).
14. Improved definition of undefined fields. All undefined fields will be specified as: "This field is undefined by
this format".
15. Added provisions for a Trace Edit byte (byte 10 of Demux Trace Header) to indicate traces zeroed for roll-on or
roll-off and to indicate deliberately zeroed traces.
TR=0 No edit of this trace

TR=1 Trace part of dead channels for roll-on or roll-off spread; trace intentionally zeroed.
TR=2 Trace intentionally zeroed.
16. Increased precision of MP factor, using byte 7 of the Channel Set descriptor.
17. Since modern seismic vessels record more than one streamer at a time, a standard convention is required to
identify which streamer recorded each channel of data. The Channel Set Descriptors are updated to handle this
task. The definition of a channel set is expanded to include the following rules. A channel set is a group of
channels that:
a) Use identical recording parameters. This includes the same record length and sampling interval.
b) Use identical processing parameters, including the same filter selection and array forming parameters.
A field has been added to Channel Set Descriptor byte 32 to describe any array forming applied to data
in that channel set.
c) Originates from the same streamer cable for marine data. The streamer cable number for each channel
set has been added to Channel Set Descriptor byte 31.
d) Consists of channels with the same group spacing. For example, if one steamer has short group spacing
close to the boat and longer groups spacing at long offsets, the data from that streamer would be
recorded as two channel sets.
In addition, the first channel in each channel set will start with Trace number one.
18. Correct the MP factor calculation (refer to Appendix E7 in the SEG-D recording format description.)
MP CALCULATION
The calculation of MP for a data recording method is given by one of the following equations:
(1) MP = FS − PA − Cmax; for binary exponents,
(2) MP = FS − PA − 2 x Cmax; for quaternary exponents,
(3) MP = FS − PA − 4 x Cmax; for hexadecimal exponents (except the 4 byte excess 64 method),
(4) MP = FS − PA − 4 x (Cmax − 64); for excess 64 hexadecimal exponents,
(5) MP = FS − PA − (Cmax − 127); for 32 bit IEEE exponents,
where
2FS = Converter full scale (millivolts),

2PA = Minimum system gain,
and
Cmax = maximum value of the data exponent,
Cmax = 15 for binary exponents,
7 for quaternary exponents,
3 for hexadecimal exponents except excess 64,
127 for excess 64 exponents, and
255 for 32 bit IEEE exponents.
19. Added the option for using record lengths in millisecond increments (rather than the previous 0.5 second
increments). The Extended Record Length is the record length, in unsigned binary milliseconds, and is recorded
in bytes 15–17 in General Header Block #2. If this option is used, Record Length (R), in the General Header
Block #1, bytes 26, 27 must be set to FFF.

3.0 Format Overview
A SEG-D record consists of three different parts stored consecutively on a storage media.
Record Header Trace Data Record Trailer

(Mandatory) (Optional) (Optional)
Start or record End or record
On blocked devices like tapes, each of these parts must start on a block boundary.
The SEG-D, Rev 3.0 format treats data going to physical storage devices as a byte stream which may be conveniently
divided, if needed, into records and blocks.1 Figure 1 illustrates a typical record structure.
Each SEG-D Rev 3.0 dataset must begin with a storage unit label, as detailed in section 4. Following the label, each
SEG-D record is recorded in demultiplexed format. SEG-D, Rev 3.0 does not support multiplexed data records.
A tape or other media to be used for SEG-D, Rev 3 recording may be partitioned. Each partition, or each tape if not
partitioned, constitutes one storage unit. A disk file is a partition of a disk, and hence constitutes a storage unit. If SEG-
D data are stored on a raw disk device (no filesystem, i.e. a byte stream device), the entire device may be considered a
storage unit. Transferring SEG-D data across networks is allowed. Each network port (e.g. TCP or UDP socket) is then
considered a storage unit. A network port may be used to transfer an unlimited sequence of SEG-D field records.
However each time the transfer is closed and (re)opened, the data must be prepended with a storage unit label. Using
other types of media for storing or transferring SEG-D data is allowed. Some examples are USB memory sticks, flash
devices, solid state disks, DVDs, serial ports, raw ethernet transfer. The same rule applies here: if the device is
partitioned, e.g. placing each field file into a separate disk file, each partition is considered a storage unit. However if
SEG-D data are read/written to the entire device as one unit, the entire device is considered a storage unit.
The storage unit label (tape label) shall consist of the first 128 bytes of the first user-writable tape record in the first
user-writable physical block and may, optionally, be followed by a File Mark. No File Mark shall be written before the
storage unit label. For field tapes we recommend the storage unit label be followed by a File Mark.
When blocked data are being recorded, all of the headers may be included in the same block with the initial channel set.
If the header spans multiple blocks, the remaining part of the header may be stored in the same block as the initial
channel set. Each channel set may be split across block boundaries. A trace may be split across several blocks, and a
trace does not have to start on at a block boundary. The trace header may also be split across blocks.
Data may be recorded in large blocks to maximize the transfer rates with high density tape systems. Three types of
device structures are supported:
A) Variable block length devices.
record). Multiple channel sets may be included in each block. Blocks should not be padded to make their length
up to the maximum block size specified in the Storage Unit Label.
1
Each new field file must begin at a record boundary.

B) Byte stream devices
There is no concept of a block, even though there is a hidden underlying physical block structure. Within each
file, one or more shot records are written consecutively without any gap.
Storage Unit Structure in field 3 in Storage Unit Label must contain the text “RECORD”, and Maximum Block
Size should be set to 1.
C) Fixed block length devices
record). Multiple channel sets may be included in each block. Typically the last block in a shot record will
contain less data than the block size, the remaining part of this block will be padded with characters without any
information.
Storage Unit Structure in Field 3 in Storage Unit Label must contain the text “FIXREC” and the block size is
found in Field 5 in Storage Unit Label.
Note: Structure A can be mapped to a file directly but one can not re-generate the same inter-block gaps (if
present) and File Marks from data stored on a file. Structure B and C can be mapped to a file directly and the
structure can be re-generated apart from the original position of the File Marks.
The SEG-D, Rev 3.0 format treats data going to tape as a byte stream. File Marks are not required to separate shot
records, however File Marks may be included between shot records where appropriate to ease error recovery and/or to
provide logical partitioning of the data. If used, File Marks may only be recorded at shot record boundaries. For field
tapes, File Marks should be written as frequently as possible, preferably for every shot. If data are staged on disk, many
shots can be stored in each file. When SEG-D, Rev 3.0 data are recorded on tape, an EOD mark must be recorded after
that last valid record and prior to the end of tape.
If the tape media supports multiple partitions, SEG-D data may be written to any of the partitions of the tape, each
beginning with a Storage Unit Label. Data from one partition cannot “run-over” into a subsequent partition, each
partition must be capable of being decoded in isolation.
On one tape, it is allowable to mix partitions containing SEG-D data with partitions containing non SEG-D formatted
information.
The headers of SEG-D Rev 3.0 can be very large compared to previous versions of the format. The maximum for each
of the main header types are shown below:
 General Header: 2,097,120 bytes ~ 2 MB
 Skew headers: 2,097,120 bytes ~ 2 MB
 Scan type header/Channel Set descriptors: 6,291,360 bytes ~ 6 MB per scan type (up to 99 scan types)
 Extended Header: 536,870,880 bytes ~ 512 MB
 External Header: 536,870,880 bytes ~ 512 MB
 General Trailer: 137,438,953,440 bytes ~ 128 GB
 Trace Header: 8,180 bytes ~ 8 kB
In addition, the maximum trace size is
 Trace: 8,180 (header) + 34,359,738,360 (data) bytes ~ 32 GB
Note: The headers and traces may therefore span multiple tape blocks.

SEGD Rev 3.0 disconnects tape blocks from data blocks completely, the start of a header block/start of trace may be
anywhere in a tape block. A header may also be split between two tape blocks, e.g. a trace header may have just one
byte in one tape block, and the rest continuing in the next block.
The maximum block size used on the storage media is listed in the Tape Label, bytes 20-29. The maximum block size is
limited to about 4 GB in SEG-D Rev 3.0. If the storage device supports less than 4GB blocks, the maximum block size
is determined by the manufacturer of the device. The following values should be used as the maximum block size in the
media Tape Label:
 For fixed block size media, this will be the block size of the media.
 For variable block media, this will be the maximum block size used on the tape. The size is determined by the
data recorder, and may be less than the maximum value determined by the device manufacturer. The size should
be selected to allow efficient reading and writing data to/from the media.
 For byte stream media, e.g. tape devices like D2, disk, USB memory sticks, network transfer, etc., the
maximum block size is always set to 1.
SEG-D data is streamed to/from the storage device as a stream of bytes, split into blocks as defined by the device
manufacturer and the maximum block size in the Tape Label, with the following modifications:
 The Tape Label must be located at the beginning of the media, with no preceding data.
 It is strongly recommended to write an end-of-file mark after the Tape Label.
 The General Header Block #1 (start of record), the first Trace Header (start of data) and the first General
Trailer block (start of trailer) will always be located at the beginning of a device block. For fixed block size
media, this means the previous block may have to be padded with zeros, and for variable block size media, the
previous block may be smaller than the maximum block size indicated in the Tape Label.

Information layout
128 bytes 32 bytes 32 bytes 32 bytes N x 32 bytes N x 32 bytes N x 32 bytes 96 bytes 96 bytes
B E General General General CRS Channel Channel Channel Sample Channel Sample Extended External General E Next Last E TOC E E
Storage General info Source info
O O header header header definition set 1 set 2 set n skew set n skew header header Data trailer O SEGD SEGD O File O O
unit label (optional) (optional)
T F #1 #2 #3 (optional) Header Header Header Header Header Header (optional) (optional) (optional) F record record F (optional) F F
Optional
Additional General Header blocks Scantype 1 ... Last scantype
SEGD channel description header
SEGD record header
H H H H H H H H H H
D Data D Data D Data D Data D Data D Data D Data D Data D Data D Data
R R R R R R R R R R
Trace 1 Trace 2 Trace n1 Trace 1 Trace n2 Trace 1 Trace nn
Channelset 1 Channelset 2 Channelset n
Scantype 1 Scantype 2 Last scantype

20 bytes
User defined
Demux Sensor Source Position Orientation
Trace header trace header
trace information information information information
extension extension
header (optional) (optional) (optional) (optional)
(optional)
Trace header (up to 8180 bytes)
Figure 1. Record Format

Device specific file mark (optional)
Record Header (partial)
:
Trace Header
Data Chset 1 / Trace 1(partial)
Increasing Physical Block Number
Chset 1Trace 1
Data Chs 1 / Tr 1 Trace Header

(partial) Chset 1 Trace 2 Data Chset 1 / Trace 2
Trace Header
Data Chset 1 / Trace 2 (partial) Data Chset 1 / Trace 3 (partial)
Chset 1Trace 3
HDR 2 / 2
HDR 2 / 3
HDR 2 / 1
(partial)
Data Chset 1 / Trace n1 (partial) Data Chset 2 Data Chset 2
Trace 1 Trace 2
Data Channelset n/Trace nn
General Trailer, block 1
General Trailer, block ntrailer

Tape Label requirements:
Field 3: Record
Maximum Block Size (Tape Label, Field 5) Field 5: Largest block size
Maximum Physical Block Length of Device

Figure 2. Variable Block Length Format Example

:
Record Header (partial) Pad (0x0)
Trace Header
Data Chset 1 / Trace 1(partial)
Chset 1Trace 1
Increasing Physical Block Number
Data Chs 1 / Tr 1 Trace Header Data Chset 1 / Trace 2

(partial) Chset 1 Trace 2
Trace Header
Data Chset 1 / Trace 2 (partial) Data Chset 1 / Trace 3 (partial)
Chset 1 Trace 3
HDR 2 / 2
HDR 2 / 3
HDR 2 / 1
(partial)
Data Chset 2 Data Chset 2
Data Chset 1 / Trace n1 (partial)
Trace 1 Trace 2
Data Channelset n/Trace nn Pad (0x0)
General Trailer, block 1
General Trailer, block ntrailer Pad (0x0) Tape Label requirements:

Field 3: FixRec
Field 5: Block size of device
Maximum Physical Block Length of Device
Figure 3. Fixed Block Length Format Example

Device specific file mark
Record
Data (Traces)
Header
Shot Record #1
Record
Data (Traces) Header Data (Traces)
Shot Record #1 Shot Record #2

One Field File
General
Data (Traces) Trailer
Shot Record #2
Ge
Record
n
Data (Traces)
Tra
Header
iler
Shot Record #3
General Tape Label requirements:

Data (Traces) Trailer Field 3: Record
Field 5: Largest Block Size set to 1
Shot Record #3 Field 10: Max shots/file set to
number of records between file
marks (in this example 3)
Device specific file mark
Figure 4. Byte Stream Device Example (3 records with and without General Trailer)

Start of disk file
Disk file
Tape Record Format is similar to Byte Stream
Data (Traces) device, however each disk file is a
Label Header
storage unit starting with a Tape
Shot Record #1 Label, and may contain any
number of SEG-D records.
Record Network transfer (e.g. Ethernet)

Data (Traces) Data (Traces) Similar format is used when
Header
transferring SEG-D records
Shot Record #1 Shot Record #2 across networks. Every time a
network port is opened/transfer
One Field File
initiated, it is viewed as starting a

General new storage unit, hence a Tape
Data (Traces)
Trailer Label must be sent prior to any
SEG-D records. If number of
Shot Record #2 records to be sent is unknown at
the initiation of transfer, Field 10
of the Tape Label is set to 0.
Ge
Record
n
Data (Traces)
Tra
Header
iler
Shot Record #3
Tape Label requirements:

General Field 3: Record
Data (Traces)
Trailer Field 5: Largest Block Size set to 1
Field 10: Max shots/file set to
Shot Record #3
number of records in file (in this
example 3). If unknown at the time
of Tape Label creation, set to 0
(undefined/unknown)
End of disk file
Figure 5. Disk File Example (3 records with and without General Trailer)

3.1 SEG-D timestamp
SEG-D Rev 3.0 supports a more accurate time stamp than provided by the earlier versions. (Rev. 2.x had only a
timestamp accurate to one second stored in General Header Block #1.) There is need to be able to give each sample an
accurate timestamp, to be able to tie seismic data to external events, externally acquired data, or similar. Previously
every manufacturer had their own proprietary time format, e.g. by storing a timestamp as part of the Extended or
External Header. As of SEG-D Rev 3.0, a timestamp is stored in General Header Block #3, bytes 1 to 8. It is still
permissible to store timestamps as part of the External or Extended Header, however the official time of the SEG-D
record is now found in General Header Block #3.
Definition
A SEG-D Rev 3.0 timestamp is an 8 byte, signed, big-endian integer counting the number of microseconds since
6 Jan 1980 00:00:00 (GPS epoch). The timestamp is equal to GPS time converted to microseconds.
This 8 byte timestamp is heretofore referred to as a SEG-D timestamp.
The number range an 8 byte microsecond count supports is approximately 9223372036854 seconds or 292471 years.
Dates before 6 Jan 1980 00:00:00 will have negative timestamps. The earliest timestamp allowed in prior revisions of
SEG-D was 1 Jan 1970 00:00:00 (SEG-D epoch). See below for more details regarding conversion between timestamp
and UTC.
There are several reasons why GPS time has been selected as basis of SEG-D timestamp:
- Most seismic acquisition systems use GPS for positioning, and hence have GPS time easily available
- GPS time does not contain leap seconds, which would cause a problem for processing of any record crossing
leap second boundaries (remember, in Rev 3.0 measurements at several different times during the record may
exist). For this reason, UTC was not chosen as basis for timestamp.
- There are other time formats without leap seconds, such as International Atomic Time (TAI) which tracks
proper time on the Earth’s geoid; however GPS is more commonly used in seismic acquisition systems.
- There are proposals for redefinition of UTC (to eliminate leap seconds). This would cause problems for
handling historical data (i.e. tapes), as there would be a difference in definition before and after the change.
- Leap seconds are unpredictable (the Earth rotation speed changes at an unpredictable rate), so it is not possible
to create a mathematical formula to calculate leap second.
Relative Time Mode record

For recording systems without absolute time, the timestamp in General Header Block #3 (bytes 1 to 8) must be set to 0,
and the Relative Time Mode in General Header Block #3 (byte 30) set to 1. All timestamps in the record must then be
relative to start of record (time zero). If reference to absolute time is required for such a record, the manufacturer is
responsible for providing the required information separately.
The time stamp in General Header Block #1 can in Relative Time Mode either be set to 1 Jan 1970, an approximate
value of the actual time, or a relative time compared to other records in the survey, whatever the manufacturer
determines would best help interpretation of the data.

SEG-D timestamp and UTC conversion
There are a few problems with choosing GPS time as foundation for a SEG-D timestamp, mainly related to the
timestamp in General Header Block #1, which is UTC (Coordinated Universal Time) or GMT (Greenwich Mean Time).
This has not been changed in Rev. 3.0 for backward compatibility. However, when reading and writing SEG-D Rev 3.0
records, it is important to handle the differences, i.e. by adding the proper number of leap seconds.
GPS was aligned with UTC on 6 Jan 1980, but due to the variation in Earth’s rotation, the definition of seconds, etc.,
leap seconds have to be added to UTC. As of April 2009, UTC time is 15 seconds behind GPS time.
The sequence of dates of the UTC second markers during leap second are:
31 December 2005, 23h 59m 59s
31 December 2005, 23h 59m 60s
01 January 2006, 0h 0m 0s
Note: The interpretation of UTC timestamps needs to allow 60 as a value of seconds! This was previously not accounted
for in the Rev 2.x standard.
As GPS time is not defined prior to 6 Jan 1980, leap seconds are added to UTC as defined by International Atomic Time
(TAI) such that the SEG-D timestamp equals TAI time plus 19 seconds at the TAI epoch (1 Jan 1972 00:00:00). (The
reason for the 19 seconds difference is the TAI choice to start off with an initial difference to UTC of 10 seconds (TAI
was synchronized with UTC at the start of 1958, and has drifted ever since), then 9 leap seconds were added during the
1970s. As GPS time was synchronized to UTC 6 Jan 1980, GPS time is now running at a fixed 19 second difference to
TAI.)
Prior to 1970 no official leap seconds existed, so SEG-D defines for the purpose of timestamp/UTC conversions that no
leap seconds exist for 1970 and 1971 (this should have very few practical consequences).
UTC to SEG-D timestamp difference:
01 MAR 2008: UTC 14 seconds behind timestamp
06 JAN 1980: UTC equal to timestamp
01 JAN 1970: UTC 9 seconds ahead of timestamp
See Appendix E for examples of conversions between UTC and SEG-D timestamp.
The table below shows leap seconds added to UTC time since 1970. Note the values for 1970 and 1971 (in italics) are
not according to international standards; they are just values used to allow conversion of dates back to 1 Jan 1970 (SEG-
D epoch):
Year 30 June 31 Dec

1970 none none
1971 none none
1972 +1 second +1 second
1973 none +1 second
thru each year
1979
1980 none none

1981 +1 second none
1982 +1 second none
1983 +1 second none
1984 none none
1985 +1 second none
1986 none none
1987 none +1 second
1988 none none
1989 none +1 second
1990 none +1 second
1991 none none
1992 +1 second none
1993 +1 second none
1994 +1 second none
1995 none +1 second
1996 none none
1997 +1 second none
1998 none +1 second
1999 none none
thru
2004
2005 none +1 second
2006 none none
2007 none none
2008 none +1 second
2009 none none
2010 none none
2011 none none
2012 +1 second

3.2 Multi-component data
Rev 2.x had limited support for multi-component data, but with several deficiencies. Rev 3.0 introduces several new
sensor types, and Position/Orientation header blocks to better cope with multi-component acquisition.
Multi-component data should be recorded with each component in separate channel sets, i.e. the X component in one
channel set, the Y component in another, etc. The component type must be clearly indicated in the Channel Set Header
and Trace Header Extension #1. The indices in Trace Header Extension #1 (i.e. receiver line/point/point index/group
index/depth index/reshoot index) will indicate which traces have to be processed together as a unit, e.g. for rotation. The
group index will indicate the component number. The sensor type will indicate which type of data each trace contains.
Component numbering must be made such that
 Cnorth   R11 R12 R13   C1 

 C   
 east    R21 R22 R23  * C2 
Cvertical   R31 R32 R33  C3 
C is a component as indicated, R is the rotation matrix described by the values found in the Orientation Header. C1, C2,
C3 indicates the component numbers (group index) that must be used in the trace extension header. C north, Ceast, Cvertical
are components in the indicated direction after rotation. Please refer to the drawing in the Orientation Header section for
a better description of the different components.
3.3 Extended recording mode
To be able to support different types of advanced recording systems requiring very long record times, SEG-D supports
an Extended Recording Mode.
Extended Recording Mode is turned on by setting the Extended Recording Mode flag of General Header Block #3 to 1
(byte 29). The trace will then start at the time indicated by the Timestamp Block in the Trace Header, not as calculated
by using the Start Time (byte 5–8) of the Channel Set Header. As a consequence of this, the trace in Extended
Recording mode can utilize the entire 4,294,967,295 samples trace length.
As a Timestamp block is used to determine the time of first sample in each Channel Set (e.g. each data block), Extended
Recording mode also allows recording non-continuous data. By adjusting the number of samples in the Channel Set
header (bytes 13-16), and the start time in the Timestamp header (bytes 1-8), the data may contain holes. Note that the
number of samples in each channelset is not required to be the same. Please refer to Appendix E.11 (and E.10) for some
examples of how Extended Recording Mode may be utilized.
3.4 Permanent recording systems
SEG-D Rev 3.0 is also designed to support permanent system recording, though its primary usage is online acquisition
of land/marine/seabed/transition zone surveys.
A permanent system consists of units with typically a few sensors, and recording can last for days or even weeks.
SEG-D 3.0 supports traces of up to 2147 seconds in length. To record data for longer than this, multiple channel sets
must be used, i.e. the same traces continue into the next channel set. See Extended Recording Mode above. Multiple
traces from the same sensor are not allowed in one channel set, but it is not necessary to make a new scan type for the
next channel set. This allows recording of up to 4,294,967,295 samples per trace * 65535 (max number of channel
sets) = 281,470,681 seconds or approximately 3257 days with highest sample rate (1 microsecond). For a more
commonly used sample rate of 2 millisecs, the maximum record length is increased to more than 17850 years. If longer
recording is required, multiple SEG-D records must be created. (Note: The example above assumes only one channel
type is recorded. If multiple channel types are needed, multiple channel sets must be created, and the maximum record
length will be reduced accordingly.)
The sizes of headers have been extended to support the extended amount of meta information required for permanent
surveys. Metadata recording incidents occurring throughout the record may appear as part of the External or Extended
Headers, inserted into the Trace Header Extension, or appended to the General Trailer. For devices with limited amount
of memory and CPU, the General Trailer option might be preferable. All metadata should be tagged with the SEG-D
timestamp (if time related), and/or scantype#/channel set#/trace# (if trace related, and information not recorded as part
of the Trace Header).
3.5 Time drift
Some acquisition systems deploy single sensor unit for long periods of time without synchronization with other parts of
the acquisition system or an external clock reference (e.g. GPS). Time drift (i.e. the clock running at a faster or slower rate
than GPS) is then a problem. SEGD supports recording the time drift for each individual trace in the Time Drift Header
block by storing the time of deployment and retrieval of the sensor, and the corresponding time offsets.
The data can then be time drift corrected using these values directly (linear time correction). If a more advanced time drift
correction is desired, the manufacturer is free to do so. The manufacturer must then provide the time drift correction
information in manufacturer specific header blocks or possibly other external data.
Trace data from a sensor unit may be recorded in SEGD format using a drifting clock, both in normal and extended
recording mode. However all channels within the record must have the same time drift (i.e. use the same time reference
system).
Note:
Trace data must be time drift corrected before merging trace data from multiple drifting sensor units into one single
SEGD record, i.e. start of trace must be aligned, and sample rate must be corrected. SEGD does not support irregular
(drifting) sample intervals or time skew between channels other than specified in the skew blocks and trace sample skew
values.
See Appendix E, EM survey, for more details regarding the time drift correction.
3.6 Positions in SEG-D

SEG-D allows for multiple coordinate tuples for any location. A coordinate tuple is an ordered set of coordinates
describing a position. For redundancy, two coordinate tuples can be given in different coordinate reference types for any
position, e.g. geographic and projected. Coordinate reference system types are:
Coordinate Tuple
CRS type
Coord 1 Coord 2 Coord 3
projected easting or northing northing or easting (not used)
(see note 1) (see note 2) (see note 2)
geographic2D latitude longitude (not used)
geographic3D latitude longitude ellipsoidal height
vertical (not used) (not used) gravity-related height

or depth (see note 3)
geocentric geocentric X geocentric Y geocentric Z
compound latitude longitude gravity-related height
geographic+vertical or depth (see note 3)
compound easting or northing northing or easting gravity-related height
projected+vertical (see note 2) (see note 2) or depth (see note 3)
Notes:
1) Sometimes called "map grid".
2) There is significant variation worldwide in the convention used for projected CRS axis order and abbreviation. In
some cases the easting will be given before the northing and in other cases the order will be northing before
easting. In both of these scenarios the axes may be labeled X and Y; in such instances the first coordinate will be
labeled X regardless of whether easting or northing and the second coordinate labeled Y.
3) Whether vertical coordinates are heights (positive up) or depths (positive down) will be defined in the CRS
definition.
These three fields need to hold the following values:
Coord 1 Coord 2 Coord 3

min max min max min max
Value range: −9,999,999 60,800,000 −9,999,999 60,800,000 −6,400,000 6,400,000
Resolution: 10 significant figures 10 significant figures 9 significant figures
All coordinate fields are to be capable of being signed.
Every coordinate tuple must be time-stamped, allowing multiple coordinate tuples to be given for any source or receiver
location in the record. Coordinates for each location may be given for various phases of a project – planning, execution,
etc.
Coordinates only define location unambiguously when the Coordinate Reference System (CRS) to which they are
referenced has been identified. This is done through the Location Data and/or Location Data EPSG Reference extended
textual stanza. That Location Data stanza may be supplemented with a Location Data Transformation extended textual
stanza. These stanzas are defined in Appendix D and stored in the General Header in multiple Coordinate Reference
System Identification blocks.
All coordinates in a SEG-D file should preferably reference the same coordinate reference system. One CRS definition
and Location Data stanza then applies to all locations. Should there be a requirement to store coordinates in one of a
number of CRSs, then each CRS requires identification through separate Location Data and/or Location Data EPSG
Reference extended textual stanzas. Each coordinate set must be related to the relevant CRS through a reference to the
relevant Location Data Stanza ID value, a single integer number between 1 and 65535.

4.0 SEG-D, Rev 3.0 Structure
4.1 Rev 3.0 Storage Unit Label (Tape Label)
The first 128 bytes of data on a Rev 3.0 tape must consist of ASCII characters and will constitute a Storage Unit Label.
This label is very similar to the RP-66 storage unit label. The Storage Unit Label is also often referred to as the “Tape
Label” for historical reasons. The label format is summarized in the table below.
If the tape media supports multiple partitions, SEG-D data may be written to any of the partitions of the tape, each
beginning with a Storage Unit Label. Data from one partition can not “run over” into a subsequent partition, each
partition must be capable of being decoded in isolation.
On one tape, it is allowed to mix partitions containing SEG-D data with partitions containing non SEG-D formatted
information.
Table 1: Label
Field Description Bytes Start – end byte
1 Storage unit sequence number 4 1–4

2 SEG-D Revision 5 5–9
3 Storage unit structure (fixed or variable) 6 10 – 15
4 Binding edition 4 16 – 19
5 Maximum block size 10 20 – 29
6 API Producer organization code 10 30 – 39
7 Creation date 11 40 – 50
8 Serial number 12 51 – 62
9 Reserved 6 63 – 68
10 Storage set identifier 60
11 External Label Name 12 69 – 80
12 Recording Entity Name 24 81 – 104
13 User defined 14 105 – 118
14 Max shot records per field record 10 119 – 128
Field 1 The Storage Unit Sequence Number is an integer in the range 1 to 9999 that indicates the order in which
the current storage unit occurs in the storage set. The first storage unit of a storage set has sequence number
1, the second 2, and so on. This number is represented using the characters 0 to 9, right justified with leading
blanks if needed to fill out the field (No leading zeros). The rightmost character is in byte 4 of the label. This
field is optional. If not used, it must be blank (filled with blank characters). This implies that this is the only
storage unit within the storage set. Separate Storage Sets should be used for different data types.

Field 2 The SEG-D Revision field indicates which revision of SEG-D was used to record the data on this tape.
SD3.0 indicates that the data was recorded using SEG-D, Revision 3.0 (SD2.1 in previous revision) - This
field is required.
Field 3 Storage Unit Structure is a name indicating the record structure of the storage unit. This name is left
justified with trailing blanks if needed to fill out the field. The leftmost character is in byte 10 of the label.
For SEG-D, Rev 3 tapes, this field must contain “RECORD” or “FIXREC”. This field is required.
“RECORD” — Records may be of variable length, ranging up to the Blocksize length specified in the
maximum Block size field of the storage unit label (if not zero). If the maximum Block size specified is zero,
then records may be of any length.
“FIXREC” — All records in the storage unit have the same length, namely that specified in the maximum
Block size field of the storage unit label. Although all storage units in the same storage set must have a
FIXREC structure, the maximum record length may be different in different storage units. When the
FIXREC option is used, then the maximum record length field shall not be 0 (zero).
Field 4 Binding edition is the character B in byte 16 of the label followed by a positive integer in the range 1 to 999
(no leading zeros), left justified with trailing blanks if needed to fill out the field. The integer value
corresponds to the edition of the Part 3 of the API, RP66 standard used to describe the physical binding of
the logical format to the storage unit. This field is required. The field should be set to ‘B2 ’ for SEG-D Rev
3.0.
Field 5 Maximum Block Size is an integer in the range of 0 to 4,294,967,295 (232−1), indicating the maximum
block length for the storage unit, or 0 (zero) if undeclared. This number is represented using the characters 0
to 9, right justified, with leading blanks if necessary to fill out the field (no leading zeros). The rightmost
character is byte 29 of the label. A valid value or 0 (zero) must be recorded. A value of 1 means byte stream
device (e.g. disk). It is highly recommended to indicate the maximum block length where possible, as this
will determine the size buffer needed to read the data, and will enable reading the data at a more optimal
speed (using multi-block read).
Field 6 Producer organization code is an integer in the range of 0 to 4,294,967,295 (232−1) indicating the
organization code of the storage unit producer. This number is represented using the characters 0 to 9, right
justified, with leading blanks if necessary to fill out the field (NO leading zeros). The rightmost character is
byte 39 of the label. This field may be empty, i.e. may contain all blanks, in which case no storage unit
producer is specified (i.e. same as RP-66 V2).
Organization codes are assigned by Energistics, formerly the Petrotechnical Open Standards Consortium
(POSC), which maintains the current list of codes. Please refer to Appendix C for a list of the currently
assigned codes. To request a new organization code, contact:
Energistics
One Sugar Creek Center Blvd.
Suite 1075
Sugar Land, TX 77478 USA
+1 281 243-2121 telephone
+1 281 243-2132 fax
[email protected]
Field 7 Creation date is the earliest date that any current information was recorded on the storage unit. The date is
represented in the form dd-MMM-yyyy, where yyyy is the year (e.g. 1996), MMM is one of (JAN, FEB,
MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC), and dd is the day of the month in the range 1

to 31. Days 1 to 9 may have one leading blank. The separator is a hyphen (code 45 10). This field is
required.
Field 8 Serial number is an ID used to distinguish the storage unit from other storage units in an archive of an
enterprise. The specification and management of serial numbers is delegated to organizations using this
standard. If an external label is used the name/number must be a subset of the serial number or the External
Label Name in Field 10, and must occupy the rightmost characters in the serial number (or External Label
Name). This field is required.
Field 9 This field is reserved and should be recorded as all blanks (code 3210).
Field 10–12 The Storage set identifier is a descriptive name for the storage set. Every storage unit in the same storage
set shall have the same value for the user defined portion of the storage set identifier in its storage unit
label. Included in the Storage Set Identifier is the External Label Name. The characters in this field are
right justified with leading blank characters as required. If the tape does not have a physical label, then this
field must be blank. A physical label is optional, but if it exists, then this field is required only if the external
label is different from the lower 6 characters of the Serial Number in Field 8. The next field in the Storage
set identifier is the Recording Entity Name. This must contain the crew number or name, or some other
unique identifier which will differentiate the recording entity which recorded this data from any other
recording entity within the organization (as included in field 6). The 24 bytes may by any alphanumeric
characters. If multiple recording systems are used on a vessel or crew, then data recorded on each system
must be clearly distinguished. For example, an ABC Geophysical crew (party 13), on the M/V Gopher,
recording data on two Zip 6000 recording systems might have a Recording Entity Name on tapes recording
on the first recording system of:
ABC, Gopher, P13, Zip#1
On the second system, the Recording Entity Name might be:
ABC, Gopher, P13, Zip#2
The Recording Entity Name field is required.
Field 13 USER DEFINED

The next 14 bytes in this field may contain any other user input information. The only restriction is that the data
must be in ASCII.
Field 14 Max Number of shot records per field record. Field Records are data between File Marks (10 bytes).
It is not acceptable to use an ANSI label (or any other label or data) prior to the Storage Unit Label.
An external, physical label is not required.
4.2 Rev 3.0 Table of Contents (TOC) File (optional)
The SEG-D TOC FILE is a table of contents for a specific tape/file/storage unit. The TOC file consists of a 448 byte
header defining general survey information, followed by a list containing one 64 byte entry for each SEG-D record on
tape. The purpose of this list is to provide fast location of data, and give an overview of the storage media without
scanning through the entire e.g. tape.
The TOC file is optional, however for tapes and other large media it is highly recommended to create a TOC file.

Note: The recorder is responsible for allocating enough space at the end of the storage media to allow storage of the TOC
file. The size of the TOC file is not large, please refer to the end of this section for an example of TOC file size
calculation.
The SEG-D TOC file may be stored on disk to provide an overview of, and fast access to, the data on the media. It is
critical that the Serial Number in the Tape Label, and the SEG-D TOC Header matches to facilitate this functionality. The
naming convention of these files should include the Serial Number, Storage Unit Sequence Number etc. from the Tape
Label, to ease the matching of TOC file to tape media.
On tape the TOC file must be separated from the other data with a File Mark before and after. The TOC file is most
commonly stored at the end of tape (after last SEG-D record, before any double File Mark or end of media), though it may
also be stored at the beginning, directly following the Tape Label.
On disk (and similar devices), where no File Marks exists, the TOC file will not be separated from the rest of the data,
hence the reader will need to recognize the TOC File Header TOC identifier "SEGD TOC FILE".
The TOC file consists of a header, followed by one TOC entry for each SEG-D record on the storage media.
4.2.1 TOC Header

Field Description Data type Start – end byte
1 TOC identifier. ASCII text 1 – 13
2 SEG-D Revision ASCII text 14 – 19

3 Serial number ASCII text 20 – 31
4 Client Identification ASCII text 32 – 63
5 Vessel/Crew Identification ASCII text 64 – 95
6 Country ASCII text 96 – 127
7 Region ASCII text 128 – 159
8 Block ASCII text 160 – 191
9 Survey Area Name ASCII text 192 – 223
10 Contract Number ASCII text 224 – 255
11 License ID ASCII text 256 – 287
12 Survey Type ASCII text 288 – 307
13 Acquisition Contractor ASCII text 308 – 339
14 Acquisition Dates (from-to) ASCII text 340 – 364
15 Job Identification ASCII text 365 – 396
16 Media Sequence Within Record Set ASCII text 397 – 402
17 Data Type Identifier ASCII text 403 – 434

18 Undefined, fill with spaces (ASCII code 3210) ASCII text 435 – 438
19 Number Of Entries In TOC File ASCII text 439 – 448
The ASCII text fields are left justified, space (‘ ‘, ASCII 3210) padded, unless otherwise specified. ASCII fields may be
left blank, i.e. contain only space (‘ ‘, ASCII 3210 ) if they are not relevant.
If data from multiple surveys are present on the same SEG-D media, most fields of the header may be left blank. If some
fields are common to all data, they may be filled in. Note: Storing data from e.g. multiple surveys onto the same tape is
not recommended.
Field 1 TOC identifier. Text indicating this is a TOC file. The field should be set to "SEGD TOC FILE",
This field is required,
Field 2 SEG-D Revision. Indicates which SEG-D revision data is stored on the media. The field should be set to
SD3.0 to indicate SEG-D Revision 3.0. Must be identical to the SEG-D Revision (Field 2) of the Tape
Label of this storage unit (i.e. tape/disk file). This field is required.
Field 3 Serial number. Must be identical to the Serial Number (Field 8) of the Tape Label of this storage unit
(i.e. tape/disk file). This field is required.
Field 4 Client Identification. The name of the client. Must match General Header #6 of the SEG-D records (if
present).
Field 5 Vessel/Crew Identification. The name of the vessel or crew acquiring the data. Must match General
Header #4 of the SEG-D records (if present).
Field 6 Country. The name of the country the data was acquired in. If multiple countries are involved, they
should all be listed here.
Field 7 Region. The region of the country the data was acquired in.
Field 8 Block. The block name of the survey area. If multiple blocks are involved, they should all be listed.
Field 9 Survey Area Name. The name of the survey area. Must match General Header #5 of the SEG-D records
(if present).
Field 10 Contract Number. The number/name of the survey contract.
Field 11 License ID. The license identification of the survey area.
Field 12 Survey Type. The type of survey, the presently recommended are:
“TOWED MARINE SEISMIC“
“LAND SEISMIC “
“TRANSITION ZONE “
“SEABED SEISMIC “
“VERTICAL SEISMIC “
“ELECTROMAGNETIC “
“COMBINATION “
“OTHER “
The COMBINATION survey is any combination of the survey types, e.g. combined TOWED MARINE

and ELECTROMAGNETIC. Other strings may be used if this increases the usability of the TOC file,
however it is recommended to use the standardized strings whenever possible.
Field 13 Acquisition Contractor. The (legal) name of the acquisition contractor. Must uniquely identify the
acquisition contractor.
Field 14 Acquisition Dates (To-From). The range of dates of the data on this media. If data from only one day is
stored, to and from date is set to same date. The format is “DD-MMM-YYYY – DD-MMM-YYYY”, e.g.
“03-JAN-2009 – 04-JAN-2009”
Field 15 Job Identification. The acquisition contractor job name/number/identification for the survey. Must match
General Header #7 of the SEG-D records (if present).
Field 16 Media Sequence Within Record Set. The sequence of this storage media within this record set. The
sequence starts counting at 1, and is increased with 1 for each storage media (e.g. tape) for the record set
(e.g. sequence or swath). For storage media with data from multiple record sets, this field is set to “1”.
Field 17 Data Type Identifier. The data type identifier states which type of data is present on this storage media.
The acquisition system can freely define the contents. Example: “RAW SEISMIC ORIGINAL
DATASET 1”, “ROT/FILT DATASET COPY 2”.
Field 19 Number Of Entries In TOC File. The number of TOC entries following this header. Field format is
right justified, space (‘ ‘, ASCII 3210 ) padded integer value. This field is required.
4.2.2 TOC Record Entry
Field Description Data type Start – end byte
1 Media File Number ASCII text 1–8

2 Record Within File ASCII text 9 – 15
3 Time of shot ASCII text 16 – 35
4 SEG-D File Number ASCII text 36 – 45
5 Record ID ASCII text 46 - 60
6 Record Set Number ASCII text 61 – 70
7 Line identification (name/number) ASCII text 71 – 94
8 User defined. ASCII text 95 – 128
The ASCII text fields are right justified, space (‘ ‘, ASCII 3210) padded, unless otherwise specified. ASCII fields may be
left blank, i.e. contain only space (‘ ‘, ASCII 3210 ) if they are not relevant.
Field 1 Media File Number. This field is the media file number containing the SEG-D record. Field format:
Unsigned integer. The number starts counting from 1. The Tape Label has Media File Number 1, the first
SEG-D record is usually contained in Media File Number 2. This field is required.

Field 2 Record Within File. Multiple SEG-D records may be stored within one single media file (though this is
not recommended for field tapes). Record Within File starts counting from 1, i.e. the first SEG-D record
has Record Within File = 1 (and starts at byte 0 of the media file). Field format: Unsigned integer. This
field is required.
Field 3 Time Of Shot. This field is identical to the Time Zero of the SEG-D record (General Header Block #3,
bytes 1–8), and matches the timestamp in General Header Block #1 (bytes 11–16). Field format: Signed
integer. This field is required.
Field 4 SEG-D File Number. The SEG-D file number as listed in the General Header of the SEG-D record
(bytes 1–2 of General Header Block #1, or bytes 1–3 of General Header Block #2). Field format:
Unsigned integer. This field is required.
Field 5 Record ID. The record ID identifies the record within the record set. Field format: Signed floating point
value, some examples: “4” “4.0” “4.000” “-4.0512”. This may be the shot point or source point number if
available, but can be any number that identify this record within the record set.
Field 6 Record set number. The record set this SEG-D record belongs to. Must be the same as bytes 21-22 of
General Header #2. Field format: Unsigned integer.
Field 7 Line identification (name/number). The line number or name of the line the record belongs to. For
surveys where both receiver and source line numbers exists, it is recommended to set this field to the
source line number whenever possible. Set to empty (all spaces, ASCII 3210) if not valid. Must match
General Header #8 Line Identification field of the SEG-D record (if present). Field is left justified space (‘
‘, ASCII 3210 ) padded ASCII string.
Field 8 User defined. 34 bytes of user defined ASCII text. The field can be freely utilized by the recorder, but the
contents must be ASCII text. Record as empty (fill with space (‘ ‘, ASCII 3210) if not used).
TOC file size calculation example:
Size of shot:
5000 channels, 10 seismic seconds (i.e. 10240 milliseconds) record length, SEG-D 8036 format (3 byte per
sample) and 2 millisecond sampling rate. All traces recorded for the full record time, each trace has five 32 byte
Trace Header Extension blocks. (For simplicity we ignore the SEG-D record header, it is assumed to be small
compared to the data).
5000 * (10240 / 2 * 3 + 5 * 32 + 20) = 77700000 bytes = 74.1 MB
Size of tape:
300 000 MB (or ~300 GB)
Size of table of contents file:

448 + 300000/74.1 * 128 = 507 kB (approximately)
The recorder of this dataset will need to leave 507 kilobytes of space at the end of a 300 GB tape for storing the
TOC file.
4.2.3 Using the TOC with SEG-D on disk

The Table of Contents is designed to aid in rapid access to data stored on tape and other sequential record-oriented media
where random access to arbitrary byte locations on the media is unavailable. For SEG-D datasets created as one huge
contiguous byte stream disk file, the TOC would be trivial and of quite modest utility, with just a list of TOC Record
entries showing the SEG-D File Numbers in that file, but providing no way of locating those records short of reading
through the disk file until the desired record is encountered (note that the reading is quite simple though as GeneralHeader
#3 contains size of record allowing fast jump to next record). For this reason, as well as to limit the loss of data should a
disk file be corrupted, we recommend that SEG-D data be created directly on disk in the following manner:
- The SEG-D Storage Unit Label and each Record should be written to a separate disk file.
- The naming convention of these files should include the numeric Media File Number from the TOC Record Entry field.
We also recommend the disk file name include the Record Set Number from that same TOC Record Entry and the Media
Sequence Within Record Set from the TOC Header prepended before the Media File Number.
For SEG-D records copied to disk from tape, the existing TOC is copied to a disk file of its own. In order for this copied
TOC to be immediately valid for the disk copy, we recommend the data be copied to disk in the following manner:
- Each individual tape file (which may include multiple SEG-D File Numbers) should be copied to a separate disk file. A
dummy SEG-D Storage Unit Label must be prepended the data. It is recommended that the dummy label is based on the
tape Storage Unit Label, but modifications done such that it will not be confused with the real tape data. It is however
strongly recommended to include a reference to the original tape media in the dummy label, e.g. by utilizing the “User
defined” portion of the Storage Unit Label.
- The naming convention of these files should include the numeric Record Set Number, the Media Sequence Within
Record Set and Media File Number from the existing TOC.
For ease of listing and sorting, the numeric fields embedded in the file names should each be of a fixed length, with
leading zeros padded instead of blanks, so as to accommodate the largest possible value for that field. So, for example, if
we use the template FILE_[rsn]_[mseq]_[mfn].SGD for file names, the Record Set Number (rsn) should be 5 digits
long, the Media Sequence Within File (mseq) should be 6 digits long, and the Media File Number 8 digits long. This
results in a file name of 29 characters, quite manageable on all modern computer systems.
Note: There are a lot of other ways of storing SEG-D data on disk, for example storing each individual tape file as a disk
file in a filesystem directory. This is perfectly legal, and may be very useful for internal data storage, but it is not
considered proper SEG-D data as each disk file does not start with a Storage Unit Label and the data can not be treated
as a stream of bytes (each disk file must be read separately).

5.0 Header blocks
The headers are blocks of data prior to the seismic data which contain auxiliary information about the seismic data, the
acquisition parameters, acquisition geometry, and user-defined information. The header block includes at least three
General Header Blocks, zero or more Scan Type headers, and optional Extended and External headers. Trace Headers
are included in conjunction with each seismic data trace. Sections 7 and 8 detail the content of each type header.
In addition to header blocks which are recorded prior to the seismic data traces, an optional General Trailer is allowed
following the seismic data. This allows recording other auxiliary information which is not available at the beginning of
the record. Sections 7 and 8 include detailed description of the allowed fields of the General Trailer.
5.1 General Headers (General Header Block #1, #2 and #3 are required)
General Header Block #1 is 32 bytes long and contains information similar to SEG A, B, C, and the original SEG-D
headers. Abbreviations are as close as possible to those used in previous formats.
SEG-D, Rev 3.0 requires the use of General Header Block #1, General Header Block #2 (as was also required in SEG-
D, Rev 2.x), and General Header #3 (new with SEG-D, Rev 3.0). The General Headers define basic parameters for the
record such as file number, time of record, number of channel sets, sizes of meta and auxiliary data, etc. General Header
Block #2 allows extended values exceeding the limits of General Header Block #1; the values of General Header Block
#1 are then set to FF16 to indicate the actual value will be found elsewhere. Note that the Rev 2.1 Sequence Number has
been renamed Record Set Number to be applicable for non-towed marine operations. For towed marine operations, the
sequence number should be entered in that field. General Header Block #3 contains an accurate timestamp for the
record in addition to size information for the record to allow quick searching through the record.
Bytes 1–3 in General Header Block #2 allow for a three byte, binary file number. To use this extended file number,
bytes 1 and 2 in General Header Block #1 must be set to FFFF16.
General Header Block #2 also allows for a two byte, binary number of Channel Sets/Scan Type in bytes 4 and 5. When
using the Extended Channel Sets/Scan Type, byte 29 of the General Header Block #1 must be set to FF16.
Additional blocks may be added as needed by the manufacturer or user.
Rev 3.0 has a much more flexible information structure in the General Header than Rev 2.x. All General Header blocks
except General Header Blocks #1–3 are optional, and can appear in any order, and a lot more information can be
entered. (Rev. 3.0 allows up to 65535 General Header blocks, compared to the 15 allowed in Rev. 2.x). To achieve this,
byte 32 of all header blocks have been assigned an ID depending on its contents. The following are currently defined:
ID Contents (Block Name) Additional Scan Trace General

(Byte 32) General Type Headers Trailer
Headers Headers
0216 General Header 2 *
0316 General Header 3 (Timestamp and size *
header)
1016 Vessel/Crew identification * *
1116 Survey Area Name * *
1216 Client Name * *
1316 Job identification * *
1416 Line Identification * *
1516 Vibrator Source Information * *
1616 Explosive source information * *
1716 Airgun source information * *

1816 Watergun source information * *
1916 Electromagnetic source * *
1F16 Other source type information * *
2016 Additional source information * *
2116 Source Auxiliary Channel Reference * *
3016 Channel set description block 1 *
4016 Demux Trace header extension 1 *
4116 Sensor Info header extension block * *
4216 Time Stamp Header block *
4316 Sensor calibration block * *
4416 Time drift block * *
4516 Electromagnetic Src/Recv desc block * *
5016 Position block 1 * *
5516 Coordinate Reference System * *
Identification block
5616 Relative position block * *
6016 Orientation Header block * *
6116 Measurement block * *
7016 General Trailer Description Block *
B016 – FF16 User defined header block * *
Table 2: Header block types defined in SEG-D Rev 3.0
Note the table contains all standard defined header types, including those used in trace headers. This is done to allow the
same information to be inserted into a General Header or a Trace Header, depending on what is most useful. The ‘*’
marks which blocks can be inserted in which parts of the SEG-D structure. Please note:
- The Scan Type Header/Channel Set Descriptors is following the General Header blocks, and should only
contain Channel Set Description block 1-3. No other block types should be inserted in the Scan Type Header.
- The ordering of blocks is used to indicate what the information in the block refers to, e.g. a Position Block
(5016-5216) following a Vibrator Source Information block (1516) describes the position of the specified vibrator.
- The General Trailer consists of manufacturer specified blocks separated by General Trailer Description blocks,
which means any other information, including the header blocks above, may be stored in the General Trailer.
- The table above gives a guide to where the blocks can be stored, however each manufacturer must determine
what is most useful in each case. For example storing Survey Area Name (1116) may not make much sense in
most cases.
And note:
Though there is support for user-defined block types, we recommend using only standard header blocks in the General
Header, and placing user-defined information into an Extended or External header. These have much more available
space available and allow a more flexible format. User-defined blocks are really intended to be used in the Trace
Header.
The General Header is a sequence of 32 byte blocks of different types, identified by the ID in byte 32, describing
general information about the entire record.
Information blocks commonly inserted into a General Header are Vessel/Crew Identification (1016), Survey Area Name
(1116), Client Name (1216), Job Identification (1316), and Line Identification (1416).

If the record is related to a single source event (shot), we recommend inserting information regarding the source (IDs
1516–1916 or 1F16 depending on source type) into a General Header. If multiple source events occur in the record, e.g.
in land slip-sweep operations, storing the source information in the relevant auxiliary source trace headers can be done.
To be able to associate information to the correct source (in General Header or Trace Header), the header blocks should
be ordered such that all information regarding one source is grouped together, followed by information related to the
next source etc. This is crucial when dealing with blocks not containing the Source ID like the Position Block. This can
schematically be summarized like this:
Source
0..1
Description
Additional
0..1
Source Info
Source Aux
0..r 0..n
Channel Reference
0..q
Position
0..m
Block
Any other blocks

0..p
related to the source
For more information regarding the use of Source Description blocks, please refer to example E.7.
Note:
Source information (e.g. Additional Source Info or Source Aux Channel Reference) may appear in Trace Headers
without a Source Description block in front, however there must then be a Source Description block for that source in
General Header. It is not allowed to store source information in General Header without a Source Description block.
5.2 Scan Type Headers
The Scan Type Header is used to describe the information about the recorded channels (filters, sampling intervals,
sample skew, etc.). The Scan Type Header is composed of one or more channel set descriptors followed by skew
information. The channel set descriptors must appear in the same order as their respective channel sets will appear
within a base scan interval. A channel set, which is part of a scan type, is defined as a group of channels all recorded
with identical recording parameters. One or more channel sets can be recorded concurrently within one scan type. In
addition, there can be multiple scan types to permit dynamic scan type changes during the record (e.g., 12 channels at
1/2 ms switched at about 1 second to 48 channels at 2 ms). Where there are dynamic changes, Scan Type Header #1
describes the first part of the record, Scan Type Header #2 the second part, etc. Within the Scan Type Header, each
channel set descriptor is composed of a 96 byte field, and up to 65535 channel set descriptors may be present. In
addition, up to 99 scan type headers may be utilized in a record.
Following the channel set descriptors of a scan type are a number of 32 byte fields (SK, specified in byte 30 of General
Header #1) that specify sample skew. Sample skew (SS) is recorded in a single byte for each sample of each subscan of
each channel set, in the same order as the samples are recorded in the scan. Each byte represents a fractional part of the
base scan interval (Byte 23 of General Header #1). The resolution is 1/256 of this interval. For instance, if the base scan
interval is 2 msec, the least significant bit in the sample skew byte is 1/256 of 2 msec or 7.8125 microseconds.

A channel set is a group of channels that:
a) Use identical recording parameters. This includes the same record length and sampling interval.
b) Use identical processing parameters, including the same filter selection and array forming parameters.
c) Originates from the same streamer cable for marine data. The streamer cable number for each channel set is
included in the channel set descriptor byte 31.
d) Consists of channels with the same group spacing. For example, if one streamer has short group spacing close to
the boat and longer group spacing at long offsets, the data from the streamer would be recorded as two channel
sets. The first channel in each channel set will start with trace number one.
The following is a list of ground rules for the scan type header:
1. The order in which channel sets are described in the header will be the same as the order in which the data are
recorded for each channel set.
2. In a Scan Type Header containing multiple channel set descriptors with different sampling intervals, each channel
set descriptor will appear only once in each scan type header. Within the data block, however, shorter sampling
interval data are recorded more frequently.
3. In the case of multiple scan type records, such as the dynamically switched sampling interval case, each scan type
will contain the same number of channel sets. Any unused channel sets needed in a scan type must be so indicated
by setting bytes 21 to 23 (channels per channel set) to zero in the channel set descriptor.
4. In multiple scan type records, the number of bytes per base scan interval must remain a constant for all scan types
recorded.
5. Channels within the same Channel Set must now have the same number of Trace Header Extensions. Since all
traces within a Channel Set will contain the same number of Trace Header Extensions, the number of Trace
Header Extensions will be indicated in the Channel Set Descriptor. Byte 28 of the Channel Set Descriptor
contains the number of Trace Extension Headers in the channel set. This must match the byte 10 of the Demux
Trace Header of traces in the channel set. Each trace is hence limited to a maximum of 255 Trace Header
Extension blocks.
6. The length of each trace within a Channel Set is restricted to be the same value. This limitation and the restriction
of the number of Trace Header Extensions to the same number within a Channel Set will result in each trace
within a Channel Set being recorded with the same number of bytes.
5.3 Demux Trace Header (required)
The Demux Trace Header length is 20 bytes and is an identifier that precedes each channel’s data. The trace header and
the trace data are recorded as one block of data. A trace is restricted to one channel of data from one channel set of one
scan type. Some of the information in the trace header is taken directly from the general header and the scan type
header.
Bytes 7, 8, and 9 comprise the timing word that would accompany the first sample if these data were written in
multiplex format. To obtain the exact sample time, the actual sample skew time (Byte 11 multiplied by the base scan
interval) must be added to the time recorded in Bytes 7, 8, and 9.
The timing word is in milliseconds and has the following bit weight assignments:
Timing word

Bit 0 1 2 3 4 5 6 7
Byte 7 S 214 213 212 211 210 29 28
Byte 8 27 26 25 24 23 22 21 20
Byte 9 2−1 2−2 2−3 2−4 2−5 2−6 2−7 2−8
The timing word LSB (2−8) is equal to 1/256 msec, and the MSB (214) is equal to 16,384 msec with a sign bit to allow
negative timing words. The timing word for each scan is equal to the elapsed time from zero time to the start of that
scan. Timing words from 0 to 65535.9961 msec can be encoded. For longer recordings the timing word may overflow
to zero and then continue.
The first scan of data has typically started with timing word zero. However, this is not a requirement. In a sampling
system, it is not always practical to resynchronize the system even though most seismic data acquisition systems have to
date. Possible reasons for not wanting to resynchronize could be digital filtering, communication restrictions, etc.
Whether the system is resynchronized or not, the timing word will contain the time from the energy source event to the
start of scan of interest. For example, assume the sampling interval is 2 msec, the system does not resynchronize, and
the energy source event occurs 1 + 9/256 msec before the next normal start of scan. The timing word values would be:
First timing word 0 + 1 + 9/256 msec
Second 2 + 1 + 9/256 msec
Third 4 + 1 + 9/256 msec
Fourth 6 + 1 + 9/256 msec
… …
One-thousandth timing word 1998 + 1 + 9/256 msec
Byte 11 contains sample skew of the first sample of this trace. This is identical to the first byte of sample skew for this
channel in the Scan Type Header.
Bytes 13, 14, 15 are included as an integrity check on time break. They comprise the timing word of the scan in which
Time Break Window Indicator (TWI) changed to a one. Thus, it represents the time from the time break to the end of
the time break window. Random variations in this time indicate a problem in the fire control system. The presence of a
value less than the base scan interval indicates that time break was not detected and recording commenced at the end of
the time break window.
The definition of the timing word is kept the same between Rev 2.1 and Rev 3.0, even though the possible sample rates
have decreased to 1 microsec. The reason is that timing words are needed for historical reasons, and modern acquisition
systems supporting high sample rate data are assumed to use synchronization techniques not requiring the use of timing
word.
A Trace Header Extension may be added to include the receiver location for that trace. Receiver locations are defined
by a receiver line number (three integer bytes and two fraction bytes), a receiver point number (three bytes integer and
two bytes fraction) and a receiver point index (one byte). This index allows one to define the receiver group in the grid,
the original value being 1 and that value is incremented by 1 every time the receiver is moved, even when it is moved
back to the previous location. The reshoot index should be used to indicate a reacquisition of a previously acquired
trace, counting from 0, an increasing with 1 every time the trace is re-acquired. The group index is used to indicate that
the trace is part of a group that must be processed as a unit, e.g. rotation for multi-component data. The depth index is
used to support sensors in different vertical positions. Please refer to appendix E.6 for examples of use of indexes. The
Sensor Type (vertical geophone, hydrophone, etc.) may be indicated in Byte 21.
Additional trace header blocks (e.g. source information, positions, orientation blocks, or manufacturer defined blocks)
may be added as needed by the manufacturer or user. The maximum number of Trace Header Extensions is limited to
255.

A larger number of samples per trace may be recorded using bytes 25–28 of the first Trace Header Extension.
5.4 Extended Header (optional)
The Extended Header provides additional areas to be used by equipment manufacturers to interface directly with their
equipment. Since the nature of this data will depend heavily on the equipment and processes being applied, it will be the
responsibility of the equipment manufacturer to establish a format and document this area. Byte 31 of General Header
Block #1 contains the number of 32 byte fields in the Extended Header. If more than 99 Extended Header blocks are
used, then General Header Block #1, byte 31 is set to FF16 and bytes 6 to 8 in the General Header Block #2 indicate the
number of Extended Header Blocks.
5.5 External Header (optional)
The External Header provides a means of recording special user-desired information in the header block. This data
format will be defined and documented by the end user. The means of putting this information into the header has
usually been provided by the equipment manufacturer. Byte 32 of General Header Block #1 contains the number of 32
byte fields in the external header. If more than 99 External Header blocks are used, then General Header Block #1, Byte
32 is set to FF16 and Bytes 28 to 30 of General Header Block #2 indicates the number of External Header blocks.
5.6 General Trailer (optional)
Following the seismic data, a General Trailer may be recorded. This provides for recording auxiliary system and
navigation related data. The addition of the trailer will allow the accumulation of system faults, data QC information,
real-time navigation position, and timing information on the same record and contiguous with the shotpoint to which it
relates. By recording this data after all of the other data, additional time is provided for collecting the data and
transferring it to the recording system. The General Trailer consists of a set of blocks consisting of a short header
followed by a number of data blocks. All information in the General Trailer is optional, and each block may be
formatted as desired by the manufacturer or user. The number of General Trailer blocks is indicated in bytes 13 to 16 of
General Header Block #2.
To aid with the transfer of information between acquisition and processing, a few types of trailer blocks have been
defined:
1. Edits
2. Navigation data backup
3. Text comments
4. Observer log
We recommended using these standard formats when inserting this type of information in the trailer.
Note: All types of trailer records are optional.
5.6.1 Edit (SEG-D Trace Edit v1.0)

Block Type (byte 1) is set to 0116, ASCII/binary (byte 2) set to 0216 and Description (byte 9–24) set to
"TRACE EDIT v1.0 ".

The edits trailer allows the recorder to modify the trace information provided by the trace header in the record. This is
typically used to indicate problems with certain traces. Edits trailer blocks are typically generated post acquisition, during
the QC and processing stages. SEG-D Rev 3 allows multiple Edit trailer blocks to be defined. The information in later
Edit blocks overrides information in earlier blocks.
The format presented here is similar to the one described in [SEG ADS Trace Edit, Norris, Hares, Faichney, 2001, SEG-
UKOOA Ancillary Data Standard - ADS Trace Edit: Geophysics, 66, no. 06, 2040–2054], though some
modifications/simplifications have been done. The SEG ADS Trace Edit format is very flexible, and some adaptation
must be done to make it fit the SEG-D record structure. In addition, the format of some fields had to be more strictly
defined to enable automatic parsing of the format.
It is recommended that the recording system creates Edit records to indicate which traces are bad, even though this is also
indicated in the trace headers. This will give a quick overview of the shot without the need for scanning through all the
data, and will simplify importing of data into processing/QC systems.
Multiple Edit records may exist. The latter will override prior definitions.
The edit format is ASCII, to ease human readability.
The format consists of multiple lines, each line terminated with a newline terminator consisting of a Line Feed ('\n', 0A16)
or Carriage Return/LineFeed ("\r\n", 0D0A16).
From here on, <LF> is used to indicate newline, <space> to indicate the space character (2016).
Each line (record) consists of a record description letter followed by space (2016), then some ASCII text, and terminated
by linefeed.
<Record function><space>ASCII text><LF>
The Edit block is padded with <space> until a multiple of 32 byte is reached.
Class Record Function Description

Character
Header V SEG-D Trace Edit version (required)
Header C Comment
Header S Timestamp, UTC (required)
Header System/person to generate this edit
W
(required)
Header A Attribute definition and range (at least one
A record is required)
Header P Parameters for attribute, if one line is not
enough to describe the attribute (optional)
Header H Header, description of a test (required)
Header R Range of traces tested. A test may not be
applicable to all traces. If not present, all
traces are tested. (optional)
Header Y Severity of exclusion. If not present, trace
is to be removed (not to be processed)

Class Record Function Description
Character
(Optional)
Primary Key Record X Exclude these trace ranges. May be several
for each header.
Primary Key Record I Include these trace ranges. May be several
for each header. I records may be used to
override X record settings (though this is
considered bad practice).
Terminator E End of Header/Primary Key record pair (at
least one E record is required)
Terminator T End of SEG-D Trace Edit dataset (one and
no more than one T record is required)
An edit record will consist of a header (V/S/W/C records), then for each test H/A/P/Y/R/X/I/E/C and optionally S/W if the
test was performed in another system/at another time.
The format of all fields are defined by the recorder, except V/S/Y/R/X/I. However there are three requirements:
o System recognition: All systems must be able to determine which traces have been edited, when, by who, and how
serious the edit is.
o System regeneration: The system creating the edit must be capable of parsing the edit, and recreate the test based
on the information in the edit records. No other information must be required.
o Human readability: The edits should be human readable. Use C records if the system generated text is not
enough.
Format of fields
SEG-D Trace Edit version

Format:
V<space>SEGD Trace Edit v<major>.<minor><LF>
This version of trace edit is 1.0.
Example:
V SEGD Trace Edit v1.0
Time stamp
This is the time of the edit Timestamp in UTC, accuracy 1 second.
Format:
S<space><hour>:<minute>:<second> <monthday>-<month three letter
abbreviation>-<year 4 digits><LF>
Example:
S 13:35:00 23-MAR-2007
Severity of exclusion
What to do with the trace failing the test described in the A record.
Y<space><severity><LF>

The following severities exist:
o EXCLUDE - The traces listed in X record should be excluded from further processing (default)
o WARNING - The traces listed in X records are suspicious, and further investigation is recommended.
Example:
Y WARNING
Y EXCLUDE
Trace range definition

Used to define ranges of traces to test (R), include (I) or exclude (X).
Format:
<record letter><space><scanset NUMBER LIST;<channelset NUMBER LIST>;<trace
NUMBER LIST><LF>
NUMBER LIST is a comma separated list of numbers, or ranges. For example 1,4,10–14 means numbers 1, 4,
and 10 through 14.
Example:
R 1-1,5-14,1-558
X 1-1,5-14,1-5
I 1-1,8-11,5-5
The ranges checked are traces 1–558 in channel sets 5–14 (e.g. the seismic channel sets for a 10 streamer vessel).
X record states traces 1–5 on all streamers fails the test (e.g. due to noise), but I record overrides, and indicates
channel 5 in channel set 8–11 passed.
See Appendix E.7 for a complete example of a Trace Edit v1.0 block.
5.6.2 Navigation data backup

Trailer block used as a backup of navigation related information. The contents is defined by the following table
Contents Block type ASCII/ Description

binary
P1 processed navigation data 2016 0216 (ASCII) “P1 FILE FORMAT ”
P2 Raw marine positioning data 2116 0216 (ASCII) “P2 FILE FORMAT ”
P3 Land survey field data 2216 0216 (ASCII) “P3 File Format ”
P5 Pipeline positioning data 2316 0216 (ASCII) “P5 FILE FORMAT ”
P6 3D seismic binning grids 2416 0216 (ASCII) “P6 FILE FORMAT ”
P7 Well deviation data 2516 0216 (ASCII) “P7 FILE FORMAT ”
SPS Shell Processing Support data 2616 0216 (ASCII) “SPS FILE FORMAT ”
SEG-Y Extended Textual Stanza 2716 0216 (ASCII) “SEGY TEXT STANZA”
A whole file is added in a trailer block as described above. If multiple files need backing up, several trailer blocks may be
added.
5.6.3 Text Comment

Block Type (byte 1) is set to 1016, ASCII/binary (byte 2) set to 0216 and Description (bytes 9–24) set to
"TEXT COMMENT ".
This trailer block contains any user defined, textual comment belonging to the SEG-D record. May be multiple lines, each
line terminated with Line Feed ('\n', 0A16), or optionally Carriage Return/LineFeed ("\r\n", 0D0A16).

Multiple text comments may exist.
Text comments are padded with spaces (2016) until a multiple of 32 bytes is reached.
5.6.4 Observer log

Block Type (byte 1) is set to 1116, ASCII/binary (byte 2) set to 0216 and Description (bytes 9–24) set to
"OBSERVER LOG ".
This is the observer log entry for this record. The format is textual.
Observer logs are padded with spaces (2016) until a multiple of 32 bytes is reached.
5.6.5 User defined

The contents of the user defined block is completely left to the recording system, however the size must be a multiple of
32 bytes. The format is textual or binary as defined by the ASCII/binary flag in the description block. Byte 1 should be set
to a value between A016 and FF16.

6.0 Data Body
Data is recorded as a byte stream in demultiplexed format. Preceding each trace of data is a trace header, a trace header
extension #1 and optional trace header extensions. Each trace is a sequential set of samples from one channel in one
channel set.
6.1 Data Recording Method
To accommodate diverse recording needs, the data recording allows sample representations of 8, 16, 20, 24, 32, and 64
bits.
The data word is a numeric representation of the sign and magnitude of the instantaneous voltage presented to the
system. It is not an indication of how the hardware gain system functions. The output of stepped gain systems may be
represented as a binary mantissa and a binary exponent of base 2, 4, or 16 (binary, quaternary, or hexadecimal system)
or a simple integer value. Depending upon the particular recording method, the mantissa or integer may be represented
as a sign-magnitude, one’s complement, or two’s complement binary value. In a sign-magnitude representation, the
initial bit is set to 1 if the value is the negative of the number represented by the remaining bits and 0 otherwise. A
one’s complement binary value is the same as sign-magnitude for nonnegative numbers but all the bits are flipped
(XOR’ed with 1’s) to represent negative values. A nonnegative value in two’s complement representation is also the
same as sign-magnitude, but negative numbers are represented by first flipping all the bits and then adding 1. If a two’s
complement number has n bits, then its value can be determined by first adding 2n−1, taking the result modulo 2n, and
finally subtracting 2n−1.
Following are descriptions of each of the data recording methods permitted. The same number system is to be used on
all samples in a record, including auxiliary and all other types of channels. All recording methods are valid for
demultiplexed records; as of Rev 1 SEG-D no longer supports multiplexed data.
1 byte quaternary exponent data recording method

The following illustrates the 8 bit word and the corresponding bit weights:
Bit 0 1 2 3 4 5 6 7
Byte 1 S C2 C1 C0 Q−1 Q−2 Q−3 Q−4
S=sign bit. —(One = negative number).
C=quaternary exponent.—This is a three bit positive binary exponent of 4 written as 4CCC where CCC can assume
values from 0–7.
Q−1-4 fraction.—This is a 4 bit one’s complement binary fraction. The radix point is to the left of the most significant bit
(Q−1) with the MSB being defined as 2−1. The fraction can have values from −1+2−4 to 1−2−4.
Input signal = S.QQQQ × 4CCC × DSM millivolts where DSM is the value required to descale the data sample to the
recording system input level. DSM is defined in Bytes 17–20 of each channel set descriptor in the scan type header.
2 byte quaternary exponent data recording method

The following illustrates the 16-bit word and the corresponding bit weights:
Bit 0 1 2 3 4 5 6 7
Byte 1 S C2 C1 C0 Q−1 Q−2 Q−3 Q−4
Byte 2 Q−5 Q−6 Q−7 Q−8 Q−9 Q−10 Q−11 Q−12

S=sign bit.—(One = negative number).
C=quaternary exponent.—This is a three bit positive binary exponent of 4 written as 4CCC where CCC can assume
values from 0–7.
Q−1-12 fraction.—This is a 12 bit one’s complement binary fraction. The radix point is to the left of the most significant
bit (Q−1) with the MSB being defined as 2−1. The fraction can have values from −1 + 2−12 to 1 − 2−12.
Input signal = S.QQQQ,QQQQ,QQQQ × 4CCC × DSM millivolts where DSM is the value required to descale the data
sample to the recording system input level. DSM is defined in Bytes 17–20 of each channel set descriptor in the scan
type header.
2½ byte binary exponent data recording method—demultiplexed

The following illustrates the 20 bit word and the corresponding bit weights:
Bit 0 1 2 3 4 5 6 7
Byte 1 C3 C2 C1 C0 C3 C2 C1 C0 Exponents for
Byte 2 C3 C2 C1 C0 C3 C2 C1 C0 samples 1 thru 4†
Byte 3 S Q−1 Q−2 Q−3 Q−4 Q−5 Q−6 Q−7 Sample 1
Byte 4 Q−8 Q−9 Q−10 Q−11 Q−12 Q−13 Q−14 Q−15
Byte 6 Q−8 Q−9 Q−10 Q−11 Q−12 Q−13 Q−14 Q−15
Byte 8 Q−8 Q−9 Q−10 Q−11 Q−12 Q−13 Q−14 Q−15
Byte 10 Q−8 Q−9 Q−10 Q−11 Q−12 Q−13 Q−14 Q−15
†
Bytes 1 and 2 contain the exponents for the following four samples of the channel. The sample numbers are relative
and are only to denote position in the four sample group.
S=sign bit—(One = negative number).
C=binary exponent—This is a 4 bit positive binary exponent of 2 written as 2CCCC where CCCC can assume values of
0–15. The four exponents are in sample order for the four samples starting with the first sample in bits 0–3 of Byte 1.
Q−1-15 fraction—This is a 15 bit one’s complement binary fraction. The radix point is to the left of the most significant
bit (Q−1) with the MSB being defined as 2−1. The sign and fraction can assume values from 1 – 2−15 to –1 + 2−15.
Input signal=S.QQQ,QQQQ,QQQQ,QQQQ × 2CCCC × DSM millivolts where DSM is the value required to descale the
data word to the recording system input level. DSM is defined in Bytes 17–20 of each of the corresponding channel set
descriptors in the scan type header.

Note that in utilizing this data recording method, the number of samples per channel must be exactly divisible by 4 in
order to preserve the data grouping of this method.
1 byte hexadecimal exponent data - recording method

Bit 0 1 2 3 4 5 6 7
Byte 1 S C1 C0 Q−1 Q−2 Q−3 Q−4 Q−5
C=hexadecimal exponent.—This is a two positive binary exponent of 16 written as 16CC where CC can assume values
from 0–3.
Q−1-5 fraction—This is a 5 bit positive binary fraction. The radix point is to the left of the most significant bit (Q−1) with
the MSB being defined as 2−1. The sign and fraction can have any value from –1 + 2−5 to 1 – 2−5.
Input signal= (−1)S × 0.Q,QQQQ × 16CC × DSM millivolts where DSM is the value required to descale the data sample
to the recording system input level. DSM is defined in Bytes 17–20 of each channel set descriptor in the scan type
header.

Bit 0 1 2 3 4 5 6 7
Byte 1 S C1 C0 Q−1 Q−2 Q−3 Q−4 Q−5
Byte 2 Q−6 Q−7 Q−8 Q−9 Q−10 Q−11 Q−12 Q−13
C=hexadecimal exponent.—This is a two bit positive binary exponent of 16CC where CC can assume values from 0–3.
Q−1-13 fraction—This is a 13 bit positive binary fraction. The radix point is to the left of the most significant bit (Q −1)
with the MSB being defined as 2−1. The sign and fraction can have any value from –1 + 2−13 to 1 – 2−13.
Input signal = (−1)S × 0.Q,QQQQ,QQQQ,QQQQ × 16CC × DSM millivolts where DSM is the value required to descale
the data sample to the recording system input level. DSM is defined in Bytes 17–20 of each channel set descriptor in
the scan type header.

Bit 0 1 2 3 4 5 6 7
Byte 2 Q−1 Q−2 Q−3 Q−4 Q−5 Q−6 Q−7 Q−8
Byte 3 Q−9 Q−10 Q−11 Q−12 Q−13 Q−14 Q−15 Q−16
Byte 4 Q−17 Q−18 Q−19 Q−20 Q−21 Q−22 Q−23 Q−24
C=excess 64 hexadecimal exponent.—This is a binary exponent of 16. It has been biased by 64 such that it represents
16(CCCCCCC−64) where CCCCCCC can assume values from 0 to 127.
Q−1-24 magnitude fraction.—This is a 24 bit positive binary fraction (i.e., the number system is sign and magnitude).
The radix point is to the left of the most significant bit (Q−1) with the MSB being defined as 2−1. The sign and fraction
can assume values from (1 – 2−24 to –1 + 2−24). It must always be written as a hexadecimal left justified number. If this
fraction is zero, the sign and exponent must also be zero (i.e., the entire word is zero.)
Input signal = (−1)S × 0.QQQQ,QQQQ,QQQQ,QQQQ,QQQQ,QQQQ × 16(CCCCCCC−64) × DSM millivolts where DSM is
the value required to descale the data sample to the recording system input level. DSM is defined in Bytes 17–20 of
each channel set descriptor in the scan type header. This data recording method has more than sufficient range to
handle the dynamic range of a typical seismic system. Thus, DSM may not be needed to account for any scaling and
may be recorded as 1.0.
4 byte IEEE floating point data - recording method
The IEEE (Institute of Electrical and Electronics Engineers) format is fully documented in the IEEE standard,
"ANSI/IEEE Std 754 - l985", available from the IEEE (http://ieeexplore.ieee.org/servlet/opac?punumber=2355).
Bit 0 1 2 3 4 5 6 7
Byte 2 C0 Q−1 Q−2 Q−3 Q−4 Q−5 Q−6 Q−7
Byte 3 Q−8 Q−9 Q−10 Q−11 Q−12 Q−13 Q−14 Q−15
Byte 4 Q−16 Q−17 Q−18 Q−19 Q−20 Q−21 Q−22 Q−23

if e = 255 & f = 0. .v = (−1)s ×  Overflow
if 0 < e < 255 . . . . .v = (−1)s × 2e−127 × (1.f) Normalized
if e = 0 & f ≠ 0. . . .v = (−1)s × 2e−126 × (0.f) Denormalized
if e = 0 & f = 0. . . .v = (−1)s × 0 ± zero
NOTE 1. A Not-a-Number (NaN) is interpreted as an invalid number. All other numbers are valid and
interpreted as described above.
Input signal = v × DSM millivolts where DSM is the value required to descale the data sample to the recording system
input level. DSM is defined in Bytes 17–20 of each channel set descriptor in the scan type header. This data recording
method has more than sufficient range to handle the dynamic range of a typical seismic system. Thus, DSM may not be
needed to account for any scaling and may be recorded as 1.0.

8 byte IEEE floating point data – recording method
The IEEE (Institute of Electrical and Electronics Engineers) format is fully documented in the IEEE standard,
"ANSI/IEEE Std 754 - l985", available from the IEEE (http://ieeexplore.ieee.org/servlet/opac?punumber=2355).
Bit 0 1 2 3 4 5 6 7
Byte 1 S C11 C10 C9 C8 C7 C6 C5
Byte 2 C4 C3 C2 C1 Q−1 Q−2 Q−3 Q−4
Byte 3 Q−5 Q−6 Q−7 Q−8 Q−9 Q−10 Q−11 Q−12
Byte 4 Q−13 Q−14 Q−15 Q−16 Q−17 Q−18 Q−19 Q−20
Byte 5 Q−21 Q−22 Q−23 Q−24 Q−25 Q−26 Q27 Q−28
Byte 6 Q−29 Q−30 Q−31 Q−32 Q−33 Q−34 Q−35 Q−36
Byte 7 Q−37 Q−38 Q−39 Q−40 Q−41 Q−42 Q−43 Q−44
Byte 8 Q−45 Q−46 Q−47 Q−48 Q−49 Q−50 Q−51 Q−52

if e = 2047 & f = 0. .v = (−1)s ×  Overflow (infinity)
if 0 < e < 2047. . . . . v = (−1)s × 2e−1023 × (1.f) Normalized
if e = 0 & f ≠ 0. . . . .v = (−1)s × 2e−1022 × (0.f) Denormalized
if e = 0 & f = 0. . . . .v = (−1)s × 0 ± zero
NOTE 1. A Not-a-Number (NaN) is interpreted as an invalid number. All other numbers are valid and interpreted as
described above.
Input signal = v × DSM millivolts where DSM is the value required to descale the data sample to the recording system
input level. DSM is defined in Bytes 17–20 of each channel set descriptor in the scan type header. This data
recording method has more than sufficient range to handle the dynamic range of a typical seismic system. Thus,
DSM may not be needed to account for any scaling and may be recorded as 1.0.
Integer formats:
24 bit two’s complement format:
Bit 0 1 2 3 4 5 6 7
Byte 1 I23 I22 I21 I20 I19 I18 I17 I16

Byte 2 I15 I14 I13 I12 I11 I10 I9 I8
Byte 3 I7 I6 I5 I4 I3 I2 I1 I0
Input signal = { (IIII,IIII,IIII,IIII,IIII,IIII + 223) mod 224 – 223 } × DSM millivolts where DSM is the value required to
descale the data sample to the recording system input level. DSM is defined in Bytes 17–20 of each channel set
descriptor in the scan type header.
32 bit two’s complement format:

Bit 0 1 2 3 4 5 6 7
Byte 1 I31 I30 I29 I28 I27 I26 I25 I24
Byte 2 I23 I22 I21 I20 I19 I18 I17 I16
Byte 3 I15 I14 I13 I12 I11 I10 I9 I8
Byte 4 I7 I6 I5 I4 I3 I2 I1 I0
Input signal = { (IIII,IIII,IIII,IIII,IIII,IIII,IIII,IIII + 2 31) mod 232 – 231 } × DSM millivolts where DSM is the value
required to descale the data sample to the recording system input level. DSM is defined in Bytes 17–20 of each channel
set descriptor in the scan type header.
6.2 DSM Factor calculation and physical unit
The Descale multiplier (DSM) parameter is provided to allow the dimensionless numbers recorded on tape to be
“descaled” back to the instantaneous sample values in millivolts at the system inputs*). As of Rev 3, DSM is stored in
bytes 17–20 of the Channel Set Descriptor in the Scan Type Header as a 4 byte IEEE floating point number. Prior to
that it was computed from an MP exponent stored in byte 8 of the Channel Set Descriptor.
In general, recording systems scale the input signal level in order to match the useful range of input levels to the gain-
ranging amplifier. DSM must account for all scaling in the acquisition system. However, in some high resolution
formats like the 4 byte hexadecimal, or 4 or 8 byte IEEE floating point cases, the data recording method may have
sufficient range, and the DSM may be set to 1.0.
*) In several instances “sample values in millivolt at system inputs” may be unclear. Modern acquisition systems offten
perform several stages of digital processing before the data samples are stored, and in many cases, especially for
auxillary data, millivolt samples may not even be applicable at all. In these situations the recorder should follow the
general advice above, and just make sure the dynamic range of the sample values matches the useful range of the input
levels. In addition it is also highly recommended to store sensor sensitivity (in a Sensor Info Header extension block as
part of the Trace Header), to ensure the sample value can be converted to a physical unit.
Physical unit conversion

To be able to relate the seismic traces to external events it may be needed to convert the millivolt values in the traces to
the physical unit. The physical unit of the traces is listed in byte 62 of the Channel Set Descriptor. This is repeated in
byte 31 of Trace Header Extension block. The sensor sensitivity (Sensor Info Header Extension bytes 9–12, 4 byte IEEE
float) is multiplied with the millivolt sample value to calculate the physical unit number.
The following equation converts a trace sample value to a physical unit sample value
Vp = Vt * DSM * SS
Vp - Physical sample value
Vt - Trace sample value
DSM - Multiplication factor to convert to millivolt value
SS - Sensor sensitivity
The type of the physical unit are listed in the table found Chapter 8, Trace Header Extension, byte 31 definition. Typical
types are millibar (e.g. hydrophone data), millimeters/second (e.g. geophone data) or meters (e.g. depth measurement).
DSM may be written
DSM = 2MP
The calculation of MP for a data recording method is given by one of the following equations:
For floating point data:
1. MP = FS – PA – Cmax For binary exponents.
2. MP = FS – PA – 2 × Cmax For quaternary exponents.
3. MP = FS – PA – 4 × Cmax For hexadecimal exponents (except for the four byte excess 64
method).
4. MP = FS – PA – 4 × (Cmax – 64) For excess 64 hexadecimal exponents.
5. MP = FS – PA – (Cmax – 127) For 32 bit IEEE exponents.
6. MP = FS – PA – (Cmax – 1023) For 64 bit IEEE exponents.
Where:
Cmax = maximum value of the data exponent;
Cmax =
15 for binary exponents
7 for quaternary exponents,
3 for hexadecimal exponents, except excess 64,
127 for excess 64 exponents and the output of the analog-to-digital converter is
written as the fractional portion of the data value.
255 for 32 bit IEEE exponents and the output of the analog-to-digital converter is
2047 for 64 bit IEEE exponents and the output of the analog-to-digital converter is
For integer data:

1. MP = FS − PA − IS;
Where:
2IS–1 = Integer number system positive full scale, and
the output of the analog-to-digital converter is written as an integer.

The term “minimum system gain” includes preamplifier gain and the minimum floating point amplifier gain. For
example, one system may use a preamplifier gain of 256 and a minimum floating point amplifier gain of one. The
minimum system gain is 256 x 1 = 28, so PA = 8. Another system may use a preamplifier gain of 320 and a minimum
floating point amplifier gain of 0.8. In this case, the minimum system gain is 320 x 0.8 = 256 or 28. Again PA = 8.
PA may also account for any amplification needed to accommodate an analog to digital converter with a full scale value
that is not a power of 2 in millivolts. For example, a 10 V (10,000 mV) converter may be preceded by an amplifier with
a gain of 1.221 (10,000/8,192). This gain may be accounted for in PA. Alternatively, it could be considered part of the
converter, making it appear to have a binary full scale.
Justifications for the Equations
The output of the analog-to-digital converter is written as the fractional portion of the data value. This is equivalent to
dividing the value by the full scale of the converter. In order to compensate for this, the data value recorded on tape
must be multiplied by the full scale value of the converter (2FS). Thus FS appears in equations (1)–(4) with a positive
sign.
The input signal was multiplied by the minimum system gain (2PA) which, as mentioned, includes any preamplifier gain,
minimum floating point amplifier gain, or analog-to-digital converter adjustment gain. The data recorded on tape must
be divided by this minimum system gain; thus, PA appears in the equations with a negative sign.
Large input signals converted at minimum floating point amplifier gain are written on tape with the maximum exponent
for the data recording method used. Likewise, small signals converted at full gain are written with the maximum
exponent. The data as written have been multiplied by the exponent base raised to Cmax (minus 64, 127, or 1023 as
appropriate to the number format.) Thus Cmax appears in the equations with a negative sign. MP is a power of 2 so the
quaternary and hexadecimal Cmax values are multiplied by 2 and 4, respectively (4c = 22c and 16c = 24c).
Data processing done prior to data storage.

In modern recording systems significant data processing is commonly done prior to storing the data on tape. The DSM
factor may have to be adapted to make sure the number resolution is maintained in the trace data, i.e. the processing
scaling parameters must be incorporated in the DSM factor.
6.3 Sensor calibration
Trace Header frequency domain calibration

SEGD supports storing individual sensor calibration values in Trace Header Extension blocks (see Sensor Calibration
Header)”. Each 32 byte Sensor Calibration Header block contains two frequency/amplitude/phase groups, and multiple
blocks may be used to define the complete frequency domain calibration function for the sensor. Sensor Calibration
Header block allows a maximum of about 500 frequencies per trace, assuming no other meta-information exist in the trace
header
The calibration corrected sensor value is achieved by converting the time series trace value to frequency domain, and
multiplying with the calibration function
Vcalibrated = Fc . Vtrace
Where
Vcalibrated = Calibration corrected trace signal (in frequency domain)
Fc = Sensor calibration transfer function as described by the values in the sensor calibration header.
Vtrace = The uncorrected trace value (in frequency domain)

The sensor calibration values in addition to the individual Sensor Sensitivity values can be used to correct for most sensor
variations needed to achieve a high fidelity signal needed in modern seismic acquisition systems.
Calibration Channel – time domain

A Calibration Channel Set can be used if time series calibration is preferred. The Calibration Channel Set also allows a
more high fidelity calibration compared to the Trace Header Extension blocks. The frequency and length of the calibration
channel may be adjusted to achieve the accuracy required. Calibration Channel Sets has Channel type set to F016 in
Channel Set Descriptor byte 4. The Calibration Channel is a time series signal that can be correlated with the trace value
to achieve a calibrated trace signal. By converting both the trace and calibration trace time series to frequency domain, the
formula shown above can be used. The indices in the Trace Header Extension block determine which trace the calibration
trace applies to.

7.0 Header Tables
Note:
Several blocks contain undefined fields, indicated by X in the tables. These values are undefined by the format, and may
be used by the manufacturer to store manufacturer defined information. However, be aware that the fields may be used in
future versions of the format, and the manufacturer use these fields at own risk. It is recommended to record ‘0’ in fields
indicated by X, and store all manufacturer defined information in user defined header blocks (External or Extended
header, General Trailer blocks, or General Header/Trace Header blocks with ID B016 through FF16 ). These will more
likely to be compliant with future versions of the format.
7.1 GENERAL HEADER BLOCK #1
Bit No. 0 1 2 3 4 5 6 7
BCD Value MSD 8 4 2 1 8 4 2 1 LSD
Binary Value MSB 128 64 32 16 8 4 2 1 LSB
File Number F1 F1 F1 F1 F2 F2 F2 F2 1
F3 F3 F3 F3 F4 F4 F4 F4 2
Format Code Y1 Y1 Y1 Y1 Y2 Y2 Y2 Y2 3
Y3 Y3 Y3 Y3 Y4 Y4 Y4 Y4 4
General Constants K1 K1 K1 K1 K2 K2 K2 K2 5
K3 K3 K3 K3 K4 K4 K K4 6
K5 K5 K5 K5 K6 K6 K6 K6 7
K7 K7 K7 K7 K8 K8 K8 K8 8
K9 K9 K9 K9 K10 K10 K10 K10 9
K11 K11 K11 K11 K12 K12 K12 K12 10
Year YR1 YR1 YR1 YR1 YR2 YR2 YR2 YR2 11
# Additional Blks in GH3 GH2 GH1 GH0 DY1 DY1 DY1 DY1 12
Gen Hdr
Day (DY) DY2 DY2 DY2 DY2 DY3 DY3 DY3 DY3 13
Hour H1 H1 H1 H1 H2 H2 H2 H2 14
Minute MI1 MI1 MI1 MI1 MI2 MI2 MI2 MI2 15
Second SE1 SE1 SE1 SE1 SE2 SE2 SE2 SE2 16
Manufacture’s Code M1 M1 M1 M1 M2 M2 M2 M2 17
M3 M3 M3 M3 M4 M4 M4 M4 18
M5 M5 M5 M5 M6 M6 M6 M6 19
0 0 0 0 0 0 0 0 20
0 0 0 0 0 0 0 0 21
0 0 0 0 0 0 0 0 22
Base Scan Interval I3 I2 I1 I0 I−1 I−2 I−3 I−4 23
Polarity (P) P P P P 0 0 0 0 24
0 0 0 0 0 0 0 0 25
Record Type (Z) Z Z Z Z R1 R1 R1 R1 26
Record Length (R) R2 R2 R2 R2 R3 R3 R3 R3 27
Scan Types/Record ST/R1 ST/R1 ST/R1 ST/R1 ST/R2 ST/R2 ST/R2 ST/R2 28
Chan Sets/Scan Type CS1 CS1 CS1 CS1 CS2 CS2 CS2 CS2 29
Skew Blocks SK1 SK1 SK1 SK1 SK2 SK2 SK2 SK2 30
Extended Header Blk EC1 EC1 EC1 EC1 EC2 EC2 EC2 EC2 31
External Header Blk EX1 EX1 EX1 EX1 EX2 EX2 EX2 EX2 32

Bit No. 0 1 2 3 4 5 6 7
Expanded File EF23 EF22 EF21 EF20 EF19 EF18 EF17 EF16 1
Number
EF15 EF14 EF13 EF12 EF11 EF10 EF9 EF8 2
Extended Channel Sets/ EN15 EN14 EN13 EN12 EN11 EN10 EN9 EN8 4
Scan Type
EN7 EN6 EN5 EN4 EN3 EN2 EN1 EN0 5
Extended Header Blks ECX23 ECX22 ECX21 ECX20 ECX19 ECX18 ECX17 ECX16 6
ECX15 ECX14 ECX13 ECX12 ECX11 ECX10 ECX9 ECX8 7
ECX7 ECX6 ECX5 ECX4 ECX3 ECX2 ECX1 ECX0 8
Extended Skew blks ESK15 ESK14 ESK13 ESK12 ESK11 ESK10 ESK9 ESK8 9
ESK7 ESK6 ESK5 ESK4 ESK3 ESK2 ESK1 ESK0 10
SEG-D Revision No. RMJ7 RMJ6 RMJ5 RMJ4 RMJ3 RMJ2 RMJ1 RMJ0 11
“major” and “minor” RMN7 RMN6 RMN5 RMN4 RMN3 RMN2 RMN1 RMN0 12
General Trailer, GT31 GT30 GT29 GT28 GT27 GT26 GT25 GT24 13
Number of Blks GT23 GT22 GT21 GT20 GT19 GT18 GT17 GT16 14
GT15 GT14 GT13 GT12 GT11 GT10 GT9 GT8 15
GT7 GT6 GT5 GT4 GT3 GT2 GT1 GT0 16
Extended Record ERL31 ERL30 ERL29 ERL28 ERL27 ERL26 ERL25 ERL24 17
Length ERL23 ERL22 ERL21 ERL20 ERL19 ERL18 ERL17 ERL16 18
ERL15 ERL14 ERL13 ERL12 ERL11 ERL10 ERL9 ERL8 19
ERL7 ERL6 ERL5 ERL4 ERL3 ERL2 ERL1 ERL0 20
Record Set Number SN15 SN14 SN13 SN12 SN11 SN10 SN9 SN8 21
SN7 SN6 SN5 SN4 SN3 SN2 SN1 SN0 22
Extended # Additional EGH15 EGH14 EGH13 EGH12 EGH11 EGH10 EGH9 EGH8 23
Blks in Gen Hdr EGH7 EGH6 EGH5 EGH4 EGH3 EGH2 EGH1 EGH0 24
Dominant Sampling BSI23 Sample
BSI22 BSI21 BSI20 BSI19 BSI18 BSI17 BSI16 25
Interval BSI15 BSI14 BSI13 BSI12 BSI11 BSI10 BSI9 BSI8 26
BSI7 BSI6 BSI5 BSI4 BSI3 BSI2 BSI1 BSI0 27
External Header Blks EH23 EH22 EH21 EH20 EH19 EH18 EH17 EH16 28
EH15 EH14 EH13 EH12 EH11 EH10 EH9 EH8 29
EH7 EH6 EH5 EH4 EH3 EH2 EH1 EH0 30
X X X X X X X X 31
Header Block Type 0 0 0 0 0 0 1 0 32

7.3 GENERAL HEADER BLOCK #3 (Timestamp and size header)
Bit No. 0 1 2 3 4 5 6 7
Time Zero TZ63 TZ62 TZ61 TZ60 TZ59 TZ58 TZ57 TZ56 1
TZ55 TZ54 TZ53 TZ52 TZ51 TZ50 TZ49 TZ48 2
Record Size RS63 RS62 RS61 RS60 RS59 RS58 RS57 RS56 9
RS55 RS54 RS53 RS52 RS51 RS50 RS49 RS48 10
Data Size DS63 DS62 DS61 DS60 DS59 DS58 DS57 DS56 17
DS55 DS54 DS53 DS52 DS51 DS50 DS49 DS48 18
Header Size HS31 HS30 HS29 HS28 HS27 HS26 HS25 HS24 25
HS23 HS22 HS21 HS20 HS19 HS18 HS17 HS16 26
Extd Rec Mode ERM7 ERM6 ERM5 ERM4 ERM3 ERM2 ERM1 ERM0 29
Rel Time Mode RTM7 RTM6 RTM5 RTM4 RTM3 RTM2 RTM1 RTM0 30
X X X X X X X X 31
7.4 GENERAL HEADER BLOCK #4 (Vessel/Crew Identification) (optional)
Bit No. 0 1 2 3 4 5 6 7
Abbr Vessel or VCA VCA VCA VCA VCA VCA VCA VCA 1
Crew Name VCA VCA VCA VCA VCA VCA VCA VCA 2
VCA VCA VCA VCA VCA VCA VCA VCA 3
Vessel or Crew VC VC VC VC VC VC VC VC 4
Name VC VC VC VC VC VC VC VC 5

VC VC VC VC VC VC VC VC 6
7.5 GENERAL HEADER BLOCK #5 (Survey Area Name) (optional)
Bit No. 0 1 2 3 4 5 6 7
Survey Area Name SAN SAN SAN SAN SAN SAN SAN SAN 1
SAN SAN SAN SAN SAN SAN SAN SAN 2

7.6 GENERAL HEADER BLOCK #6 (Client Identification) (optional)
Bit No. 0 1 2 3 4 5 6 7
Client Identification CI CI CI CI CI CI CI CI 1
CI CI CI CI CI CI CI CI 2

7.7 GENERAL HEADER BLOCK #7 (Job identification) (optional)
Bit No. 0 1 2 3 4 5 6 7
Abbr Job JIA JIA JIA JIA JIA JIA JIA JIA 1
Identification JIA JIA JIA JIA JIA JIA JIA JIA 2
JIA JIA JIA JIA JIA JIA JIA JIA 3
Job Identification JI JI JI JI JI JI JI JI 6
JI JI JI JI JI JI JI JI 7

7.8 GENERAL HEADER BLOCK #8 (Line identification) (optional)
Bit No. 0 1 2 3 4 5 6 7
Line Abbreviation LA LA LA LA LA LA LA LA 1
LA LA LA LA LA LA LA LA 2
Line Identification LI LI LI LI LI LI LI LI 8
LI LI LI LI LI LI LI LI 9
7.9 SOURCE DESCRIPTION BLOCK (optional)

7.9.1 VIBRATOR
Bit No. 0 1 2 3 4 5 6 7
Expanded File No. EF23 EF22 EF21 EF20 EF19 EF18 EF17 EF16 1
Source Line No. SLN23 SLN22 SLN21 SLN20 SLN19 SLN18 SLN17 SLN16 4
(INTEGER) SLN15 SLN14 SLN13 SLN12 SLN11 SLN10 SLN9 SLN8 5
SLN7 SLN6 SLN5 SLN4 SLN3 SLN2 SLN1 SLN0 6
Source Line No. SLN–1 SLN–2 SLN–3 SLN–4 SLN–5 SLN–6 SLN–7 SLN–8 7
(FRACTION) SLN–9 SLN–10 SLN–11 SLN–12 SLN–13 SLN–14 SLN–15 SLN–16 8
Source Point No. SPN23 SPN22 SPN21 SPN20 SPN19 SPN18 SPN17 SPN16 9
(INTEGER) SPN15 SPN14 SPN13 SPN12 SPN11 SPN10 SPN9 SPN8 10
SPN7 SPN6 SPN5 SPN4 SPN3 SPN2 SPN1 SPN0 11
Source Point No. SPN–1 SPN–2 SPN–3 SPN–4 SPN–5 SPN–6 SPN–7 SPN–8 12
(FRACTION) SPN−9 SPN−10 SPN−11 SPN−12 SPN−13 SPN−14 SPN−15 SPN−16 13
Source Point Index SPI7 SPI6 SPI5 SPI4 SPI3 SPI2 SPI1 SPI0 14
Phase Control PC7 PC6 PC5 PC4 PC3 PC2 PC1 PC0 15
Type Vibrator V7 V6 V5 V4 V3 V2 V1 V0 16
Phase Angle PA15 PA14 PA13 PA12 PA11 PA10 PA9 PA8 17
PA7 PA6 PA5 PA4 PA3 PA2 PA1 PA0 18
Source Id SI7 SI6 SI5 SI4 SI3 SI2 SI1 SI0 19
Source Set No. SS7 SS6 SS5 SS4 SS3 SS2 SS1 SS0 20
Re-shoot Index RI7 RI6 RI5 RI4 RI3 RI2 RI1 RI0 21
Group Index GI7 GI6 GI5 GI4 GI3 GI2 GI1 GI0 22
Depth Index DI7 DI6 DI5 DI4 DI3 DI2 DI1 DI0 23
Offset Cross-line OX15 OX14 OX13 OX12 OX11 OX10 OX9 OX8 24
OX7 OX6 OX5 OX4 OX3 OX2 OX1 OX0 25
Offset In-line OI15 OI14 OI13 OI12 OI11 OI10 OI9 OI8 26
OI7 OI6 OI5 OI4 OI3 OI2 OI1 OI0 27
Size SZ15 SZ14 SZ13 SZ12 SZ11 SZ10 SZ9 SZ8 28
SZ7 SZ6 SZ5 SZ4 SZ3 SZ2 SZ1 SZ0 29
Offset Depth OD15 OD14 OD13 OD12 OD11 OD10 OD9 OD8 30
OD7 OD6 OD5 OD4 OD3 OD2 OD1 OD0 31
7.9.2 EXPLOSIVE
Bit No. 0 1 2 3 4 5 6 7

(FRACTION) SPN–9 SPN–10 SPN–11 SPN–12 SPN–13 SPN–14 SPN–15 SPN–16 13
Depth DE15 DE14 DE13 DE12 DE11 DE10 DE9 DE8 15
DE7 DE6 DE5 DE4 DE3 DE2 DE1 DE0 16
Charge Length CL7 CL6 CL5 CL4 CL3 CL2 CL1 CL0 17
Soil Type ST7 ST6 ST5 ST4 ST3 ST2 ST1 ST0 18
7.9.3 AIRGUN
Bit No. 0 1 2 3 4 5 6 7

Air Pressure AP15 AP14 AP13 AP12 AP11 AP10 AP9 AP8 17
AP7 AP6 AP5 AP4 AP3 AP2 AP1 AP0 18
7.9.4 WATERGUN
Bit No. 0 1 2 3 4 5 6 7
Air Pressure AP15 AP14 AP13 AP12 AP11 AP10 AP9 AP8 17
AP7 AP6 AP5 AP4 AP3 AP2 AP1 AP0 18

7.9.5 ELECTROMAGNETIC SOURCE
Bit No. 0 1 2 3 4 5 6 7
Source Type ST7 ST6 ST5 ST4 ST3 ST2 ST1 ST0 15
Moment MO23 MO22 MO21 MO20 MO19 MO18 MO17 MO16 16
MO15 MO14 MO13 MO12 MO11 MO10 MO9 MO8 17
MO7 MO6 MO5 MO4 MO3 MO2 MO1 MO0 18
Current/Voltage CV15 CV14 CV13 CV12 CV11 CV10 CV9 CV8 28
CV7 CV6 CV5 CV4 CV3 CV2 CV1 CV0 29

7.9.6 OTHER SOURCE
Bit No. 0 1 2 3 4 5 6 7
(FRACTION)
SPN–9 SPN–10 SPN–11 SPN–12 SPN–13 SPN–14 SPN–15 SPN–16 13
X X X X X X X X 15
X X X X X X X X 16
X X X X X X X X 17
X X X X X X X X 18
X X X X X X X X 28
X X X X X X X X 29
7.10 ADDITIONAL SOURCE INFO (optional)
Follows the Source Description Block
Bit No. 0 1 2 3 4 5 6 7

Time T63 T62 T61 T60 T59 T58 T57 T56 1
T55 T54 T53 T52 T51 T50 T49 T48 2
T47 T46 T45 T44 T43 T42 T41 T40 3
T39 T38 T37 T36 T35 T34 T33 T32 4
T31 T30 T29 T28 T27 T26 T25 T24 5
T23 T22 T21 T20 T19 T18 T17 T16 6
T15 T14 T13 T12 T11 T10 T9 T8 7
T7 T6 T5 T4 T3 T2 T1 T0 8
Source Status SST7 SST6 SST5 SST4 SST3 SST2 SST1 SST0 9
Source Moving MV7 MV6 MV5 MV4 MV3 MV2 MV1 MV0 11
Error description ED ED ED ED ED ED ED ED 12
ED ED ED ED ED ED ED ED 13
7.11 SOURCE AUXILIARY CHANNEL REFERENCE (optional)

Bit No. 0 1 2 3 4 5 6 7
Scan Type Number 1 ST11 ST11 ST11 ST11 ST12 ST12 ST12 ST12 2
Channel Set Number 1 CS115 CS114 CS113 CS112 CS111 CS110 CS19 CS18 3
CS17 CS16 CS15 CS14 CS13 CS12 CS11 CS10 4
Trace Number 1 TN123 TN122 TN121 TN120 TN119 TN118 TN117 TN116 5
TN115 TN114 TN113 TN112 TN111 TN110 TN19 TN18 6


7.12 COORDINATE REFERENCE SYSTEM IDENTIFICATION (conditional)
This header block is mandatory if a position block is included in the record.
Bit No. 0 1 2 3 4 5 6 7
Coordinate CRID CRID CRID CRID CRID CRID CRID CRID 1
Reference CRID CRID CRID CRID CRID CRID CRID CRID 2
System (CRS) CRID CRID CRID CRID CRID CRID CRID CRID 3
identification CRID CRID CRID CRID CRID CRID CRID CRID 4
CRID CRID CRID CRID CRID CRID CRID CRID 5
Header Blk Type 0 1 0 1 0 1 0 1 32
7.13 POSITION BLOCKS (optional)
Bit No. 0 1 2 3 4 5 6 7
Time of position TP63 TP62 TP61 TP60 TP59 TP58 TP57 TP56 1
TP55 TP54 TP53 TP52 TP51 TP50 TP49 TP48 2

Time of TC63 TC62 TC61 TC60 TC59 TC58 TC57 TC56 9
measurement/ TC55 TC54 TC53 TC52 TC51 TC50 TC49 TC48 10
calculation TC47 TC46 TC45 TC44 TC43 TC42 TC41 TC40 11
TC39 TC38 TC37 TC36 TC35 TC34 TC33 TC32 12
TC7 TC6 TC5 TC4 TC3 TC2 TC1 TC 0 16
Vertical VE31 VE30 VE29 VE28 VE27 VE26 VE25 VE24 17
error VE23 VE22 VE21 VE20 VE19 VE18 VE17 VE16 18
VE15 VE14 VE13 VE12 VE11 VE10 VE9 VE8 19
VE7 VE6 VE5 VE4 VE3 VE2 VE1 VE0 20
Horizontal error HEA31 HEA30 HEA29 HEA28 HEA27 HEA26 HEA25 HEA24 21
ellipse HEA23 HEA22 HEA21 HEA20 HEA19 HEA18 HEA17 HEA16 22
semi-major HEA15 HEA14 HEA13 HEA12 HEA11 HEA10 HEA9 HEA8 23
dimension HEA7 HEA6 HEA5 HEA4 HEA3 HEA2 HEA1 HEA0 24
Horizontal error HEB31 HEB30 HEB29 HEB28 HEB27 HEB26 HEB25 HEB24 25
ellipse HEB23 HEB22 HEB21 HEB20 HEB19 HEB18 HEB17 HEB16 26
semi-minor HEB15 HEB14 HEB13 HEB12 HEB11 HEB10 HEB9 HEB8 27
dimension HEB7 HEB6 HEB5 HEB4 HEB3 HEB2 HEB1 HEB0 28
Horizontal error HEO15 HEO14 HEO13 HEO12 HEO11 HEO10 HEO9 HEO8 29
ellipse orientation HEO7 HEO6 HEO5 HEO4 HEO3 HEO2 HEO1 HEO0 30
Position Type PT7 PT6 PT5 PT4 PT3 PT2 PT1 PT 0 31
Header Blk Type 0 1 0 1 0 0 0 0 32
Bit No. 0 1 2 3 4 5 6 7
Coord tuple 1 T1C163 T1C162 T1C161 T1C160 T1C159 T1C158 T1C157 T1C156 33
Coord 1 T1C155 T1C154 T1C153 T1C152 T1C151 T1C150 T1C149 T1C148 34
T1C147 T1C146 T1C145 T1C144 T1C143 T1C142 T1C141 T1C140 35

Stanza ID 1 ID115 ID114 ID113 ID112 ID111 ID110 ID19 ID18 57
ID17 ID16 ID15 ID14 ID13 ID12 ID11 ID10 58
Position 1 valid PV17 PV16 PV15 PV14 PV13 PV12 PV11 PV10 59
Position 1 quality PQ17 PQ16 PQ15 PQ14 PQ13 PQ12 PQ11 PQ10 60
Undefined X X X X X X X X 61
X X X X X X X X 62
X X X X X X X X 63
Header Blk Type 0 1 0 1 0 0 0 1 64
Bit No. 0 1 2 3 4 5 6 7
Stanza ID 2 ID215 ID214 ID213 ID212 ID211 ID210 ID29 ID28 89
ID27 ID26 ID25 ID24 ID23 ID22 ID21 ID20 90
Position 2 valid PV27 PV26 PV25 PV24 PV23 PV22 PV21 PV20 91
Position 2 quality PQ27 PQ26 PQ25 PQ24 PQ23 PQ22 PQ21 PQ20 92
X X X X X X X X 94
X X X X X X X X 95
Header Blk Type 0 1 0 1 0 0 1 0 96

7.14 RELATIVE POSITION BLOCK (optional)
Bit No. 0 1 2 3 4 5 6 7
Offset easting OE31 OE30 OE29 OE28 OE27 OE26 OE25 OE24 1
OE23 OE22 OE21 OE20 OE19 OE18 OE17 OE16 2
Offset northing ON31 ON30 ON29 ON28 ON27 ON26 ON25 ON24 5
ON23 ON22 ON21 ON20 ON19 ON18 ON17 ON16 6
Offset vertical OD31 OD30 OD29 OD28 OD27 OD26 OD25 OD24 9
Description DE DE DE DE DE DE DE DE 13
DE DE DE DE DE DE DE DE 14
Header Blk Type 0 1 0 1 0 1 1 0 32
7.15 SCAN TYPE HEADER (Channel Set Descriptor)
Bit No. 0 1 2 3 4 5 6 7
BCD Value MSD 8 4 2 1 8 4 2 1
Binary Value MSB 128 64 32 16 8 4 2 1
Scan Type No. ST1 ST1 ST1 ST1 ST2 ST2 ST2 ST2 1

Channel Set No. CS15 CS14 CS13 CS12 CS11 CS10 CS9 CS8 2
Channel Type C7 C6 C5 C4 C3 C2 C1 C0 4
Channel Set TF31 TF30 TF29 TF28 TF27 TF26 TF25 TF24 5
Start Time TF23 TF22 TF21 TF20 TF19 TF18 TF17 TF16 6
TF15 TF14 TF13 TF12 TF11 TF10 TF9 TF8 7
TF7 TF6 TF5 TF4 TF3 TF2 TF1 TF0 8
Channel Set TE31 TE30 TE29 TE28 TE27 TE26 TE25 TE24 9
End Time TE23 TE22 TE21 TE20 TE19 TE18 TE17 TE16 10
TE15 TE14 TE13 TE12 TE11 TE10 TE9 TE8 11
TE7 TE6 TE5 TE4 TE3 TE2 TE1 TE0 12
Number of Samples NS31 NS30 NS29 NS28 NS27 NS26 NS25 NS24 13
NS23 NS22 NS21 NS20 NS19 NS18 NS17 NS16 14
Descale Multiplier DSM31 DSM30 DSM29 DSM28 DSM27 DSM26 DSM25 DSM24 17
DSM23 DSM22 DSM21 DSM20 DSM19 DSM18 DSM17 DSM16 18
No. of Channels C/S23 C/S22 C/S21 C/S20 C/S19 C/S18 C/S17 C/S16 21
C/S15 C/S14 C/S13 C/S12 C/S11 C/S10 C/S9 C/S8 22
C/S7 C/S6 C/S5 C/S4 C/S3 C/S2 C/S1 C/S0 23
Sampling Interval SR23 SR22 SR21 SR20 SR19 SR18 SR17 SR16 24
SR15 SR14 SR13 SR12 SR11 SR10 SR9 SR8 25
SR7 SR6 SR5 SR4 SR3 SR2 SR1 SR0 26
Array Forming ARY7 ARY6 ARY5 ARY4 ARY3 ARY2 ARY1 ARY0 27
Trace Header Extensions THE7 THE6 THE5 THE4 THE3 THE2 THE1 THE0 28
Extended Header EFH3 EFH2 EFH1 EFH0 J J J J 29
Flag/Channel Gain
Vertical Stack VS7 VS6 VS5 VS4 VS3 VS2 VS1 VS0 30
Streamer No. CAB7 CAB6 CAB5 CAB4 CAB3 CAB2 CAB1 CAB0 31
Bit No. 0 1 2 3 4 5 6 7
BCD Value MSD 8 4 2 1 8 4 2 1
Binary Value MSB 128 64 32 16 8 4 2 1
Alias Filter Frequency AF31 AF30 AF29 AF28 AF27 AF26 AF25 AF24 33
AF23 AF22 AF21 AF20 AF19 AF18 AF17 AF16 34
Low Cut Filter LC31 LC30 LC29 LC28 LC27 LC26 LC25 LC24 37
LC23 LC22 LC21 LC20 LC19 LC18 LC17 LC16 38
Alias Filter Slope AS31 AS30 AS29 AS28 AS27 AS26 AS25 AS24 41
AS23 AS22 AS21 AS20 AS19 AS18 AS17 AS16 42

Low Cut Filter Slope LS31 LS30 LS29 LS28 LS27 LS26 LS25 LS24 45
LS23 LS22 LS21 LS20 LS19 LS18 LS17 LS16 46
First Notch Filter NT131 NT130 NT129 NT128 NT127 NT126 NT125 NT124 49
NT123 NT122 NT121 NT120 NT119 NT118 NT117 NT116 50
Second Notch Filter NT231 NT230 NT229 NT228 NT227 NT226 NT225 NT224 53
Third Notch Filter NT331 NT330 NT329 NT328 NT327 NT326 NT325 NT324 57
Filter Phase FPH7 FPH6 FPH5 FPH4 FPH3 FPH2 FPH1 FPH0 61
Physical Unit PHU7 PHU6 PHU5 PHU4 PHU3 PHU2 PHU1 PHU0 62
X X X X X X X X 63
Bit No. 0 1 2 3 4 5 6 7
BCD Value MSD 8 4 2 1 8 4 2 1
Binary Value MSB 128 64 32 16 8 4 2 1
Filter delay FDL31 FDL30 FDL29 FDL28 FDL27 FDL26 FDL25 FDL24 65
FDL23 FDL22 FDL21 FDL20 FDL19 FDL18 FDL17 FDL16 66
Description DSC DSC DSC DSC DSC DSC DSC DSC 69
DSC DSC DSC DSC DSC DSC DSC DSC 70


7.16 DEMUX TRACE HEADER
Bit No. 0 1 2 3 4 5 6 7
File Number F1 F1 F1 F1 F2 F2 F2 F2 1
F3 F3 F3 F3 F4 F4 F4 F4 2
Scan Type Number ST1 ST1 ST1 ST1 ST2 ST2 ST2 ST2 3
Channel Set CN1 CN1 CN1 CN1 CN2 CN2 CN2 CN2 4
Number
Trace Number TN1 TN1 TN1 TN1 TN2 TN2 TN2 TN2 5
First Timing Word T15 T14 T13 T12 T11 T10 T9 T8 7
T7 T6 T5 T4 T3 T2 T1 T0 8
T–1 T–2 T–3 T–4 T–5 T–6 T–7 T–8 9
Trace Header THE7 THE6 THE5 THE4 THE3 THE2 THE1 THE0 10
Extension
Sample Skew SSK–1 SSK–2 SSK–3 SSK–4 SSK–5 SSK–6 SSK–7 SSK–8 11
Trace Edit TR7 TR6 TR5 TR4 TR3 TR2 TR1 TR0 12
Time Break TW15 TW14 TW13 TW12 TW11 TW10 TW9 TW8 13
Window
TW7 TW6 TW5 TW4 TW3 TW2 TW1 TW0 14
TW–1 TW–2 TW–3 TW–4 TW–5 TW–6 TW–7 TW–8 15
Extended Channel EN15 EN14 EN13 EN12 EN11 EN10 EN9 EN8 16
Set Number
EN7 EN6 EN5 EN4 EN3 EN2 EN1 EN0 17
Extended File EFN23 EFN22 EFN21 EFN20 EFN19 EFN18 EFN17 EFN16 18
Number
EFN15 EFN14 EFN13 EFN12 EFN11 EFN10 EFN9 EFN8 19
EFN7 EFN6 EFN5 EFN4 EFN3 EFN2 EFN1 EFN0 20

7.17 TRACE HEADER EXTENSION #1
Bit No. 0 1 2 3 4 5 6 7
Receiver Line RLN23 RLN22 RLN21 RLN20 RLN19 RLN18 RLN17 RLN16 1
Number RLN15 RLN14 RLN13 RLN12 RLN11 RLN10 RLN9 RLN8 2
RLN7 RLN6 RLN5 RLN4 RLN3 RLN2 RLN1 RLN0 3
Receiver Point RPN23 RPN22 RPN21 RPN20 RPN19 RPN18 RPN17 RPN16 4
Number RPN15 RPN14 RPN13 RPN12 RPN11 RPN10 RPN9 RPN8 5
RPN7 RPN6 RPN5 RPN4 RPN3 RPN2 RPN1 RPN0 6
Receiver Point RPI7 RPI6 RPI5 RPI4 RPI3 RPI2 RPI1 RPI0 7
Index
Reshoot Index RI7 RI6 RI5 RI4 RI3 RI2 RI1 RI0 8
Extended ERLN23 ERLN22 ERLN21 ERLN20 ERLN19 ERLN18 ERLN17 ERLN16 11
Receiver Line ERLN15 ERLN14 ERLN13 ERLN12 ERLN11 ERLN10 ERLN9 ERLN8 12
Number ERLN7 ERLN6 ERLN5 ERLN4 ERLN3 ERLN2 ERLN1 ERLN0 13
ERLN–1 ERLN–2 ERLN–3 ERLN–4 ERLN–5 ERLN–6 ERLN–7 ERLN–8 14
ERLN–9 ERLN–10 ERLN–11 ERLN–12 ERLN–13 ERLN–14 ERLN–15 ERLN–16 15
Extended ERPN23 ERPN22 ERPN21 ERPN20 ERPN19 ERPN18 ERPN17 ERPN16 16
Receiver Point # ERPN15 ERPN14 ERPN13 ERPN12 ERPN11 ERPN10 ERPN9 ERPN8 17
ERPN7 ERPN6 ERPN5 ERPN4 ERPN3 ERPN2 ERPN1 ERPN0 18
ERPN–1 ERPN–2 ERPN–3 ERPN–4 ERPN–5 ERPN–6 ERPN–7 ERPN–8 19
ERPN–9 ERPN–10 ERPN–11 ERPN–12 ERPN–13 ERPN–14 ERPN–15 ERPN–16 20
Sensor Type SEN7 SEN6 SEN5 SEN4 SEN3 SEN2 SEN1 SEN0 21
Extended Trace ETN23 ETN22 ETN21 ETN20 ETN19 ETN18 ETN17 ETN16 22
Number ETN15 ETN14 ETN13 ETN12 ETN11 ETN10 ETN9 ETN8 23
ETN7 ETN6 ETN5 ETN4 ETN3 ETN2 ETN1 ETN0 24
# of Samples per NS31 NS30 NS29 NS28 NS27 NS26 NS25 NS24 25
Trace NS23 NS22 NS21 NS20 NS19 NS18 NS17 NS16 26
Sensor Moving MV7 MV6 MV5 MV4 MV3 MV2 MV1 MV0 29
Physical Unit PHU7 PHU6 PHU5 PHU4 PHU3 PHU2 PHU1 PHU0 31
Header Blk Type 0 1 0 0 0 0 0 0 32
7.18 SENSOR INFO HEADER EXTENSION (optional)
Bit No. 0 1 2 3 4 5 6 7
Instrument Test ITT63 ITT62 ITT61 ITT60 ITT59 ITT58 ITT57 ITT56 1
Time ITT55 ITT54 ITT53 ITT52 ITT51 ITT50 ITT49 ITT48 2
ITT47 ITT46 ITT45 ITT44 ITT43 ITT42 ITT41 ITT40 3

Sensor STY31 STY30 STY29 STY28 STY27 STY26 STY25 STY24 9
Sensitivity STY23 STY22 STY21 STY20 STY19 STY18 STY17 STY16 10
STY15 STY14 STY13 STY12 STY11 STY10 STY9 STY8 11
STY7 STY6 STY5 STY4 STY3 STY2 STY1 STY0 12
Instr Test Result ITR7 ITR6 ITR5 ITR4 ITR3 ITR2 ITR1 ITR0 13
Serial Number SN SN SN SN SN SN SN SN 14
SN SN SN SN SN SN SN SN 15
Header Blk Type 0 1 0 0 0 0 0 1 32
7.19 TIMESTAMP HEADER (optional)
Bit No. 0 1 2 3 4 5 6 7
Time Zero of TZD63 TZD62 TZD61 TZD60 TZD59 TZD58 TZD57 TZD56 1
Data TZD55 TZD54 TZD53 TZD52 TZD51 TZD50 TZD49 TZD48 2
TZD47 TZD46 TZD45 TZD44 TZD43 TZD42 TZD41 TZD40 3
X X X X X X X X 10
X X X X X X X X 11
X X X X X X X X 12
X X X X X X X X 13
X X X X X X X X 14
X X X X X X X X 15
X X X X X X X X 16
X X X X X X X X 17
X X X X X X X X 18
X X X X X X X X 19

X X X X X X X X 20
X X X X X X X X 21
X X X X X X X X 22
X X X X X X X X 23
X X X X X X X X 24
X X X X X X X X 25
X X X X X X X X 26
X X X X X X X X 27
X X X X X X X X 28
X X X X X X X X 29
X X X X X X X X 30
X X X X X X X X 31
Header Blk Type 0 1 0 0 0 0 1 0 32
7.20 SENSOR CALIBRATION HEADER (optional)
Bit No. 0 1 2 3 4 5 6 7
Frequency 1 FR131 FR130 FR129 FR128 FR127 FR126 FR125 FR124 1
FR123 FR122 FR121 FR120 FR119 FR118 FR117 FR116 2
Amplitude 1 AM131 AM130 AM129 AM128 AM127 AM126 AM125 AM124 5
AM123 AM122 AM121 AM120 AM119 AM118 AM117 AM116 6
Phase 1 PH131 PH130 PH129 PH128 PH127 PH126 PH125 PH124 9
PH123 PH122 PH121 PH120 PH119 PH118 PH117 PH116 10
Frequency 2 FR231 FR230 FR229 FR228 FR227 FR226 FR225 FR224 13
Amplitude 2 AM231 AM230 AM229 AM228 AM227 AM226 AM225 AM224 17
Phase 2 PH231 PH230 PH229 PH228 PH227 PH226 PH225 PH224 21
Calibration applied CA7 CA6 CA5 CA4 CA3 CA2 CA1 CA0 25
X X X X X X X X 27
X X X X X X X X 28
X X X X X X X X 29

X X X X X X X X 30
X X X X X X X X 31
Header Blk Type 0 1 0 0 0 0 1 1 32
7.21 TIME DRIFT HEADER (optional)
Bit No. 0 1 2 3 4 5 6 7
Time of TD63 TD62 TD61 TD60 TD59 TD58 TD57 TD56 1
deployment TD55 TD54 TD53 TD52 TD51 TD50 TD49 TD48 2
TD47 TD46 TD45 TD44 TD43 TD42 TD41 TD40 3
Time of TR63 TR62 TR61 TR60 TR59 TR58 TR57 TR56 9
retrieval TR55 TR54 TR53 TR52 TR51 TR50 TR49 TR48 10
TR47 TR46 TR45 TR44 TR43 TR42 TR41 TR40 11
Timer Offset OD31 OD30 OD29 OD28 OD27 OD26 OD25 OD24 17
Deployment OD23 OD22 OD21 OD20 OD19 OD18 OD17 OD16 18
Time Offset OR31 OR30 OR29 OR28 OR27 OR26 OR25 OR24 21
Retrieval OR23 OR22 OR21 OR20 OR19 OR18 OR17 OR16 22
OR15 OR14 OR13 OR12 OR11 OR10 OR9 OR8 23
OR7 OR6 OR5 OR4 OR3 OR2 OR1 OR0 24
Timedrift corrected TDC7 TDC6 TDC5 TDC4 TDC3 TDC2 TDC1 TDC0 25
Correction method CM7 CM6 CM5 CM4 CM3 CM2 CM1 CM0 26
X X X X X X X X 28
X X X X X X X X 29
X X X X X X X X 30
X X X X X X X X 31
Header Blk Type 0 1 0 0 0 1 0 0 32
7.22 ORIENTATION HEADER (optional)
Bit No. 0 1 2 3 4 5 6 7
Rotation X axis RX31 RX30 RX29 RX28 RX27 RX26 RX25 RX24 1
RX23 RX22 RX21 RX20 RX19 RX18 RX17 RX16 2

Rotation Y axis RY31 RY30 RY29 RY28 RY27 RY26 RY25 RY24 5
RY23 RY22 RY21 RY20 RY19 RY18 RY17 RY16 6
Rotation Z axis RZ31 RZ30 RZ29 RZ28 RZ27 RZ26 RZ25 RZ24 9
RZ23 RZ22 RZ21 RZ20 RZ19 RZ18 RZ17 RZ16 10
Reference RO31 RO30 RO29 RO28 RO27 RO26 RO25 RO24 13
Orientation RO23 RO22 RO21 RO20 RO19 RO18 RO17 RO16 14
RO15 RO14 RO13 RO12 RO11 RO10 RO9 RO8 15
RO7 RO6 RO5 RO4 RO3 RO2 RO1 RO0 16
Time Stamp TS63 TS62 TS61 TS60 TS59 TS58 TS57 TS56 17
TS55 TS54 TS53 TS52 TS51 TS50 TS49 TS48 18
Orientation Type OT7 OT6 OT5 OT4 OT3 OT2 OT1 OT0 25
Ref Orient Valid ROV7 ROV6 ROV5 ROV4 ROV3 ROV2 ROV1 ROV0 26
Rotation Applied RA7 RA6 RA5 RA4 RA3 RA2 RA1 RA0 27
Rot North Applied RNA7 RNA6 RNA5 RNA4 RNA3 RNA2 RNA1 RNA0 28
X X X X X X X X 29
X X X X X X X X 30
X X X X X X X X 31
Header Blk Type 0 1 1 0 0 0 0 0 32
7.23 MEASUREMENT BLOCK (optional)
Bit No. 0 1 2 3 4 5 6 7
Timestamp TS63 TS62 TS61 TS60 TS59 TS58 TS57 TS56 1
Measurement VA31 VA30 VA29 VA28 VA27 VA26 VA25 VA24 9
Value VA23 VA22 VA21 VA20 VA19 VA18 VA17 VA16 10
VA15 VA14 VA13 VA12 VA11 VA10 VA9 VA8 11
VA7 VA6 VA5 VA4 VA3 VA2 VA1 VA0 12

Maximum Value MA31 MA30 MA29 MA28 MA27 MA26 MA25 MA24 13
MA23 MA22 MA21 MA20 MA19 MA18 MA17 MA16 14
Minimum Value MI31 MI30 MI29 MI28 MI27 MI26 MI25 MI24 17
MI23 MI22 MI21 MI20 MI19 MI18 MI17 MI16 18
Quantity Class QC15 QC14 QC13 QC12 QC11 QC10 QC9 QC8 21
QC7 QC6 QC5 QC4 QC3 QC2 QC1 QC0 22
Unit Of Measure UOM15 UOM14 UOM13 UOM12 UOM11 UOM10 UOM9 UOM8 23
UOM7 UOM6 UOM5 UOM4 UOM3 UOM2 UOM1 UOM0 24
Measurement MD15 MD14 MD13 MD12 MD11 MD10 MD9 MD8 25
Description MD7 MD6 MD5 MD4 MD3 MD2 MD1 MD0 26
X X X X X X X X 28
X X X X X X X X 29
X X X X X X X X 30
X X X X X X X X 31
Header Blk Type 0 1 1 0 0 0 0 1 32
7.24 ELECTROMAGNETIC SRC/RECV DESC BLOCK (optional)
Bit No. 0 1 2 3 4 5 6 7
Equipment LX23 LX22 LX21 LX20 LX19 LX18 LX17 LX16 1
Dimension X LX15 LX14 LX13 LX12 LX11 LX10 LX9 LX8 2
LX7 LX6 LX5 LX4 LX3 LX2 LX1 LX0 3
Equipment LY23 LY22 LY21 LY20 LY19 LY18 LY17 LY16 4
Dimension Y LY15 LY14 LY13 LY12 LY11 LY10 LY9 LY8 5
LY7 LY6 LY5 LY4 LY3 LY2 LY1 LY0 6
Equipment LZ23 LZ22 LZ21 LZ20 LZ19 LZ18 LZ17 LZ16 7
Dimension Z LZ15 LZ14 LZ13 LZ12 LZ11 LZ10 LZ9 LZ8 8
LZ7 LZ6 LZ5 LZ4 LZ3 LZ2 LZ1 LZ0 9
Positive terminal PT7 PT6 PT5 PT4 PT3 PT2 PT1 PT0 10
Equipment OX23 OX22 OX21 OX20 OX19 OX18 OX17 OX16 11
Offset X OX15 OX14 OX13 OX12 OX11 OX10 OX9 OX8 12
Equipment OY23 OY22 OY21 OY20 OY19 OY18 OY17 OY16 14
Offset Y OY15 OY14 OY13 OY12 OY11 OY10 OY9 OY8 15
OY7 OY6 OY5 OY4 OY3 OY2 OY1 OY0 16
Equipment OZ23 OZ22 OZ21 OZ20 OZ19 OZ18 OZ17 OZ16 17
Offset Z OZ15 OZ14 OZ13 OZ12 OZ11 OZ10 OZ9 OZ8 18
OZ7 OZ6 OZ5 OZ4 OZ3 OZ2 OZ1 OZ0 19
X X X X X X X X 21
X X X X X X X X 22
X X X X X X X X 23
X X X X X X X X 24
X X X X X X X X 25

X X X X X X X X 26
X X X X X X X X 27
X X X X X X X X 28
X X X X X X X X 29
X X X X X X X X 30
X X X X X X X X 31
Header Blk Type 0 1 0 0 0 1 0 1 32
7.25 GENERAL TRAILER DESCRIPTION BLOCK (optional)
Bit No. 0 1 2 3 4 5 6 7
Block Type BT7 BT6 BT5 BT4 BT3 BT2 BT1 BT0 1
ASCII or binary AB7 AB6 AB5 AB4 AB3 AB2 AB1 AB0 2
0 0 0 0 0 0 0 0 3
0 0 0 0 0 0 0 0 4
Block Size SI31 SI30 SI29 SI28 SI27 SI26 SI25 SI24 5
SI23 SI22 SI21 SI20 SI19 SI18 SI17 SI16 6
Description DE DE DE DE DE DE DE DE 9
0 0 0 0 0 0 0 0 25
0 0 0 0 0 0 0 0 26
0 0 0 0 0 0 0 0 27
0 0 0 0 0 0 0 0 28
0 0 0 0 0 0 0 0 29
0 0 0 0 0 0 0 0 30
0 0 0 0 0 0 0 0 31
Header Blk Type 0 1 1 1 0 0 0 0 32

8.0 HEADER BLOCK PARAMETERS
In cases where extended fields exists (e.g. File Number (General Header #1) and Extended File Number (General Header
#2), all nibbles of the original field is set to F16 to indicate when the extended field is used. When the normal field is used,
the extended field is either set to 0 or the value of the normal field. No other values are allowed.
The different location indexes for sources and receivers (Line, Point, Point index, Depth, Group and Depth) should be
recorded as 0 if they are unknown/undetermined unless specified otherwise.
8.1 GENERAL HEADER, BLOCK #1
All values are in packed BCD unless otherwise specified.
INDEX ABBREVIATION DESCRIPTION

BYTE
_____ _________________________________________________________________
1 F1, F2 File number of four digits (0–9999), set to FFFF16 when the
2 F3, F4 file number is greater than 9999. The expanded file number is contained in
Bytes 1, 2, and 3 of General Header, Block #2.
3 Y1, Y2 Format code:

4 Y3, Y4 8015 20 bit binary
8022 8 bit quaternary
8024 16 bit quaternary
8036 24 bit 2's complement integer
8038 32 bit 2's complement integer
8042 8 bit hexadecimal
8058 32 bit IEEE
8080 64 bit IEEE
0200 Illegal, do not use
0000 Illegal, do not use
5 K1, K2 General constants, 12 digits

6 K3, K4
7 K5, K6
8 K7, K8
9 K9, K10
10 K11, K12
11 YR1, YR2 Last two digits of year (0–99)
12 GH Number of additional Blocks in General Header (unsigned binary). This

number will be 2 or greater for Rev 3 (e.g., if only General Header Blocks #1,
#2 and #3 are present then GH = 2). For each additional block, the value is
increased by one.). If more than 14 are required, set to GH to F16, and use bytes
23–24 of the General Header Block #2.
12 DY1
13 DY2, DY3 Julian day, 3 digits (1–366).

14 H1, H2 Hour of day, 2 digits (0–23) (UTC Time).
15 MI1, MI2 Minute of hour, 2 digits (0–59).
16 SE1, SE2 Second of minute, 2 digits (0–60). The value 60 is a legal value of this field
only during UTC leap seconds.
17 M1, M2 Manufacturer's code 2 digits

Note: See Appendix A for the current assignments
18 M3, M4 Manufacturer's serial number, 4 digits
19 M5, M6
20 0 Not used. Record as zero

23 I3 – I –4 Base scan interval. This is coded as a binary number with the LSB equal to
1/16 msec. This will allow sampling intervals from 1/16 through 8 msec in
binary steps. Thus, the allowable base scan intervals are 1/16, 1/8, 1/4, 1/2, 1,
2, 4, and 8 msec. The base scan interval is always the difference between
successive timing words. Note: Each channel set is no longer (as of Rev 3.0)
required to have a scan interval that is a multiple of the base scan interval.
Instead, this is defined to be the main/dominant scan rate. If a different base
scan interval is required, set to FF16, and use byte 25–27 in General Header
Block #2. Also note: Care must be taken when using 1/16 msec sample rate as
it is not a multiple of 1 microsecond which means only every second sample
can be absolutely addressed by a SEGD timestamp.
24 P, Polarity. These 4 binary bits are measured on the sensors, cables, instrument,
and source combination and are set into the system manually. The codes are:
016 Untested
116 Zero
216 45 degrees
316 90 degrees
416 135 degrees
516 180 degrees
616 225 degrees
716 270 degrees
816 315 degrees
C16 unassigned
24 X These 4 bits are not used.

25 X These 8 bits are not used.
26 Z, Record type
216 Test record
416 Parallel channel test
616 Direct channel test
816 Normal record
116 Other
26 R1,

27 R2, R3 Record length from time zero (in increments of 0.5 times 1.024 sec). This
value can be set from 00.5 to 99.5 representing times from 0.512 sec. to
101.888 sec. A setting of 00.0 indicates the record length is indeterminate.
These three nibbles must be set to FFF16 when using the Extended Record
Length (record length in milliseconds), bytes 17-20, in General Header Block
#2. This is the maximum record length for any trace in the record. If Extended
Recording Mode is used (General Header #3 byte 29 set to 1), Record Length
must be set to 00.0.
28 ST/R1, ST/R2 Scan types per record. This 2 digit code is the number of scan types per record
(0–99).
29 CS1, CS2 Number of channel sets per scan type (0–99). (Set to FF16 when using
Extended Channel Sets/Scan Type.) This 2 digit code is the number of channel
sets per scan. If multiple scan types are used (such as in a switching sampling
interval environment), this number is equal to the number of channel sets
contained in the scan type with the largest number of channel sets. If scan
types also exist with less than this maximum number of channel sets per scan
type, dummy channel set descriptors will have to be recorded in the Scan Type
Header. This can be done by setting the number of channels in the dummy
channel set descriptor to zero (reference Bytes 21 - 23 of the Scan Type Header
description).
30 SK1, SK2 Number of 32 byte fields added to the end of each scan type header in order to
record the sample skew of all channels (0–99). (See Appendix E.2 of the SEG-
D Standard). Zero indicates that skew is not recorded. If more skew records
are required, set to FF16, and use bytes 9 and 10 of General Header Block #2.
31 EC1, EC2 Extended Header length. The Extended Header is used to record additional
equipment parameters. The two digits (0–99) in this field specify the number
of 32 byte extensions. If more than 99 extensions, then these bytes are set to
FF16. Bytes 6, 7 and 8 of General Header Block #2 contain the number of 32
byte extensions.
32 EX1, EX2 External Header length. The External Header is used to record additional user
supplied information in the header. The two digits (0–99) in this field specify
the number of 32 byte extensions. If more than 99 extensions, then these bytes
are set to FF16. Bytes 28, 29 and 30 of General Header Block #2 contain the
number of 32 byte extensions.

BYTE
_____ _______________ __________________________________________
1,2,3 EF23 – EF0 Extended File Number (three bytes, unsigned binary). For file numbers greater
than the 9999, bytes 1 and 2 of the General Header Block #1 must be set to
FFFF16.
4,5 EN15 – EN0 Extended Channel Sets/Scan Type (two bytes, unsigned binary). Allows the
number of Channel Sets/Scan Type to be greater than the 99 supported in the

standard General Header Block #1 (byte 29). When using the Extended
Channel Sets/Scan Type, byte 29 of General Header Block #1 must be set to
FF16.
6,7,8 ECX23 – ECX0 Extended Header Blocks (three bytes, unsigned binary). Allows the number of
Extended Header Blocks (of 32 bytes each) to be greater than the 99 allowed
by the standard General Header Block #1 (byte 31). To use more than 99
Extended Header Blocks, set byte 31 of General Header Block #1 to FF16, and
use these two bytes. Max size 536,870,880 bytes or 512 MB.
9,10 ESK15 – ESK0 Extended Skew Blocks (two bytes, unsigned binary). Number of 32 byte fields
added to the end of each scan type header in order to record the sample skew of
all channels. (See Appendix E2 of the SEG-D Standard). Zero indicates that
skew is not recorded. When using the Extended Skew blocks field, byte 30 of
General Header Block #1 must be set to FF16.
11 RMJ7 – RMJ0 Major SEG-D Revision Number (one byte, unsigned binary). Set to 0316.
12 RMN7 – RMN0 Minor SEG-D Revision Number (one byte, unsigned binary). Set to 0016.
Revisions 0 to 0.N are not valid. This version is Rev 3.0.
13–16 GT31 – GT0 Number of Blocks of General Trailer (four bytes, unsigned binary). The
number of 32 byte blocks to be used for General Trailers. Max size
137,438,953,408 bytes or 128 GB. If not known at the time (i.e. to allow easy
appending of trailer blocks while data is stored on disk), it may be set to
FFFFFFFF16. The reader will then have to read the trailer block by block to
determine the shot size. It is strongly recommended to set this field to its
correct value when recording to tape.
17–20 ERL31 – ERL0 Extended Record Length (four bytes, unsigned binary) indicates the record
length in microseconds. When using extended record length, the record length
in the General Header Block #1, the Record Length in bytes 26 and 27 must be
set to FFF16. A value of 0.0 means record length is indeterminate. Note: This is
the maximum record length for any trace in the record. Please refer to the
channel set descriptor for actual information of start and end times, number of
samples per trace etc. Also note that negative start times are allowed. If
Extended Recording Mode is used (General Header #3 byte 29 set to 1),
Extended Record Length must be set to 0.0.
21,22 SN15 – SN0 Record set number. (two bytes, unsigned binary) This is the sequence number
(e.g. the line’s unique sequence number), swath number, or any other
applicable number that may be used to identify this group of shot records. Set
to 0 if not valid. Allows values of 1–65535.
23,24 EGH15 – EGH0 Extended Number of additional Blocks in the General Header (two bytes,
unsigned binary). This number will be 2 or greater for Rev 3 (e.g. If only
General Header Blocks #1, #2 and #3 are present then EGH = 2). For each
additional block, the value is increased by one.) When using this field, the
upper nibble of byte 12 of General Header Block #1 must be set to F16.
25,26,27 BSI23 – BSI0 Dominant Sampling Interval (3 bytes, unsigned binary). Only used if General
Header Block #1 (byte 23) is set to FF16. Dominant sampling interval in
microseconds (1/1000000 second). As sample rates allowed in SEG-D Rev 3.0
and above are very flexible, this is no longer related to the base scan interval
(term used in Rev 2.x and below) with each channel set being a multiple of it.
Instead, it is the main or dominant sampling interval for the record. The
sampling interval within each channel set (byte 24-26 of the channel set
header) should be used to find the correct sampling interval. This field should
not be used to calculate size of records or traces in the record. The field is left
for backwards compatibility. It can assume a value from 0 to 16,777,215. A
value of 0 means the dominant sampling interval is indeterminate.
28,29,30 EH23 – EH0 External Header Blocks (3 bytes, unsigned binary). Allows the number of 32
byte External Header Blocks to be greater than the 99 allowed by General
Header Block #1, byte 32. To use more than 99 External Header Blocks, set
byte 32 of General Header Block #1 to FF16, and use these three bytes.
Maximum size is 536,870,880 bytes or 512 MB.
31 X These 8 bits are undefined by the format and may have any value. Note: In
future versions these may be defined, so use with caution.
32 HT7 – HT0 Header block type (one byte, unsigned binary). The header type indicates what
type of information is contained in this header. For General Header Block #2
this byte is set to 0216.
NOTES:
1. Where the range of allowable numbers is not indicated, the follow ranges apply:
One byte, unsigned binary, range is 0 – 255
Two bytes, unsigned binary, range is 0 – 65535
Three bytes, unsigned binary, range is 0 – 16777215
Four bytes, unsigned binary, range is 0 – 4294967295
8.3 GENERAL HEADER BLOCK #3 (Timestamp and size header)

BYTE
_____ _______________ __________________________________________
1–8 TZ63 – TZ0 Time Zero for this record (eight bytes, SEG-D timestamp). The time data and
events in this record are offset from (by using e.g. Channel Set Start Time).
Matches timestamp in General Header Block #1 bytes 11–16, but is accurate to
1 microsecond. If the recorder does not know the absolute time, this must be
recorded as 0, and all timestamps in the record will be relative to this time. If
absolute timing of all data traces and events is used in the record (i.e. by
utilizing Timestamp Header, Additional Source Info Header etc.), the TZ
value may be freely chosen by the recorder. It is however highly recommended
to use a time close to the start of the data/events in the record.
9–16 RS63 – RS0 Record Size (eight bytes, unsigned binary). The total size of the SEG-D record
in number of bytes. May be set to 0 if unknown (e.g., the size of the General
Trailer is set to FFFFFFFF16 in bytes 13–16 in General Header Block #2). It is
strongly recommended to set this field to a proper value unless absolutely
necessary. If no General Trailer blocks exist, this field is equal to the Data Size
(bytes 17–24). The field is very useful for any byte oriented devices like disks
or networks.
17–24 DS63 – DS0 Data Size (eight bytes, unsigned binary). The total size of the headers and data
in this record in number of bytes. This value enables skipping of all traces to
the beginning of the trailer. If no General Trailer exists, this is equal to the
Record Size (bytes 9–16). The field is very useful for any byte oriented devices
like disks and networks.
25–28 HS31 – HS0 Header Size (four bytes, unsigned binary). The total size of the headers (i.e.
General Headers, Channel Set Headers, Skew Headers, External Header,
Extended Header, etc.) in this record in number of bytes. This value enables
skipping of all headers to the beginning of the first trace. The field is very
useful for any byte oriented devices like disks or networks.
29 ERM7 – ERM0 Extended Recording Mode (one byte, unsigned binary). Set to 1 if this record is
using the Extended Recording Mode, 0 for normal record.
30 RTM7 – RTM0 Relative Time Mode (one byte, unsigned binary). Set to 1 if this record does
not contain absolute timestamps, 0 for normal record. If set to 1, bytes 1 to 8
(TZ) must be set to 0, and all timestamps in the record must be relative to this
time (i.e. start of record).
31 X These 8 bits are undefined by the format and may have any value. Note: In
type of information is contained in this header. For General Header Block #3
8.4 GENERAL HEADER BLOCK #4 (Vessel/Crew Identification) (optional)
This block contains the name/description of the vessel or crew.

BYTE
_____ _____________ __________________________________________
1,2,3 VCA Abbreviated vessel or crew name (3 characters, ASCII). May be used on tape
labels, etc. Left justified, padded with space (2016) characters. May be blank if
no abbreviation exists.
4–31 VC Vessel or crew name (ASCII text). 28 character vessel or crew name which
uniquely identifies the vessel/crew within the enterprise. Left justified, padded
with space (2016) characters.
32 HT7 – HT0 Header block type (1 byte, unsigned binary). Set to 1016 for Vessel/Crew
Identification.
8.5 GENERAL HEADER BLOCK #5 (Survey Area Name) (optional)
This block contains the name/description of the survey area.

BYTE

_____ _____________ __________________________________________
1–31 SAN Survey Area Name (ASCII text). 31 character survey area name which
properly identifies the area the record was recorded in. Left justified, padded
with space (2016) characters.
32 HT7 – HT0 Header block type (1 byte, unsigned binary). Set to 1116 for Survey Area Name.
8.6 GENERAL HEADER BLOCK #6 (Client Identification) (optional)
This block contains the name/description of the client.

BYTE
_____ _____________ __________________________________________
1–31 CI Client Identification (ASCII text). 31 character client name/identification

which properly identifies the client for this survey. Left justified, padded with
space (2016) characters.
32 HT7 – HT0 Header block type (1 byte, unsigned binary). Set to 1216 for Client Identifica-
tion.
8.7 GENERAL HEADER BLOCK #7 (Job identification) (optional)
This block contains the name/description of the job/survey.

BYTE
_____ _____________ __________________________________________
1–5 JIA Abbreviated Job Identification (5 characters ASCII). May be used on tape
labels etc. Left justified, padded with space (2016) characters. May be blank if
no abbreviation exists.
6–31 JI Job Identification (ASCII text). 26 character job name/number/identification

which properly identifies the survey within the enterprise. Left justified,
padded with space (2016) characters.
32 HT7 – HT0 Header block type (1 byte, unsigned binary). Set to 1316 for Job Identification.
8.8 GENERAL HEADER BLOCK #8 (Line identification) (optional)

This block contains the description of current line. Mainly targeted to Marine operations, however any recorder might use
this field for line/swath related information. Make sure the information here matches the sequence number in General
Header Block #2, bytes 21–22.

BYTE
_____ _____________ __________________________________________
1–7 LA Line Abbreviation (ASCII text). 7 character line abbreviation (e.g. line number,
though letters are allowed) which uniquely identifies the line within the survey.
This is typically the pre-plot line number without information about sequence-
number, line type (primary/in-fill/reshoot, etc.) Left justified, padded with
8–31 LI Line Identification (ASCII text). 24 character line name/identification which

uniquely identifies the line within the survey/job. Left justified, padded with
32 HT7 – HT0 Header block type (1 byte, unsigned binary). Set to 1416 for Line Identification.
8.9 SOURCE DESCRIPTION BLOCK (optional)
Source description blocks may be inserted into the General Header or relevant Trace Headers (e.g. source auxiliary traces),
depending on what is most useful. It is also allowed to replicate Source Description Blocks in the General Header and
Trace Headers if that may improve decoding and use of the data.
If multiple source events exist inside the same record, it is required to insert multiple Source Description Blocks
describing each of the source events. If the source event does not occur at time zero for the SEG-D record, an Additional
Source Info block must be inserted after each source block and the time of the event must be properly stored in bytes 1–8.
If source auxiliary traces are stored in the record, the source description block may be followed by Source Auxiliary
Channel Reference blocks describing which traces contain more information regarding the sources.
See Appendix E.7 for examples of how to encode source information.
8.9.1 VIBRATOR

BYTE
_____ _____________ _________________________________________________
1–3 EF23 – EF0 Expanded File Number (three bytes, unsigned binary). This must be the same
value as the file number specified in General Header #1 bytes 1-2 or General
Header #2 bytes 1-3. For file numbers greater than 9999, bytes 1 and 2 of the
General Header Block #1 must be set to FFFF16.
4–6 SLN23 – SLN0 Source Line Number, Integer (three bytes, two’s complement, signed binary).
The Source Description Block contains the source location for one

Source/Source Set. Additional Source Description blocks may be used to
provide position information for additional Sources/Source sets.
7,8 SLN–1 – SLN–16 Source Line Number, Fraction (two bytes, fixed binary point). The two’s
complement integer formed by Bytes 4–8 is always equal to 65536 times the full
Source Line Number.
9–11 SPN23 – SPN0 Source Point Number, Integer (three bytes, two’s complement, signed binary).
12,13 SPN–1 – SPN–16 Source Point Number, Fraction (two bytes, fixed binary point). The two’s
complement integer formed by Bytes 9–13 is always equal to 65536 times the
full Source Point Number.
14 SPI7 – SPI0 Source Point Index (one byte, unsigned binary). This index allows several
locations for the source in the grid, the original value is one and that value is
incremented by one every time the source is moved, even when it is moved back
to a previous location. A zero value means that the Source Point Index is not
recorded.
15 PC7 – PC0 Phase Control (unsigned binary). Identifies the signal used to control the phase
of the vibrator output. Assumes following the 1991 Vibrator Polarity Standards:
0016 Phase Control not recorded
0116 Baseplate accelerometer
0216 Reaction Mass
0316 Weighted sum (baseplate acceleration times mass
plus reaction mass acceleration times its mass)
0416 Direct force measurement
It is anticipated that additional codes will be added later. If Phase Control is set
to Zero then the Phase Angle (Bytes 17, 18) is undefined.
16 V7 – V0 Type Vibrator (unsigned binary).

0016 Type not recorded
0116 P wave vibrator
0216 Shear wave vibrator
0316 Marine vibrator
Other types may be added later.
17,18 PA15 – PA0 Phase Angle (two bytes, two’s complement, signed binary). The Phase angle of
the intercept of the pilot signal with respect to the phase feedback signal,
measured in degrees. Phase Angle is set to zero when Phase Control (Byte 15)
is zero (Phase Control not recorded).
19 SI7 – SI0 Source Id (one byte, unsigned binary). The source id is a unique number
assigned to each source in the survey. 0 means unknown (same as source set).
20 SS7 – SS0 Source Set Number (one byte, unsigned binary). Used to allow multiple sets of
sources. Zero means this source id is not part of a source set (may be a source
set by itself).
21 RI7 – RI0 Re-shoot Index (one byte, unsigned binary). The re-shoot index is used to
indicate that this shot has been recorded earlier, and this record should replace
it. Re-shoot index starts at 0 (indicates recorded for first time).

22 GI7 – GI0 Group Index (one byte, unsigned binary). Group index is used to indicate this
record is part of a set of records needed to be processed as a unit. This may be a
stack fold number/vibrator sweep number in case of recording records that must
be stacked prior to processing, or phase index in case of HFVS type of
acquisition, where a group of records must be processed to do source separation
prior to data processing. 0 means source is not part of a group
23 DI7 – DI0 Depth Index (one byte, unsigned binary). The depth index is used to indicate
sources fired at different depths on the same location. 0 is not allowed.
24,25 OX15 – OX0 Offset cross-line (two bytes, two’s complement, signed binary). Cross-line
offset is number of centimeters (1/100 meter) the source is located from the
position indicated by the line/point index number. Used to organize groups of
sources firing at the same logical source point, but with different offsets. The
offset may be nominal or actual. Set to -32768 (800016) to indicate unknown
offset.
26,27 OI15 – OI0 Offset in-line (two bytes, two’s complement, signed binary). In-line offset is
number of centimeters (1/100 meter) the source is located from the position
indicated by the line/point index number. Used to organize groups of sources
firing at the same logical source point, but with different offsets. The offset may
be nominal or actual. Set to -32768 (800016) to indicate unknown offset.
28,29 SZ15 – SZ0 Size (two bytes, unsigned binary). The size of the source. For vibrator this is the
total peak force generated by the vibrators associated with this source. Unit 100
pound force, i.e. if 4 vibrators of a peak force of 70000lbs is combined in this
source, the value of this field is set to 2800. Set to 0 if unknown.
30,31 OD15 – OD0 Offset depth (two bytes, two’s complement, signed binary). Offset depth offset
is number of centimeters (1/100 meter) the source is located from the position
indicated by the line/point index number. Positive direction upwards. Used to
organize groups of sources firing at the same logical source point, but with
different offsets. The offset may be nominal or actual. Set to -32768 ( 800016) to
indicate unknown offset.
32 HT7 – HT0 Header type (one byte, unsigned binary). The header type indicates what type of
information is contained in this header. For Vibrator source this byte is set to
1516.
8.9.2 EXPLOSIVE

BYTE
_____ _____________ ___________________________________________________
provide position information for additional Source/Source sets.

Source Line Number.
to a previous location. Zero value means that the Source Point Index is not
recorded.
15,16 DE15 – DE0 Depth (two bytes, unsigned binary). Nominal shot depth in centimeters (1/100
meter). Set to 0 if unknown.
17 CL7 – CL0 Charge length (one byte, unsigned binary). Length of charge in decimeters
(1/10 meter). Set to 0 if unknown.
18 ST7 – ST0 Soil Type (one byte, unsigned binary). This is the nominal type of soil or near
surface medium. The following types are defined
0016 Water
0116 Alluvium
0216 Dry sand
0316 Weathering
0416 Mud
0516 Glacial
0616 Shale
0716 Sand
0816 Sandstone
0916 Limestone
0A16 Granite
0B16 Chalk
0C16 Gypsum
0D16 Salt
0E16 Gabbro
FF16 Other
Other types may be added later.
set by itself).

record is part of a set of records needed to be processed as a unit. 0 means
source not part of a group..
offset.
28,29 SZ15 – SZ0 Size (two bytes, two’s complement, signed binary). The size of source. For
explosive this is the size of charge in grams. Set to 0 if unknown.
information is contained in this header. For Explosive source this byte is set to
1616.
8.9.3 AIRGUNs

BYTE
_____ _____________ ___________________________________________________

Source Line Number.
recorded.
15,16 DE15 – DE0 Depth (two bytes, unsigned binary). This is the nominal depth from the water
surface in centimeters (1/100 meter) for this source. Allows values of 0–655.35
meters. Set to 0 if unknown.
17,18 AP15 – AP0 Air Pressure (two bytes, unsigned binary). The nominal operating air pressure
Unit is PSI. Set to 0 if unknown.
set by itself).
record is part of a set of records needed to be processed as a unit.0 means source
not part of a group.
offset.

Airgun this is the combined volume of the guns associated with this source ID.
Unit cubic inches. Set to 0 if unknown.
information is contained in this header. For Airgun source this byte is set to
1716.
8.9.4 WATERGUN

BYTE
_____ _____________ ___________________________________________________
Source Line Number.
recorded.
15,16 DE15 – DE0 Depth (two bytes, unsigned binary). This is the nominal depth from the water
surface in centimeters (1/100 meter) for this source. Set to 0 if unknown.
17,18 AP15 – AP0 Air Pressure (two bytes, unsigned binary). The nominal operating air pressure
Unit is PSI. Set to 0 if unknown.

set by itself).
source not part of a group.
offset.
Watergun this is the total volume of guns associated with this source ID. Unit
cubic inches. Set to 0 if unknown.
information is contained in this header. For Watergun source this byte is set to
1816.
8.9.5 ELECTROMAGNETIC

BYTE
_____ _____________ ___________________________________________________

Source Line Number.
recorded.
15 ST7 – ST0 EM Source Type (one byte, unsigned binary). One of the following source
types:
0016 Unknown
0116 Dipole
0216 Loop Coil
0316 Airborne
0416 Open Loop
0516 Closed loop
0F16 Other
16–18 MO23 – MO0 Source Moment (three bytes, unsigned binary). The source moment in
AmpereMeter (for Dipole source) or AmperMeter2 (for Coil source). Set to 0 if
unknown.
set by itself).

source not part of a group.
offset.
28,29 CV15 – CV0 Source Current or Voltage (two bytes, unsigned binary). The source current (in
Ampere) or voltage (in Volts), depending on the source type. Set to 0 if
unknown.
information is contained in this header. For Electromagnetic source this byte is
set to 1916.
8.9.6 OTHER SOURCE

BYTE
_____ _____________ ___________________________________________________
4,5,6 SLN23 – SLN0 Source Line Number, Integer (three bytes, two’s complement, signed binary).
Source/Source Set. Additional Source Description Blocks may be used to

Source Line Number.
recorded.
15,16,17,18 X Unused, may have any value.
set by itself).
source is not part of a group.
sources firing at the same logical source point, but with different offset to it. The
offset.
firing at the same logical source point, but with different offset to it. The offset
may be nominal or actual. Set to -32768 (800016) to indicate unknown offset.
28,29 X Unused space, may have any value.
information is contained in this header. For Other Source this byte is set to 1F16.
8.10 ADDITIONAL SOURCE INFO (optional)


BYTE
_____ _____________ ___________________________________________________
1–8 T63 – T0 Time (eight bytes, SEG-D timestamp). A time of 0 is allowed, and will indicate
source fired at start of record (time as indicated in General Header Block #3,
bytes 1 to 8).
9 SST7 – SST0 Source Status (1 byte, unsigned binary)

. 0016 Untested/unknown status
0116 Source fired OK
1216 Timing error
1316 Mechanical failure
1416 Software error
1516 Hydraulics failure
1616 Air leakage
1716 Power failure
1816 Communication failure
FF16 Unknown error
Used to determine which source block this block belongs to.
11 MV7 – MV0 Source Moving (one byte, unsigned binary). Source moving or stationary flag.
Set to 1 if source is moving during the record, 0 if stationary.
12–31 ED Error Description (20 bytes, ASCII text). Error description in free text as
defined by the recorder. The text should be a human readable string. "OK"
should be used to indicate the source fired OK, however if another string would
better represent the status, the recorder is free to do so. Field is left justified, and
unused characters should be filled with spaces (2016).
information is contained in this header. For Additional Source Info this byte is
set to 2016.
8.11 SOURCE AUXILIARY CHANNEL REFERENCE (optional)


This block is inserted into the General Header (or Trace Header) after the Source Description Block to indicate which
auxiliary channels contain information data regarding the source. Multiple Source Auxiliary Channel Reference blocks
may be used for each source if necessary. May be inserted into (auxiliary source) trace headers to indicate which (other)
traces are related to the source.
A value of 0 for Source Id, Scan Type Number, Channel Set Number and Trace Number means no channel referenced.

BYTE
_____ _____________ ___________________________________________________
assigned to each source in the survey.
2 ST11, ST12 Channel 1, Scan Type Number (one byte, two digit, BCD). Currently only
values 1–99 allowed.
3,4 CS115 – CS10 Channel 1, Channel Set Number (two bytes, unsigned binary).
5–7 TN123 – TN10 Channel 1, Trace Number (3 bytes, unsigned binary).
11–13 TN223 – TN20 Channel 2, Trace Number (three bytes, unsigned binary).
17–19 TN323 – TN30 Channel 3, Trace Number (three byte, unsigned binary).
21, 22 CS415 – CS40 Channel 4, Channel Set Number (two bytes, unsigned binary).
23–25 TN423 – TN40 Channel 4, Trace Number. (three byte, unsigned binary).
27, 28 CS515 – CS50 Channel 5, Channel Set Number (two bytes, unsigned binary).
29–31 TN523 – TN50 Channel 5, Trace Number (three bytes, unsigned binary).
information is contained in this header. For Source Auxiliary Channel Reference

8.12 COORDINATE REFERENCE SYSTEM IDENTIFICATION (conditional)
This header block is mandatory if a position block is included in the record.

BYTE
_____ _______________ __________________________________________
1–31 CRID CRS ID (31 bytes, ASCII text). The coordinate reference system (CRS)
identification in a textual format as defined in Appendix D. The string contains
all stanzas (including Location Data and Location Data Transformation stanzas)
used in the record, concatenated into a continuous string. It is recommended that
each stanza is separated by a newline terminator ('\n', 0A16) or Carriage
Return/LineFeed ("\r\n", 0D0A16).The string is split into 31 byte blocks, and
stored in multiple, consecutive CRS identification blocks as part of the General
Header. Text is left justified, the block is padded with space (2016) characters if
needed.
information is contained in this header. For Coordinate Reference System
Identification this byte is set to 5516.
8.13 POSITION BLOCKS (optional)
The location of the Position blocks in the header will determine what the position refers to, i.e. the Position blocks will
describe the position of the blocks they follow. For example: Position blocks following a Source Description block will
describe the position of the source, Position blocks following a Demux Trace Header will describe the position of the
trace, and Position blocks following a Measurement block will describe the position of the measurement.
Note: There may be other blocks between the Position blocks and the block they describe the position of (see e.g. the
Source block description in Section 5.1).

BYTE
_____ ________________________________________________________________
1–8 TP63 – TP0 Time of position (eight bytes, SEG-D timestamp). Time to which this position
applies, i.e., sample time.
9–16 TC63 – TC0 Time of measurement/calculation (eight bytes, SEG-D timestamp). Time the
position was measured or calculated.
17–20 VE31 – VE0 Vertical error quality estimate: 95% precision estimate in same units as vertical
coordinate (four bytes, IEEE float). Set to 0 if coordinate reference type only
uses the horizontal plane. Set to infinity (exponent all bits set, mantissa all
zeroes) if not available.
21–24 HEA31 – HEA0 Horizontal error quality estimate: 95% error ellipse semi-major axis in same
units as horizontal coordinate (four bytes, IEEE float). Set to 0 if coordinate
reference type only uses the vertical plane. Set to infinity (exponent all bits set,

mantissa all zeroes) if not available. HEA, HEB and HEO must all be valid, or
all be infinity.
25–28 HEB31 – HEB0 Horizontal error quality estimate: 95% error ellipse semi-minor axis in same
units as horizontal coordinate (four bytes, IEEE float). Set to 0 if coordinate
reference type only uses the vertical plane. Set to infinity (exponent all bits set,
mantissa all zeroes) if not available. HEA, HEB and HEO must all be valid, or
all be infinity.
29–30 HEO15 – HEO0 Horizontal error quality estimate: Bearing of error ellipse semi-major axis (two
bytes, unsigned binary). Orientation to map grid north in steps of 1/100 of a
degree. Set to 0 if coordinate reference type only uses the vertical plane. Set
FFFF16 if not available. HEA, HEB and HEO must all be valid, or all be
infinity.
31 PT7 – PT0 Position type (one byte, unsigned binary). The type of position, the following
types are supported:
0116 Planned/preplot
0216 Measured
0316 Processed
0416 Final
0F16 Unknown
32 HT7 – HT0 Header block type (one byte, unsigned binary). Set to 5016 for Position Block 1.

BYTE
_____ ________________________________________________________________
33–40 T1C163 – T1C10 First coordinate for coordinate tuple 1 (eight bytes, IEEE double float). This
coordinate and its unit is as given in the CRS definition in the location data
stanza identified through ID1. Set to infinity (exponent all bits set, mantissa all
zeroes) if CRS type is one-dimensional i.e. vertical.
41–48 T1C263 – T1C20 Second coordinate for coordinate tuple 1 (eight bytes, IEEE double float). This
49–56 T1C363 – T1C30 Third coordinate for coordinate tuple 1 (eight bytes, IEEE double float). This
zeroes) if CRS type is two-dimensional (projected or geographic 2D).
57–58 ID115 – ID10 Location Data Stanza ID 1 (two bytes, unsigned binary). Location Data Stanza
ID of the CRS for coordinate tuple 1. Defined in the Coordinate Reference
System Identification blocks of the record header. Please refer to Appendix D
for a description of the Coordinate Reference System Identification format.
Range 0 to 65535. A value of 0 means unknown Location Data Stanza ID.
59 PV17 – PV10 Position 1 Valid (one byte, unsigned binary). Position 1 valid flag. Set to 1 if
position coordinates are valid, 0 if not.
60 PQ17 – PQ10 Position 1 Quality (one byte, unsigned binary). Position 1 quality flag.
Supported values:
0016 Position 1 not present
0116 Position is good
0216 Quality uncertain
0316 Position is bad, not to be used
This field must always be filled in. The field will be an interpretation of VE,
HEA, HEB and HEO (bytes 17–30) if available.
61–63 X Undefined

BYTE
_____ ________________________________________________________________
65–72 T2C163 – T2C10 First coordinate for coordinate tuple 2 (eight bytes, IEEE double float). This
73–80 T2C263 – T2C20 Second coordinate for coordinate tuple 2 (eight bytes, IEEE double float). This
81–88 T2C363 – T2C30 Third coordinate for coordinate tuple 2 (eight bytes, IEEE double float). This
zeroes) if CRS type is two-dimensional (projected or geographic 2D).
89–90 ID215 – ID20 Location Data Stanza ID 2 (two bytes, unsigned binary). Location Data Stanza
ID of the CRS for coordinate tuple 2. Defined in the Coordinate Reference
System Identification blocks of the record header. Please refer to Appendix D
for a description of the Coordinate Reference System Identification format.
Range 0 to 65535. A value of 0 means unknown Location Data Stanza ID
91 PV27 – PV20 Position 2 Valid (one byte, unsigned binary). Position 2 valid flag. Set to 1 if
position coordinates are valid, 0 if not.
92 PQ27 – PQ20 Position 2 Quality (one byte, unsigned binary). Position 2 quality flag.
Supported values:
0016 Position 2 not present
0116 Position is good
0216 Quality uncertain
0316 Position is bad, not to be used
This field must always be filled in. The field will be an interpretation of VE,
HEA, HEB and HEO (bytes 17–30) if available.
93–95 X Undefined
8.14 RELATIVE POSITION BLOCK (optional)
The header block describes a position relative to the position described by the 96 byte position header. A textual
description is included.
Relative offset is in projection/grid coordinates only. Follows directly after the position header to which it is relative.
Multiple relative positions might be connected to the same position header, e.g. to describe the front and tail of source
(Position Header describes center of source).

BYTE
_____ ________________________________________________________________
1–4 OE31 – OE0 Offset Easting (four bytes, IEEE float). Offset in projected (grid) coordinates
in easting direction, in units given in projected CRS definition. Note that (i)
although given first here, easting may not be the first coordinate given in
Position Header block, (ii) SEG-D only allows horizontal offsets to be given in
projected terms.
5–8 ON31 – ON0 Offset Northing (four bytes, IEEE float). Offset in projected (grid) coordinates
in northing direction, in units given in projected CRS definition. Note that (i)
although given second here, northing may not be the second coordinate given
in Position Header block, (ii) SEG-D only allows horizontal offsets to be given
in projected terms.
9–12 OD31 – OD0 Offset Vertical (four bytes, IEEE float). Offset in vertical direction, in units
given in vertical CRS definition. Note that whether a positive offset is a height
or a depth is defined in the CRS Header.
13–31 DE Description (19 bytes, ASCII text). Manufacturer defined, textual description
of the equipment. Left justified, padded with space (ASCII 2016).
32 HT7 – HT0 Header block type (one byte, unsigned binary). Set to 5616 for Relative Position
Block.

8.15 SCAN TYPE HEADER (channel set descriptor)
The scan type header is determined by the system configuration and consists of one or more channel set descriptors each
of 96 bytes followed by a series of 32 byte sample skew fields. A channel set is defined as a group of channels operating
with the same set of parameters and being sampled as part of a scan of data. A scan type header can be composed of
from 1 to 65535 channel set descriptors. If dynamic parameter changes are required during the recording, additional scan
type headers must be added, each containing the channel set descriptors necessary to define the new parameters. Each
scan type header must have the same number of channel set descriptors.
8.16 CHANNEL SET DESCRIPTOR

BYTE
_____ _____________ ____________________________________________________
1 ST1, ST2 These two digits (one byte BCD) (1–99) identify the number of the scan type
header to be described by the subsequent bytes. The first scan type header is 1
and the last scan type header number is the same value as Byte 28 (ST/R) of the
General Header Block #1. If a scan type header contains more than one channel
set descriptor, the scan type header number will be repeated in each of its
channel set descriptors. If the system does not have dynamic parameter changes
during the record, such as switched sampling intervals, there will only be one
scan type header required.
2,3 CS15 – CS0 Channel Set Number (two bytes, unsigned binary). These digits (1–65535)
identify the channel set to be described in the next 94 bytes within this scan type
header. The first channel set is "1" and the last channel set number is the same
number as Byte 29 (CS) of the General Header Block #1 (or bytes 4-5 (EN) of
General Header #2 if Extended Channel Sets/Scan Type is used). If the scan
actually contains fewer channel sets than CS, then dummy channel set
descriptors are included as specified in Byte 29 of General Header Block #1 /
bytes 4-5 of General Header #2.
4 C7 – C0 Channel type Identification (one byte, unsigned binary).
0016 Unused
1016 Seis
1116 Electromagnetic (EM)
2016 Time break
2116 Clock timebreak
2216 Field timebreak
3016 Up hole
4016 Water break
5016 Time counter
6016 External Data
6116 Acoustic range measurement
6216 Acoustic reference measured (correlation reference)
6316 Acoustic reference nominal (correlation reference)
7016 Other
8016 Signature/unfiltered
9016 Signature/filtered
9116 Source signature/unfiltered
9216 Source signature/filtered

9316 Source signature/estimated
9416 Source signature/measured
9516 Source base plate
9616 Source reference sweep
9716 Source other
9816 Source reference pilot
9916 Source mass
A016 Auxiliary Data Trailer (no longer used)
B016 True reference sweep (correlation reference)
B116 Radio reference sweep
B216 Radio similarity signal
B316 Wireline reference sweep
C016 Depth
C116 Wind
C216 Current
C316 Voltage
C416 Velocity
C516 Acceleration
C616 Pressure
C716 Tension
C816 Tilt measurement
C916 Angle measurement
F016 Calibration trace (time series)
5–8 TF31 – TF0 Channel set start time (four bytes, two’s complement, signed binary). This is a
microsecond (1/1000000 second) unit of measurement. This number identifies
the timing word of the first scan of data in this channel set. In a single scan type
record, this would typically be recorded as a zero (an exception might be deep
water recording). In multiple scan type records, this number represents the
starting time, in microseconds, of the channel set. Start times from
−2,147,483,648 to 2,147,483,647 (in 1-μsec increments) can be recorded. In
Extended Recording mode (byte 29 of General Header #3 set to 1) this field is
not used, and should be set to 0. By setting TF and TE to 0, the manufacturer
can use a Timestamp Header in each trace to allow recording data over a larger
time span than the normal +/- 2147 seconds even without utilizing the Extended
Recording Mode (i.e. byte 29 of General Header #3 set to 0). This also allows
recording traces with different start points within the same channelset. Note: All
other limitations on channel sets as defined in section ”5.2 Scan Type Headers”
still applies. Also note: TF and TE must be set to 0 if a Timestamp header is
used to indicate trace start time.
9–12 TE31 – TE0 Channel set end time (four bytes, two’s complement, signed binary). This is a
microsecond (1/1000000 second) unit of measurement. This number represent
the record end time of the channel set in microseconds. TE may be used to allow
the termination of a particular channel set shorter than other channel sets within
its scan type. In a single scan type record starting at time zero, Bytes 9–12
would be the length of the record. End times from −2,147,483,648 to
2,147,483,647 μsec (in 1-μsec increments) can be recorded. In Extended
Recording mode (byte 29 of General Header #3 set to 1) this field is not used,
and should be set to 0. By setting TF and TE to 0, the manufacturer can use a
Timestamp Header in each trace to allow recording data over a larger time span
than the normal +/- 2147 seconds even without utilizing the Extended Recording
Mode (i.e. byte 29 of General Header #3 set to 0). This also allows recording
traces with different start points within the same channelset. Note: All other
limitations on channel sets as defined in section ”5.2 Scan Type Headers” still
applies. Also note: TF and TE must be set to 0 if a Timestamp header is used to
indicate trace start time.
13–16 NS31 – NS0 Number of samples in each trace of this channel set (four bytes, unsigned
binary). It can assume a value from 0 to 4,294,967,295. For the purpose of this
SEG-D standard, the number of samples NS, sampling interval SR, channel set
start time TF, and channel set end time TE should be related by the formula
TE=TF+NS×SR.
17–20 DSM31 – DSM0 Sample descale multiplication factor (four bytes, IEEE float). The multiplier is
be used to descale the data on tape to obtain input voltage in millivolts.
21–23 C/S23 – C/S0 Number of channels in this channel set (three bytes, unsigned binary). It can
assume a value from 0 to 16,777,215.
24–26 SR23 – SR0 Sampling Interval (three bytes, unsigned binary). This is a microsecond
(1/1000000 second) unit of measurement. It can assume a value from 0 to
16,777,215.
27 ARY7 – ARY0 Array Forming (one byte, unsigned binary). Identifies whether the data in this
channel set is the result of array forming.
0116 No array forming.

0216 2 groups summed, no weighting.
0N16 N groups summed, no weighting.
1N16 N groups weighted, overlapping, summation.
28 THE7 – THE0 Number of Trace Header Extensions (one byte, unsigned binary). Must match
byte 10 of the Demux Trace Header. Range 1-255. 0 is not allowed.
29 EFH3 – EFH0, Extended Header flag (half byte, unsigned binary). Set to 1 to indicate that the
extended header contains additional information on the channel set.
29 J Channel gain control method (half byte, unsigned binary).
116 Individual AGC

216 Ganged AGC
316 Fixed gain
416 Programmed gain
816 Binary gain control
916 IFP gain control

30 VS7 – VS0 Vertical Stack (one byte, unsigned binary). Effective stack order. Set to zero if
the trace data was intentionally set to real zero. Set to one if no stack. Set to the
effective stack order if the data is the result of stacked data (with or without
processing).
31 CAB7 – CAB0 Streamer Cable number (one byte, unsigned binary). Required for streamer data
only. Identifies the number of the streamer cable that will be identified in this
block. The starboard-most cable is identified as cable 1 while the Port most
cable is N. Zero means that the Streamer Cable number has not been recorded.
32 HT7 – HT0 Header block type (one byte, unsigned binary). Set to 3016 for Channel Set
Descriptor block 1.
33–36 AF31 – AF0 Alias filter frequency in Hz (four bytes, IEEE float).
37–40 LC31 – LC0 Low-cut filter setting in Hz (four bytes, IEEE float).
41–44 AS31 – AS0 Alias filter slope in dB per octave (four bytes, IEEE float). A zero indicates the
filter is out. (See Appendix E3 for definition.)
45–48 LS31 – LS0 Low-cut filter slope (four bytes, IEEE float). A zero indicates the filter is out.
(See Appendix E3 for definition.)
49–52 NT131 – NT10 Notch frequency setting (four bytes, IEEE float). The out filter is written as 0.0
Hz.
The following notch filters are coded in a similar manner:
53–56 NT231 – NT20 Second notch frequency

57–60 NT331 – NT30 Third notch frequency
61 FPH7 – FPH0 Filter phase (one byte, unsigned binary).

0016 Unknown
0116 Minimum
0216 Linear
0316 Zero
0416 Mixed
0516 Maximum
62 PHU7 – PHU0 Physical unit (one byte, unsigned binary). This is the physical unit measured by
this sensor.
0016 Unknown
0116 Millibar
0216 Bar
0316 Millimeter/second
0416 Meter/second
0516 Millimeter/second/second
0616 Meter/second/second
0716 Newton
0816 Kelvin
0916 Hertz
0A16 Second
0B16 Tesla
0C16 Volt/meter
0D16 Volt meter
0E16 Ampere/meter
0F16 Volt
1016 Ampere
1116 Radians (angle)
1216 Pascal
1316 Micropascal
63 X These bits are undefined by the format and may have any value. Note: In future
versions these may be defined, so use with caution.
Description block 2.
65–68 FDL31 – FDL0 Filter delay (four bytes, unsigned binary). The signal delay introduced by the
filter in microseconds.
69–95 DSC Description (27 bytes, ASCII text). Channel set description 27 byte free-text as
defined by the recording system. Left justified, padded with spaces (2016) for
unused characters. zero (0016) is not allowed.
Descriptor block 3.
8.17 DEMUX TRACE HEADER

BYTE
_____ ______________________________________________________________
1,2 F1 – F4 File Number (two bytes, four digits, BCD). These bytes must be set to FFFF16
when the file number is above 9999, i.e. the Extended File Number (bytes 18–
20) is used.
3 ST1 – ST2 Scan Type Number (one byte, two digits, BCD). (1-99) Scantype this trace
belongs to, see Channel Set Descriptor byte 1.
4 CN1 – CN2 Channel Set Number (one byte, two digits, BCD). (1-99) Channel Set this trace
belongs to, see Channel Set Descriptor byte 2-3. Set to FF16 if more than 99
channel sets are required, i.e. Extended Channel Set Number (byte 16–17) is
used.
5,6 TN1 – TN4 Trace Number (two bytes, four digits, BCD). (1-9999) Set to FFFF16 if more
than 9999 channels are required, i.e. Extended Trace Number (byte 22–24 of
Trace Header Extension) is used.
7–9 T15 – T−8 First Timing Word. (signed binary, two bytes integer, one byte fractional).
These bytes comprise the timing word that would accompany the first sample if
these data were written in the multiplexed format. To obtain the exact sample
timing, the actual sample skew time (byte 11 multiplied by the Channel Set
Sampling Interval) must be added to the time recorded in Bytes 7–9.

10 THE7 – THE0 Trace Header Extensions (one byte, unsigned binary). Indicates the number of
Trace Header Extension blocks (32 bytes each). Range 1-255. At least one
Trace Header Extension block (the Trace Header Extension, block type 4016) is
required. Channels within the same channel set must have the same number of
Trace Header Extensions. Value must be the same as byte 28 of the matching
Channel Set Descriptor.
11 SSK−1 – SSK−8 Sample Skew (one byte, binary fraction). The fractional skew value represents
the fractional part of the Channel Set Sampling Interval (Byte 24-26 of
Channel Set Descriptor.)
12 TR7 – TR0 Trace edit (one byte, unsigned binary).

0016 No edit applied to this trace.
0116 Trace part of dead channels for roll-on or roll-off spread. Trace
intentionally zeroed.
0216 Trace intentionally zeroed.
0316 Trace has been edited. This flag will indicate that the acquisition
system has modified one or more samples of this trace. Other codes
are undefined in Rev 3.0.
13–15 TW15 – TW−8 Time Break Window (three bytes, unsigned binary with two bytes integer and
one byte fraction). Bytes 13, 14, and 15 are included as an integrity check on
time break. They comprise the timing word of the scan in which TWI changed
to a one.
16,17 EN15 – EN0 Extended Channel Set Number (two bytes, unsigned binary). Allows Channel
Set Numbers beyond the 99 which can be indicated in byte 4. To allow
Channel Set Numbers greater than 99, or to allow use of a binary channel set
number, set byte 4 to FF16 and use bytes 16 and 17 for the Channel Set
Number.
18–20 EFN23 – EFN0 Extended File Number (three bytes, unsigned binary). Allows File Numbers
beyond the 9999 which can be indicated in bytes 1 and 2. To allow File
Numbers greater than 9999, or to allow use of a binary file numbers, set bytes 1
and 2 to FFFF16 and use bytes 18, 19, and 20 for the File Number.
8.18 TRACE HEADER EXTENSION #1

BYTE
_____ ________________________________________________________________
1–3 RLN23 – RLN0 Receiver Line Number (three bytes, two’s complement, signed binary).
4–6 RPN23 – RPN0 Receiver Point Number (three bytes, two’s complement, signed binary).
7 RPI7 – RPI0 Receiver Point Index (one byte, two’s complement, signed binary). This index
allows several locations for the receiver group in the grid, the original value is
1 and that value is incremented by 1 every time the receiver is moved, even
when it is moved back to the previous location). Receiver Point Index may also
be used for downhole seismic to extend the numerical range of the Depth
Index.
indicate that this receiver has been moved back here for a re-acquisition (shot
has been recorded earlier, and this record should replace it). Re-shoot index
starts at 0 (indicates recorded for first time).
receiver is part of a set of receivers needed to be processed as a unit. This could
be a component of a three-component sensor at a given location. 0 means
receiver is not part of a group.
receivers recorded at different depths on the same location. 0 is not allowed.
Starts at 1 closest to the surface, and counts up when moving downwards.
11–15 ERLN23 – ERLN−16 Extended Receiver Line Number (Signed binary, three bytes integer, two bytes
fractional). Allows fractional Receiver Line Numbers. Only valid if bytes 1–3
in this Trace Header Extension are set to FFFFFF16. The representation of a
negative receiver line number is the two’s complement of the integer formed
by multiplying the absolute value of the receiver line number by 65536.
16–20 ERPN23 – ERPN−16 Extended Receiver Point Number (Signed binary, three bytes integer, two bytes
fractional). Allows fractional Receiver Point Numbers. Only valid if bytes 4–
6 in this Trace Header Extension are set to FFFFFF16. The representation of a
negative receiver line number is the two’s complement of the integer formed
by multiplying the absolute value of the receiver line number by 65536.
21 SEN7 – SEN0 Sensor Type recorded on this trace (one byte, unsigned binary)
0016 Not defined
0116 Hydrophone (pressure sensor)
0216 Geophone (velocity sensor) Vertical
0316 Geophone, Horizontal, inline
0416 Geophone, Horizontal, cross-line
0516 Geophone, Horizontal, other
0616 Accelerometer, Vertical
0716 Accelerometer, Horizontal, inline
0816 Accelerometer, Horizontal, crossline
0916 Accelerometer, Horizontal, other
1516 Electric Dipole

1616 Magnetic coil
other values are not defined at the present time
22–24 ETN23 – ETN0 Extended Trace Number (three bytes, unsigned binary). Extended trace number
to allow up to 16,777,215 traces in one channel set. Field is only valid if bytes
5–6 in Demux Trace Header is set to FFFF16.
25–28 NS31 – NS0 Number of samples in this trace (four bytes, unsigned binary) It can assume a
value from 0 to 4,294,967,295. This must be the same as bytes 13–16 of
channel set descriptor.
29 MV7 – MV0 Sensor moving (one byte, unsigned binary). Sensor moving or stationary. Set to
1 if sensor is moving during the record, 0 if it is stationary.
30 X Undefined
31 PHU7 – PHU0 Physical unit (1 byte, unsigned binary). This is the physical unit measured by
this sensor. Same as byte 62 of the channel set header
32 HT7 – HT0 Header block type (1 byte, unsigned binary) Set to 4016 for Trace header
extension 1.
8.19 SENSOR INFO HEADER EXTENSION (optional)

BYTE
_____ ________________________________________________________________
1–8 ITT63 – ITT0 Equipment Test Time (SEG-D 8 byte timestamp). Time of last test. Set to 0 if
not recorded.
9–12 STY31 – STY0 Sensor Sensitivity (four bytes, IEEE float). This is the signal sensitivity for the
sensor. Divide the sample value by this number to achieve a physical unit (as
specified in bytes 31). Set to 0 if not specified (physical unit unknown).
13 ITR7 – ITR0 Equipment Test Result (one byte, unsigned binary).

The following values are allowed
0016 Unknown (untested)
0116 Passed
0216 Failed
0316 Uncertain (warning during IT)
14–31 SN Serial Number (18 bytes, ASCII text) . Serial number of sensor for this
receiver. Left-justified, padded with space (2016) characters.
32 HT7 – HT0 Header block type (one byte, unsigned binary). Set to 4116 for Sensor Info
Header Extension.
8.20 TIMESTAMP HEADER (optional)

BYTE
_____ _______________ __________________________________________
1–8 TZD63 – TZD0 Time Zero for this data block (eight bytes, SEG-D timestamp). The time of
first sample in the data described by this header. (The actual sample time is
calculated as Time Zero + Sample Skew + First Timing Word.) Typically
inserted into Trace Header in Extended Recording Mode, the timestamp is then

the time of first sample in the trace. If the recorder does not know the absolute
time, this timestamp must be relative to the timestamp in General Header Block
#3 (bytes 1–8), i.e. number of microseconds since time zero of the record.
9–31 X These byte fields are undefined by the format and may have any value. Note: In
type of information is contained in this header. See Table 2 for an overview of
header types. Set to 4216 for Timestamp Header.
8.21 SENSOR CALIBRATION HEADER (optional)
Use of the sensor calibration header supports between 1 and a maximum of approximately 500 points (the maximum size
of the trace header). The maximum depends on what other blocks are present in the trace header. If a higher resolution
calibration is required, a calibration channel/channelset must be created.

BYTE
_____ _______________ __________________________________________
1–4 FR131 – FR10 Frequency 1 (four bytes, IEEE float). The frequency of first calibration value.
Set to 0.0 if not used.
5–8 AM131 – AM10 Amplitude 1 (four bytes, IEEE float). The amplitude of first calibration value.
9–12 PH131 – PH10 Phase 1 (four bytes, IEEE float). The phase of first calibration value.
13–16 FR231 – FR20 Frequency 2 (four bytes, IEEE float). The frequency of second calibration
value. Set to 0.0 if not used.
17–20 AM231 – AM20 Amplitude 2 (four bytes, IEEE float). The amplitude of second calibration
value.
21–24 PH231 – PH20 Phase 2 (four bytes, IEEE float). The phase of second calibration value.
25 CA7 – CA0 Calibration applied (one byte, unsigned binary). Set to 1 if calibration has
already been applied, i.e. the trace has been corrected with the calibration
function described by the values in the Sensor Calibration Header blocks, set to
0 if trace is not corrected. Note: Multiple Sensor Calibration Header blocks are
usually needed to describe a calibration function.
26–31 X Undefined
type of information is contained in this header. See Table 2 for an overview of
header types. Set to 4316 for Sensor Calibration Header.

8.22 TIME DRIFT HEADER (optional)
This block may be used when data from sensors with drifting clocks are merged into one SEGD record. Data must be
clock drift corrected prior to creating a SEGD shot, i.e. SEGD only supports recording data with one single clock
reference system.

BYTE
_____ ________________________________________________________________
1–8 TD63 – TD0 Time of deployment (eight bytes, SEG-D timestamp). Time of sensor unit
deployment, i.e. when time drift was measured before deployment.
9–16 TR63 – TR0 Time of retrieval (eight bytes, SEG-D timestamp). Time of sensor unit
retrieval, i.e. when the time drift was measured after retrieval.
17–20 OD31 – OD0 Time offset at deployment (four bytes, two’s complement, signed binary).
Time offset value at deployment in number of microseconds. Range
approximately ±2147 seconds.
21–24 OR31 – OR0 Time offset at retrieval (four bytes, two’s complement, signed binary). Time
offset value at retrieval in number of microseconds. Range approximately
±2147 seconds.
25 TDC7 – TDC0 Time drift corrected (one byte, unsigned binary). Set to 1 if time drift
correction has been applied, 0 if not. Note: SEGD only supports recording data
from one clock reference system. Data must be time drift corrected prior to
record creation if data acquired from sensors with decoupled (drifting) clocks
is merged into one SEGD record.
26 CM7 – CM0 Time drift correction method (one byte, unsigned binary). Method used to
correct for time drift. The following methods are supported:
0016 Uncorrected
0116 Linear correction (values in this header used)
FF16 Other, manufacturer defined method used for correction
27–31 X Undefined
32 HT7 – HT0 Header block type (one byte, unsigned binary). Set to 4416 for Time Drift
Header.
8.23 ORIENTATION HEADER (optional)
The orientation header provides the means to specify the orientation at a given position for 3C data.

North
RX X
3C Sensor East
RY
RZ
Y
Z
Vertical (down)
Figure shows multicomponent measurements and their respective rotation

measurements relative to the reference system (north/east/vertical)
X is defined as in-line, Y is cross-line and Z is vertical. Positive vertical is down. The rotation follows the right-hand rule.
RX is defined as rotation around X axis, RY around Y axis, and RZ around Z axis. Positive value as defined by right-hand
rule. This means the axis and positive direction for the rotation angles around the axis are given by the right hand, as
indicated in the figures above.
X axis will for cable acquisition (towed streamers, seabed cables etc.) be along the cable.
The rotation measurement in the sensor is expected to result in a rotation to the horizontal plane, however rotation to true
north will in many cases require an external measurement. This value is hence extracted to a separate field in the rotation
header, and may also be recorded as 0 if not available at the time of acquisition.
 C north   R11 R12 R13  C x 

 C   
 east    R21 R22 R23  * C y  (1)
C vertical   R31 R32 R33  C z 
The rotation described in bytes 1–16 in the orientation header must fulfill equation (1) above. The group index for
multicomponent data must hence be numbered such that
1 = X axis
2 = Y axis
3 = Z axis

BYTE
_____ ________________________________________________________________
1–4 RX31 – RX0 Rotation angle around the X axis in radians (four bytes, IEEE float).
5–8 RY31 – RY0 Rotation angle around the Y axis in radians (four bytes, IEEE float).

9–12 RZ31 – RZ0 Rotation angle around the Z axis in radians (four bytes, IEEE float).
13–16 RO31 – RO0 Reference Orientation (four bytes, IEEE float). Rotation angle for the system
described in bytes 1–12 relative to true north, i.e. the rotation angle around the
Z axis for the X direction to point towards true north, This will be the cable
direction or housing orientation, depending of the value of byte 25. Recorded
as 0 if not applicable. If value is valid, byte 26 should be set to 1.
May be recorded as 0 if the value is unknown at the time of recording. The

value must then be made available to the processing/QC systems through other
means. Byte 26 should then be set to 0.
17–24 TS63 – TS0 Time Stamp (eight bytes, SEG-D timestamp). Timestamp for which the
rotation applies to, i.e. which sample the rotation applies to. Allows multiple
rotation measurements during a record. May be recorded as 0, the values then
applies to first sample in trace.
25 OT7 – OT0 Orientation Type horizontal plane (one byte, unsigned binary). The rotation
angle in bytes 9–12 is referenced to this coordinate system. The following
values are defined
0016 None/Unknown
0116 Earth true north
0216 Cable direction (e.g. marine/seabed
streamer)
0316 Sensor housing orientation
0416 Survey orientation
0516 Magnetic north
0916 Other
26 ROV7 – ROV0 Reference Orientation Valid (one byte, unsigned binary). Set to 1 if bytes 13–
16 contains a valid value, otherwise recorded as 0.
27 RA7 – RA0 Rotation Applied (one byte, unsigned binary). Set to 1 if rotation in bytes 1–12
has already been applied, otherwise recorded as 0. Allows recording of
orientation values for QC purposes even though the rotation has already been
done
28 RNA7 – RNA0 Rotation to North Applied (one byte, unsigned binary). Set to 1 if values in
traces has already been rotated to true north, otherwise recorded as 0. Rotation
in bytes 1–16 has been applied to trace values. Allows recording of orientation
values for QC purposes even though the rotation has already been done. If byte
28 is 1, byte 27 must also be set to 1.
29–31 X These bytes are undefined by the format and may have any value. Note: In
32 HT7 – HT0 Header block type (one byte, unsigned binary). Set to 6016 for Orientation
Header.

8.24 MEASUREMENT BLOCK (optional)
This block is used to standardize storage of different types of common measurements.
The Measurement Block may optionally be followed by a Position Block describing where the measurement was taken.

BYTE
_____ ________________________________________________________________
1–8 TS63 – TS0 Time Stamp (eight bytes, SEG-D timestamp). Timestamp for the measurement.
Timestamp for time related measurements like Uphole time should be set to
time zero for record (same as timestamp in General Header #3) if they are
measuring the offset from start of record.
9–12 VA31 – VA0 Measurement value (four bytes, IEEE float). Value of the measurement. Set to
NAN (Not a number, 7fffffff16) if not defined.
13–16 MA31 – MA0 Maximum Value (four bytes, IEEE float). Maximum possible/allowed value of
measurement. Set to NAN (Not a number, 7fffffff16) if not defined.
17–20 MI31 – MI0 Minimum Value (four bytes, IEEE float). Minimum possible/allowed value of
measurement. Set to NAN (Not a number, 7fffffff16) if not defined.
21–22 QC15 – QC0 Quantity Class (two bytes, unsigned binary). Code representing the underlying
kind of measurement represented by GM1 (e.g. length, time, pressure, etc.).
Please refer to the Energistics Quantity Class table located at
http://www.seg.org/web/technical-standards-committee/wiki/-
/wiki/Main/SegMeasurements for the definition of codes. Example: Set to 1069
for “length”. Appendix F contains a snapshot of the Energistics Quantity Class
table.
23-24 UOM15- UOM0 Unit of Measure (two bytes, unsigned binary). Code of Unit of Measure for the
measurement VA. Please refer to the Energistics Unit of Measure table located
at http://www.seg.org/web/technical-standards-committee/wiki/-
/wiki/Main/SegMeasurements for the definition of codes. Example: Set to 2066
for “m (metre)”. Appendix F contains a snapshot of the Energistics Unit of
Measure table.
25-26 MD15 – MD0 Measurement Description code (two bytes, unsigned binary). Code
representing the detailed description of the measurement VA. Please refer to
the Measurement Description table located at
http://www.seg.org/web/technical-standards-committee/wiki/-
/wiki/Main/SegMeasurements for the definition of codes. Example set to
050216 for “Equipment height”.
27-31 X Undefined.
32 HT7 – HT0 Header block type (one byte, unsigned binary). Set to 6116 for Measurement
Block.
8.25 ELECTROMAGNETIC SRC/RECV DESC BLOCK (optional)

BYTE
_____ ________________________________________________________________
1–3 LX23 – LX0 Equipment Dimension X direction (three bytes, unsigned binary). Length of
measurement equipment (e.g. antenna) in X (inline) direction in number of
centimeters (1/100 meters). Maximum length is 16777215 centimeters, or
approximately 16777 meters.
4–6 LY23 – LY0 Equipment Dimension Y direction (three bytes, unsigned binary). Length of
measurement equipment (e.g. antenna) in Y (crossline) direction in number of
7–9 LZ23 – LZ0 Equipment Dimension Z direction (three bytes, unsigned binary Length of
measurement equipment (e.g. antenna) in Z (height) direction in number of
10 PT7 – PT0 Positive terminal (one byte, unsigned binary). Determines the positive terminal
for the antenna. Bits 0–2 determines if the positive end (i.e. antenna end with
largest positive value) in X, Y and Z direction respectively is the positive
terminal. Set bit to 1 if positive end is positive terminal, 0 if it is negative.
Example: The antenna is 15 meters in inline direction, positive terminal is at

the positive end of the antenna. LX is set to 0005DC16, LY to 00000016, LZ to
00000016, PT to 0116.
Example 2: Antenna is 25 meters diagonally in X-Y direction, positive terminal

is negative X, positive Y value. Length in X and Y direction is
sqrt(252/2)=17.68 meters. LX is set to 0006E816, LY to 0006E816, LZ to
00000016, PT to
0216.
+ -
Inline(X)
Crossline(Y)
-
+
Example 1 Example 2

11–13 OX23 – OX0 Equipment Offset X direction (three bytes, two’s complement, signed binary).
Measurement equipment (e.g. antenna) offset from center of equipment in X
(inline) direction in number of centimeters (1/100 meters). Maximum offset is
+/-8388607 centimeters, or approximately 8388 meters.
14–16 OY23 – OY0 Equipment Offset Y direction (three bytes, two’s complement, signed binary).
Measurement equipment (e.g. antenna) offset from center of equipment in Y
(crossline) direction in number of centimeters (1/100 meters). Maximum offset
is +/-8388607 centimeters, or approximately 8388 meters.
17–19 OZ23 – OZ0 Equipment Offset Z direction (three bytes, two’s complement, signed binary).
Measurement equipment (e.g. antenna) offset from center of equipment in Z
(height) direction in number of centimeters (1/100 meters). Maximum offset is
+/-8388607 centimeters, or approximately 8388 meters.
20–31 X Undefined.
32 HT7 – HT0 Header block type (one byte, unsigned binary). Set to 4516 for Electromagnetic
Src/Recv Desc block
8.26 GENERAL TRAILER (Optional)
The general trailer consists of data block units of varying size. Each data block starts with a description block (32 bytes)
followed by data (either binary or ASCII) in a multiple of 32 bytes.
The content of the trailer data blocks is completely recording system defined. However, some types have been predefined
to simplify exchange of data. The predefined types (e.g. edits) can be found in table listed for Byte 1 in the General Trailer
Description block below.
Binary data padded with zeros (0016), ASCII data padded with spaces (2016), until 32 byte limit.
Layout of the general trailer will be like this:
[GT desc block (32 byte)][Block 1 (x*32 byte)][GTDB][Block 2][GTDB][Block 3]…
This is done to simplify appending data.
8.26.1 GENERAL TRAILER DESCRIPTION BLOCK (optional)
Field Description Bytes Start – end byte
1 Trailer Block type/id 1 1

2 ASCII/Binary data 1 2
Undefined (zero-filled) 2 3–4
3 Size (unsigned binary) 4 5–8

4 Description (ASCII) if type other 16 9–24
Undefined (zero-filled) 6 25–31
5 Header block type (7016) 1 32

BYTE
_____ _____________ ____________________________________________________
1 BT7 – BT0 Block type, (one byte, unsigned binary). This describes the type of data in this
block.
0116 Edits
1016 Text comments
1116 Observer log
2016 P1 processed navigation data
2116 P2 Raw marine positioning data
2216 P3 Land survey field data
2316 P5 Pipeline positioning data
2416 P6 3D seismic binning grids
2516 P7 Well deviation data
2616 SPS Shell Processing Support data
2716 SEG-Y Extended Textual Stanza
A016 – FF16 Other (user defined)
2 AB7 – AB0 ASCII or binary (one byte, unsigned binary). States if data in this block is
binary or ASCII text.
0116 Binary
0216 ASCII
3–4 X Undefined, set to 0.
5–8 SI31 – SI0 Block size (four bytes, unsigned binary). Number of 32 byte blocks in this data
block. Block size in bytes = 32 * SI
9–24 DE Description (16 bytes, ASCII). A description of the contents of this data block.
Must be filled out if block type is Other/User defined (A016 – FF16). Unused
characters are filled with ASCII space (2016) characters.
25–31 X Undefined, set to 0.
32 HT7 – HT0 Header block type (one byte, unsigned binary). Set to 7016 for General Trailer
Description Block.
Note: All types of trailer records are optional.

Appendix A: Manufacturers of Seismic Field Recorders
Code No. Manufacturer Name and Address

01 Alpine Geophysical Associates, Inc. (Obsolete)
65 Oak St.
Norwood, New Jersey
02 Applied Magnetics Corporation (See 09)
75 Robin Hill Rd.
Goleta, California 93017
03 Western Geophysical Exploration Products (formerly Litton Resources Systems)

3600 Briarpark Drive,
Houston, Texas 77042
04 SIE, Inc. (Obsolete)

5110 Ashbrook
05 Dyna-Tronics Mfg. Corporation (Obsolete)

5820 Star Ln., Box 22202
06 Electronic Instrumentation, Inc. (Obsolete)

601 Dooley Rd., Box 34046
Dallas, Texas 75234
07 Halliburton Geophysical Services, Inc.,(formerly, Electro-Technical

Labs, Div. of Geosource, Inc.)
6909 Southwest Freeway
08 Fortune Electronics, Inc. (Obsolete)

5606 Parkersburg Dr.
09 Geo Space Corporation

7334 Gessner
10 Leach Corporation (Obsolete)

405 Huntington Dr.
San Marino, California

11 Metrix Instrument Co. (Obsolete)
8200 Westglen
Box 36501
12 Redcor Corporation (Obsolete)

7800 Deering Ave., Box 1031
Canoga Park, California 91304
13 Sercel (Societe d'Etudes, Recherches Et Constructions Electroniques)

25 X, 44040 Nantes Cedex,
France
14 Scientific Data Systems (SDS), (Obsolete)

1649 Seventeenth St.
Santa Monica, California 90404
15 Texas Instruments, Inc.

P.O. Box 1444
17 GUS Manufacturing, Inc.

P.O. Box 10013
El Paso, Texas 79991
18 Input/Output, Inc.
12300 Parc Crest Dr.
Stafford, Texas 77477
19 Geco-Prakla
Transition Zone Product Development
(formerly Terra Marine Engineering)
10420 Miller Road
Dallas, Texas 75238
20 Fairfield Industries, Incorporated

10627 Kinghurst
22 Geco-Prakla
Buckingham Gate, Gatwick Airport
West Sussex, RH6 ONZ, UK
31 Japex Geoscience Institute 1991

Akasaka Twin Towers Bldg. 2;
2-17-22, Akasaka
Minato-ku; Tokyo 107, Japan
32 Halliburton Geophysical Services, Inc. 1991

6909 Southwest Freeway

33 Compuseis, Inc. 1993
8920 Business Park Dr, Ste 275,
Austin, Texas 78759
34 Syntron, Inc. 1993

17200 Park Row
35 Syntron Europe Ltd. 1993

Birchwood Way
Cotes Park Industrial Estates
Somercotes, Alfreton,
Dergyshire DE55 4QQ, U.K.
36 Opseis 1994
7700 E. 38th St.
Tulsa, OK 74145
39 Grant Geophysical 1995

16850 Park Row
Houston, Tx 77084
40 Geo-X 1996
Suite 900, 425 1st St SW
Calgary, Alberta, Canada T2P3L8
41 PGS Inc. 2001

16010, Barkers Point Lane,
Houston
Texas 77079
42 SeaMap UK Ltd. 2003

Unit 31
The Maltings
Charlton Estate
Shepton Mallet BA4 5QE
UK
43 Hydroscience 2004
Hydroscience Technologies, Inc.
5101 Airport Road
Mineral Wells,
Texas 77478
USA
44 JSC 2006
“SPECIAL DESIGN BUREAU FOR SEISMIC INSTRUMENTATION”
129, Krainyaya Str.,
410019 Saratov,
RUSSIA
45 Fugro 2006
Hoffsveien 1C
N-0213 Oslo
NORWAY
46 ProFocus Systems AS 2006

Spelhaugen 20
5147 Fyllingsdalen
NORWAY
47 Optoplan AS 2008
Haakon VII’s gate 17
7041 Trondheim
NORWAY
48 Wireless Seismic Inc 2008

12996 Somerset Drive
Grass Valley, CA 95945
USA
49 AutoSeis 2010
2101 Midway Road Suite 310
Carrolton, TX 75006
USA
50 INOVA Geophysical, Inc. 2011

12200 Parc Crest Drive
Stafford, TX 77477
USA
51 Verif-i Ltd. 2011

23 Wood Lane
Sonning Common, RG4 9SJ
UK
52 Troika International 2012

14b Chapel Place
Tunbridge Wells, Kent, TN1 1YQ
UK
53 MagSeis AS 2012
Teatergaten 35
5010 Bergen
Norway

Appendix B: Glossary
Attribute – A named item of information or data pertaining to an object.

Base scan interval – The time between timing words. A base scan interval usually contains one scan but under
some conditions may contain multiple subscans.
Beginning of tape mark (BOT) – An indelible mark (e.g., reflector) near the beginning of the tape that indicates
the start of the region in which recorded data is permitted.
Block – The data between gaps on tape. On modern tape devices block may be a logical marks only, not an
actual gap on the tape. A block usually refers to the smallest amount of data possible to read from the device.
Channel set – One or more channels sampled at the same sampling interval and containing the same filter, fixed
gain, and other fixed parameter information.
Channel set descriptor – A unit of the scan type header describing the parameters of a channel set.
Data recording method – The arrangement of bits to represent samples on tape.
End of data flag (EOD) – A special record or condition on the tape used to indicate the end of data on the tape.
End of file mark (EOF) – A special record or condition on the tape that indicates the end of a tape file. Also
called File Mark.
End of tape warning (ETW) – An indelible mark (e.g., reflector), located a required minimum distance from
the physical end of the tape that serves as a warning.
Field record – The data between two filemarks on media that supports this (e.g. tape). The field record may
consists of multiple SEG-D records. For media without filemarks the field record equals a SEG-D record. (See
also File)
File – Literally, it is all of the blocks between file marks. The term Field File is sometimes used instead of File.
It is all data recorded from a one or more energy impulses or sweeps, stored in one or more SEG-D records. It
may also be the sum of a number of energy impulses or sweeps, or data recorded without any source actions.
(See also Field record.)
Filemark – A special record or state of a media index that indicates the end of a physical file.
Format Data – recording method combined with a multiplexed/demultiplexed indicator (see general header
Bytes 3 and 4).
General header – The first header in the header block. It contains information common to the entire record.
Index byte – The byte number of some particular parameter within the general or scan type header.
Organization code – A number assigned by the Petroleum Open Standards Consortium (POSC) to an
organization that identifies the organization and represents schemas and dictionaries defined and administered by
the organization.
Packed BCD – Binary coded decimal digits represented by four data bits.
Partition – An independent recording area resulting from physical formatting of the media that can be mounted
as though it were a single volume.
Physical blocks (on tape) – A collection of contiguous bytes recorded as a unit on a longitudinal tape or a track
set on helical scan tape. Physical blocks on longitudinal tape are separated by interblock gaps.
Record – A SEG-D record is a collection of data traces and meta-data describing those traces. It is also allowed
to create a record with the meta-data only. The record consists of a header (mandatory), data traces and a record
trailer. Sometimes the terms Shot record or Seismic record is used to describe a SEG-D record.
Sample skew – The fraction of the base scan interval between the timing word and the actual time the sample
was taken in a base scan interval (not related to position on tape).
Sampling interval – The interval between readings such as the time between successive samples of a digital
seismic trace.
Scan – One complete sequence of events, such as sampling all channels. Data recorded during a base scan
interval.
Scan interval – The interval between readings of all samples contained in a scan type.

Scan type – One complete set of channel sets which make up a scan. A seismic record contains multiple scans,
and may or may not contain more than one scan type.
Scan type header – A header containing one or more channel set descriptors and the skew information.
Schema – A formalized description of the encoding of information defined by a logical model, typically in terms
of a data model.
Storage set – An ordered set of storage units, the position in the set is specified in the storage unit label.
Storage unit – A logical volume of data containing on or more logical files.
Subscan – A set of samples containing one sample for each channel in a channel set.
Tape file – Is the data contained between two File Marks or between an File Mark at its beginning and an EOD
at its end. A typical implementation of EOD is an empty tape file, i.e., two consecutive File Marks. Some
systems implement EOD as two or more (possibly many) File Marks.
Tape record – A sequence of data bytes treated as a unit by the tape I/O subsystem. The application provides
the number of bytes in the tape record when writing and is returned the number of bytes in the tape record when
reading. A tape record has an identifiable beginning on the tape, which need not be on the boundary of a
physical block, and which is locatable by the tape I/O subsystem.
Time break window – Time interval in which time break is expected. If time break does not occur by the end of
the window, internal time break is generated.
Trace - A record of one seismic channel within a scan type. A collection of a sequential set of points from one
seismic channel.
Trace block - A block containing the data of one trace or a part of a trace with constant parameters.

Appendix C: API Producer Organization Code
C.1 Scope
Table 1 below contains a list of organization codes assigned by the Petrotechnical Open Standards Consortium (POSC)
for use in API Recommended Practice 66. Several of the organization codes in this appendix are historical in nature
and reflect the well log origins of API Recommended Practice 66.
This specification was originally prepared by the Subcommittee on Standard Format for Digital Well data. In June 1996
it was designated a recommended practice by the American Petroleum Institute [API] Exploration & Production
Department's Executive Committee on Drilling and Production Practices. In June 1998 stewardship of the document
was transferred from API to Petroleum Open Standards Consortium [POSC]. This organization was relaunched as
Energistics in December 2006.
C.2 Assignment of Organization Codes
Organization codes are assigned by Energistics, which maintains the current list of codes. To request a new organization
code, contact:
Energistics
Suite 1075
+1 281 243-2121 telephone
+1 281 243-2132 fax
[email protected]
http://www.energistics.org/
The following is copied from
http://w3.energistics.org/RP66/V2/Toc/main.html
This document, POSC RP66 V2, is a specification of Petrotechnical Open Standards Consortium.
This specification is based on and is equivalent in content to the document Recommended Practices for Exploration and
Production Data Digital Interchange: API RECOMMENDED PRACTICE 66, V2: Second Edition, June 1996 published
by the American Petroleum Institute (API). The acronym RP66V2 is retained for historical reasons; POSC does not
designate specifications as "Recommended Practices".
The following table is copied from
http://www.energistics.org/rp66-organization-codes
Last Updated 5 Oct 2011

Table 1— Organization Codes
Name
Description (Organization Name)
(Code)
0 Subcommittee On Recommended Format For Digital Well Data, Basic Schema
1 Operator
2 Driller
3 Mud Logger
9 Amerada Hess
10 Analysts, The
15 Baker Hughes Inteq
20 Baroid
30 Birdwell
40 Reeves (1 Jan 99; formerly BPB)
50 Brett Exploration
58 Canrig (added 2009-09-09)
60 Cardinal
65 Center Line Data
66 Subcommittee On Recommended Format For Digital Well Data, DLIS Schema
70 Century Geophysical
77 CGG Logging, Massey France
80 Charlene Well Surveying
90 Compagnie de Services Numerique
95 Comprobe
100 Computer Data Processors
110 Computrex
115 COPGO Wood Group
120 Core Laboratories
125 CRC Wireline, Inc.
126 Crocker Data Processing Pty Ltd
127 Tucker Wireline Services (formerly Davis Great Guns Logging, Wichita, KS)
128 Datalog Technology (added 2009-09-09)
130 Digigraph
137 Tucker Technologies (formerly Digital Logging Inc.), Tulsa, OK.
140 Digitech
145 Deines Perforating
148 Drillog Petro-Dynamics Limited
150 Baker Atlas (formerly Dresser Atlas)
160 Earthworm Drilling
170 Electronic Logging Company
180 Elgen
190 El Toro

200 Empire
205 Encom Technology, Ltd.
206 Ensigh Geophysics, Ltd.
208 Epoch (merged with Canrig, Nov 2008; added 2009-09-09)
210 Frontier
215 Geolog
217 Geoshare
218 GEO·X Systems Ltd.
220 G O International
230 Gravilog
240 Great Guns Servicing
250 Great Lakes Petroleum Services
260 GTS
268 Guardian Data Seismic Pty. Ltd.
270 Guns
280 Halliburton Logging
285 Horizon Production Logging
290 Husky
293 INOVA Geophysical (added 2011-01-03)
295 Input/Output, Inc.
300 Jetwell
305 Landmark Graphics
310 Lane Wells
315 Logicom Computer Services (UK) Ltd
320 Magnolia
330 McCullough Tool
332 Mitchell Energy Corporation
335 Paradigm Geophysical (formerly Mincom Pty Ltd)
337 DPTS Limited (formerly MR-DPTS Limited, changed as of 2008-08-12)
338 NRI On-Line Inc
339 Oilware, Inc.
340 Pan Geo Atlas
342 Pathfinder Energy Services
345 Perfco
350 Perfojet Services
360 Perforating Guns of Canada
361 Petcom, Inc.
362 Petroleum Exploration Computer Consultants, Ltd.
363 Petrologic Limited
366 Phillips Petroleum Company
367 Phoenixdata Services Pty Ltd.

368 Petroleum Geo-Services (PGS)
370 Petroleum Information
380 Petrophysics
390 Pioneer
392 The Practical Well Log Standards Group
395 IHS Energy Log Services (formerly Q. C. Data Collectors)
400 Ram Guns
410 Riley's Datashare
418 RODE
420 Roke
430 Sand Surveys
440 Schlumberger
450 Scientific Software
460 Seismograph Service
462 SEGDEF
463 SEG Technical Standards High Density Media Format Subcommittee
464 Shell Services Company
465 Stratigraphic Systems, Inc.
466 Spectrum ASA
467 Sperry-Sun Drilling Services
468 SEPTCO
469 Sercel, Inc.
470 Triangle
471 Thrubit Logging(added 2009-09-09)
475 Troika International
480 Welex
490 Well Reconnaissance
495 Wellsite Information Transfer Specification (WITS)
500 Well Surveys
510 Western
520 Westronics
525 Winters Wireline
530 Wireline Electronics
540 Worth Well
560 Z & S Consultants Limited
999 Reserved for local schemas
1000 Energistics (formerly POSC, changed as of 2006-11-06

Appendix D: Coordinate Reference System identification
The following stanzas are extended versions of the SEG-Y Rev 1 Location Data stanza. The structure for Extended
Textual stanzas is described in section 6.1 of SEG-Y Revision 1 (http://www.seg.org/SEGportalWEBproject/prod/SEG-
Publications/Pub-Technical-Standards/Documents/seg_y_rev1.pdf) and summarized in the following:
The ground rules for stanzas that use this schema are as follows:
 Each line consists of a keyword/value pair in the form “keyword = value”.
 The keywords and values can contain any printable character except double right or double left parentheses or the
equal sign. However, the use of punctuation characters in keywords is not recommended.
 The case of a keyword is not significant.
 For readability, spaces within a keyword are allowed but ignored. Thus the keyword “Line Name” refers to the same
keyword as “LINENAME”.
 The value associated with a keyword begins with the first non-blank character following the equal sign and extends to
the last non-blank character on the line.
 The value field for a keyword may consist of multiple subfields, separated by commas (“,”, EBCDIC 6B16 or ASCII
2C16).
 Blank lines are ignored.
 If the first non-blank character in a line is the hash sign (“#”, EBCDIC 7B16 or ASCII 2316), the line is treated as a
comment and ignored.
 If the last non-blank character on a line is an ampersand (“&”, EBCDIC 5016 or ASCII 1616), the next line is considered
to be a continuation of the current line (i.e. the next line is concatenated with the current line, with the ampersand
removed).
Each line in an Extended Textual File Header ends in carriage return and linefeed (EBCDIC 0D2516 or ASCII 0D0A16)
D.1 Location Data

Location stanzas provide the definitions for the system to which coordinates given in this SEG-D format file are
referenced. Without this information the coordinates are ambiguous. The stanzas for this coordinate reference system
definition are described in D.1.1. Examples are given in D.1.2.
If during acquisition a coordinate transformation has been applied to derive the coordinates defined through the location
stanza (for example when the location data has been transformed from the GPS system's WGS 84 coordinates to
coordinates referenced to a local Coordinate Reference System), details of the transformation applied should additionally
be given through a Coordinate Transformation stanza. The stanzas for this transformation are defined in D.1.3. Examples
are given in D.1.4.
Some keywords in both the Location Data stanza (D.1.1 table 1.2) and the Location Data Coordinate Transformation
stanza (D.1.3 table 1.4) require entry of a parameter from the EPSG Geodetic Parameter Dataset. In some cases, such as
unit of measure, the user has the ability to specify the Unit Name, Unit Code and/or Conversion Factor (to canonical Unit
of Measure). The EPSG dataset is available at www.epsg.org or online at www.epsg-registry.org.
Degree Representation
A sexagesimal degree is defined as “a plane angle represented by a sequence of values in degrees, minutes and seconds.
In the case of latitude or longitude, may also include a character indicating hemisphere.” For example: 50.0795725
degrees is represented as 50º04'46.461"N sexagesimal degrees. To store this in numeric form requires three or four fields.
The EPSG dataset includes a pseudo-unit named sexagesimal DMS which allows the storage of a sexagesimal degree in
one numeric field. The format is:

signed degrees - period - minutes (two digits) - integer seconds (two digits) - fraction of seconds
(any precision). Must include leading zero in minutes and seconds and exclude decimal point for
seconds.
For example 50º04'46.461"S may be represented as −50.0446461 in sexagesimal DMS.
This “unit” is used for documenting (mainly map projection) parameter values where the values must be exactly preserved
and rounding through conversion to decimal degrees cannot be tolerated.
Note that the value given in decimal degrees (e.g. 50.0795725) will differ from its equivalent value given in sexagesimal
DMS (50.0446461) only in the decimal part and that the two representations may be easily confused. Any value given in
sexagesimal DMS must be clearly labeled as such.
Sexagesimal DMS must be used only for geodetic parameter values in the extended textual location data stanzas. For
latitude and longitude coordinates given in General Header records, signed decimal degrees must be used.
D.1.1 Location Data stanza

The Location Data stanza identifies the Coordinate Reference System (CRS) to which data recording locations, such as
source and group, and derived locations, for example CDP, are referenced. The CRS serves as a reference for both
horizontal positioning, such as easting and northing, and vertical positioning, such as elevations and depths. Without this
identification these coordinates are ambiguous. This information may be given implicitly2 through reference to the EPSG
Geodetic Parameter Dataset (Table 1.1) or explicitly3 (Table 1.2).
Whenever the Coordinate Reference System used is included in the EPSG dataset both the implicit and explicit definition
Textual Location Data stanzas may be provided to ease decoding in environments that lack direct internet access to the
EPSG dataset. If a user extended version of the EPSG dataset is utilized with a code outside of the EPSG reserved range,
then explicit definition is required.
If more than one CRS is used for a given seismic survey, then multiple Location Data Stanzas with unique non-ambiguous
IDs must also be populated. Multiple Location Data Stanza IDs may also be used for continuation of stanzas over 3200
bytes to ensure proper continuity and repetition for oversized stanzas.
2
Implicit definition of the Coordinate Reference System (CRS) to which a set of coordinates is referenced requires the user to specify only the
appropriate CRS code and the dataset version number of the EPSG dataset from which that CRS definition was obtained. See Table 1.1 for required
data for an implicit CRS definition.
3
Explicit definition of the Coordinate Reference System (CRS) to which a set of coordinates is referenced requires specifying all of the key attributes
and parameters necessary to define the CRS. See Table 1.2 for required data in an explicit CRS definition.
Table 1.1 Stanza for implicit identification of Location Data
Stanza Header and Keyword Format Resolution / Limits Comment
((SEG: Location Data EPSG Text Stanza name
Reference ver 3.0))
Location Data Stanza ID = Long Integer ID is user defined;. range 1 to Reference from coordinate tuple given in Position
65535. block..
CRS code = Long integer EPSG code range is limited to The code of the Coordinate Reference System as given
1–32767, but other database in the EPSG Geodetic Parameter Dataset,
users may add their own code www.epsg.org
extensions outside of this
range.
CRS name = Text 80 character limit The name of the Coordinate Reference System as given
in the EPSG Geodetic Parameter Dataset,
www.epsg.org
Dataset version4 = Text 80 character limit The release number for the EPSG Geodetic Parameter
Dataset.
4
For all EPSG dataset versions from EPSG v6.0 onward the code itself (without version number) would be sufficient, as from v6.0 onward code
number will always remain unique. However, adding the version number is a good bit of insurance.
Table 1.2 Stanza for explicit definition of Location Data
((SEG: Location Data ver 3.0)) Text Stanza name
The following keywords apply to all Coordinate Reference Systems (CRS):
Location Data Stanza ID = Long Integer ID is user defined; range 1 to Reference from coordinate tuple given in Position block.
65535.
CRS type = Text from list 24 character limit, but must be See EPSG dataset www.epsg.org and accompanying
from specified “look up” list. guidance notes for information on CRS type.
projected
geographic2D
geographic3D
vertical
geocentric
compound
CRS name = Text 80 character limit The name of the Coordinate Reference System.
The following keywords are additionally required if CRS type = compound:
Horizontal CRS name = Text 80 character limit The name of the CRS forming the horizontal component
of the compound CRS. The CRS type may be projected or
geographic2D.
Vertical CRS name = Text 80 character limit The name of the CRS forming the vertical component of
the compound CRS. The CRS type will be vertical.
The definitions of these two component CRSs should then be provided through the relevant keywords below.
The following keywords are additionally required if CRS type = projected or geographic2D, or compound including one of these types, or
geographic3D or geocentric:
Geodetic Datum name = Text 80 character limit The name of the Geodetic Datum.
Prime Meridian name = Text 80 character limit Mandatory if not “Greenwich”.
Note: most, but not all, Coordinate Reference Systems use
Greenwich as the prime meridian (PM).
PM Greenwich longitude = Real Number IEEE double precision The longitude of the CRS’s prime meridian relative to the
normally represented/provided Greenwich meridian, positive if east of Greenwich. Not
to seven decimal places of a required if Prime Meridian name = “Greenwich”.
degree. Range −180 <= λG <=
+180 degrees or equivalent in
other units. See EPSG dataset
for examples of values / ranges
PM Greenwich longitude unit Long integer EPSG code range is limited to
code = 1–32767, but other database
users may add their own code Not required if Prime Meridian name = “Greenwich”.
extensions outside of this If Prime Meridian name is not "Greenwich" then at least
range. one of EPSG unit code, unit name or unit conversion ratio
PM Greenwich longitude unit Text 80 character limit, but must be to radian is required.
name = from EPSG Unit of Measure Example conversion ratio: if unit = degree, conversion
table Name field. ratio ≈ 0.01745329…
PM Greenwich longitude unit Real Number IEEE double precision.
conversion =
Ellipsoid name = Text 80 character limit
Ellipsoid semi-major axis = Real Number IEEE double precision, See EPSG dataset for examples of values / ranges.
normally given to 10
significant figures. Range
6350 < a < 6400 km or
equivalent in other units.
Semi-major axis unit code = Long integer EPSG code range is limited to
1–32767, but other database
users may add their own code
extensions outside of this At least one of EPSG unit code, unit name or unit
range. conversion ratio to meter is required.
Semi-major axis unit name = Text 80 character limit, but must be Example conversion ratio: if unit = US Survey foot,
from EPSG Unit of Measure conversion ratio ≈ 0.3048006096…
table Name field.
Semi-major axis unit Real Number IEEE double precision.
conversion =
Ellipsoid inverse flattening = Real Number IEEE double precision If a sphere, 1/f is infinite. In this case enter value of 0.
normally given to 10
significant figures. Range 250
< 1/f < 350. See EPSG dataset
for examples of values / ranges
The following keyword is additionally required when CRS type = vertical or compound:
Vertical Datum name = Text 80 character limit The name of the Vertical Datum. Not required if
ellipsoidal heights are given - these are part of a
geographic3D CRS. (Most heights and depths are gravity-
related, not ellipsoidal).

The following keywords are additionally required when CRS type = projected or when a Bin Grid Definition stanza or a Data Geographic Extent
stanza or a Coverage Perimeter stanza is included in the extended file header:
Projection name = Text 80 character limit

Projection method name = Text 50 character limit For example: “Transverse Mercator”, “Lambert Conic
Conformal (1SP)”, “Lambert Conic Conformal (2SP)”.
Projection parameter 1 name = Text 80 character limit The number and name of projection defining parameters is
dependent upon the map projection method. See the EPSG
Geodetic Parameter Dataset coordinate operation method
table for parameters required by each projection method.
Projection parameter 1 value = Real Number IEEE double precision. See
EPSG dataset for examples of
values / ranges
Projection parameter 1 unit Long integer EPSG code range is limited to
At least one of EPSG unit code, unit name or unit
conversion ratio to standard unit (radian for angle, meter
for length, unity for scale) is required.
range.
Example conversion ratios: if unit = degree, conversion
Projection parameter 1 unit Text 80 character limit, but must be
ratio ≈ 0.01745329…; if unit = US Survey foot,
name = from EPSG Unit of Measure
conversion ratio ≈ 0.3048006096…; if unit = unity,
table Name field.
conversion ratio = 1.0.
Projection parameter 1 unit Real Number IEEE double precision.
conversion =
: :
Projection parameter n name = Text 80 character limit
Projection parameter n value = Real Number IEEE double precision. See
EPSG dataset for examples

Projection parameter n unit Long integer EPSG code range is limited to
users may add their own code At least one of EPSG unit code, unit name or unit
extensions outside of this conversion ratio to standard unit (radian for angle, meter
range. for length, unity for scale) is required.
Projection parameter n unit Text 80 character limit, but must be Example conversion ratios: if unit = grad, conversion ratio
name = from EPSG Unit of Measure ≈ 0.01570796…; if unit = International foot, conversion
table Name field. ratio = 0.3048; if unit = unity, conversion ratio = 1.0.
Projection parameter n unit Real Number IEEE double precision.
conversion =
The following keywords are additionally required if CRS type = projected or geographic2D or geographic3D or geocentric or compound (they
are not required if CRS type = vertical):
Coordinate System axis 1 Text 80 character limit The name or abbreviation of the Coordinate System (CS)
name = axis for the coordinate in Position block Coord 1. For
example: easting, latitude, X, E, or geocentric X.
CS axis 1 orientation = Text 24 character limit The positive direction for axis 1. For example: “east”, or
“north”.
CS axis 1 unit code = Long integer EPSG code range is limited to
range.
Example conversion ratios: if unit = grad, conversion ratio
CS axis 1 unit name = Text 80 character limit, but must be
≈ 0.01570796…; if unit = International foot, conversion
from EPSG Unit of Measure
ratio = 0.3048; if unit = unity, conversion ratio = 1.0.
table Name field.
CS axis 1 unit conversion = Real Number IEEE double precision.
Coordinate System axis 2 Text 80 character limit The name or abbreviation of the axis for the coordinate in
name = Position block Coord 2. For example: northing, Y, N, or
longitude.
CS axis 2 orientation = Text 24 character limit The positive direction for axis 2. For example: “north” or
“east”.
CS axis 2 unit code = Long integer EPSG code range is limited to At least one of EPSG unit code, unit name or unit
1–32767, but other database conversion ratio to standard unit (radian for angle, meter
users may add their own code for length, unity for scale) is required.
extensions outside of this Example conversion ratios: if unit = grad, conversion ratio
range. ≈ 0.01570796…; if unit = International foot, conversion

CS axis 2 unit name = Text 80 character limit, but must be ratio = 0.3048; if unit = unity, conversion ratio = 1.0.
table Name field.
The following keywords are additionally required when CRS type = geographic3D or geocentric or vertical or compound (they are not required if
CRS type = projected or geographic 2D):
Coordinate System axis 3 Text 80 character limit The name or abbreviation of the axis for the elevations
name = and depths in Position block Coord3. For example:
gravity-related height, ellipsoidal height.
CS axis 3 orientation = Text 24 character limit The positive direction for axis 3. For example: “up”.
CS axis 3 unit code = Long integer EPSG code range is limited to
range.
Example conversion ratios: if unit = grad, conversion ratio
CS axis 3 unit name = Text 80 character limit, but must be
≈ 0.01570796…; if unit = International foot, conversion
ratio = 0.3048; if unit = unity, conversion ratio = 1.0.
table Name field.

D.1.2 Example Stanzas for Location Data
a) Example of implicit identification of Location Data through a geographic 2D CRS
((SEG: Location Data EPSG Reference ver 3.0))
Location Data Stanza ID = 1
CRS code = 4267
CRS name = NAD27
Dataset version = 6.13
b) Example of implicit identification of Location Data through a projected CRS (i.e. through a Map Grid)
This is the same CRS as described in full in example (e).

CRS code = 34020
CRS name = NAD27 / Texas South Central
c) Example of implicit identification of Location Data through compound coordinate reference system
consisting of projected CRS (map grid) with vertical CRS
This is the same CRS as described in full in example (i).

CRS code = 7407
CRS name = NAD27 / Texas North + NGVD29
d) Example of implicit identification of Location Data through a compound coordinate reference system
consisting of geographic2D CRS with vertical CRS
CRS code = 7406
CRS name = NAD27 + NGVD29
e) Example of explicit definition of Location Data through a projected CRS (i.e. a map grid)
This is the same CRS as identified implicitly in example (b).
((SEG: LOCATION DATA VER 3.0))

CRS type = projected

Geodetic Datum name = North American Datum 1927
Ellipsoid name = Clarke 1866
Ellipsoid semi-major axis = 6378206.4
Semi-major axis unit name = meter
Ellipsoid inverse flattening = 294.9786982
Projection name = Texas CS27 South Central zone
Projection method name = Lambert Conic Conformal (2SP)
Projection parameter 1 name = latitude of false origin
Projection parameter 1 value = 27.5
Projection parameter 1 unit name = sexagesimal DMS
Projection parameter 2 name = longitude of false origin
Projection parameter 2 value = −99
Projection parameter 2 unit name = degree
Projection parameter 3 name = latitude of first standard parallel
Projection parameter 4 name = latitude of second standard parallel
Projection parameter 5 name = easting at false origin
Projection parameter 5 unit name = US survey foot
Projection parameter 6 name = northing at false origin
Coordinate System axis 1 name = X
CS axis 1 orientation = East
CS axis 1 unit code = 9003
CS axis 1 unit name = US Survey foot
CS axis 1 unit Conversion Ratio = 0.304800609601
Coordinate System axis 2 name = Y
CS axis 2 orientation = North
f) Example of explicit definition of Location Data through a geographic2D CRS

((SEG: LOCATION DATA VER 3.0))
CRS type = geographic 2D
CRS name = NTF (Paris)
Geodetic Datum name = Nouvelle Triangulation Francaise (Paris)
# The following three keyword/value pairs are not needed when Prime Meridian =
Greenwich.

# See examples (a) and (c) for instances where these keyword/value pairs are
omitted.
Prime Meridian name = Paris
PM Greenwich longitude = 2.5969213
PM Greenwich longitude unit name Grad
Ellipsoid name = Clarke 1880 (IGN)
Coordinate System axis 1 name = latitude
CS axis 1 orientation = north
CS axis 1 unit name = grad
Coordinate System axis 2 name = longitude
CS axis 2 orientation = east
CS axis 2 unit code = 9105
CS axis 2 unit name = grad
CS axis 2 unit Conversion Ratio = 0.015707963267949
g) Example of explicit definition of Location Data through a geographic3D CRS

((SEG: Location Data ver 3.0))
CRS type = geographic 3D
CRS name = WGS 84
Geodetic Datum name = World Geodetic System 1984
Ellipsoid name = WGS 84
Coordinate System axis 1 name = latitude
CS axis 1 unit name = degree
Coordinate System axis 2 name = longitude
CS axis 2 unit name = degree
Coordinate System axis 3 name = ellipsoidal height
CS axis 3 orientation = up
CS axis 3 unit name = meter
h) Example of explicit definition of Location Data through a geocentric CRS

CRS type = geocentric
CRS name = WGS 84

Geodetic Datum name = World Geodetic System 1984
Ellipsoid name = WGS 84
Coordinate System axis 1 name = geocentric X
CS axis 1 orientation = from geocenter to intersection of equator and
prime meridian
Coordinate System axis 2 name = geocentric Y
CS axis 2 orientation = from geocenter to intersection of equator and
meridian of 90 degrees E
Coordinate System axis 3 name = geocentric Z
CS axis 3 orientation = from geocenter to north pole
i) Example of explicit definition of Location Data through a compound coordinate reference system: projected
CRS (map grid) with vertical CRS
This is the same CRS as identified implicitly in example (c).

CRS type = compound
CRS name = NAD27 / Texas South Central + NGVD29
Horizontal CRS name = NAD27 / Texas South Central
Vertical CRS name = NGVD29
Geodetic Datum name = North American Datum 1927
Ellipsoid name = Clarke 1866
Vertical Datum name = North American Vertical Datum 1929
Projection name = Texas CS27 South Central zone
Projection method name = Lambert Conic Conformal (2SP)
Projection parameter 1 name = latitude of false origin
Projection parameter 2 name = longitude of false origin
Projection parameter 2 value = −99
Projection parameter 2 unit name = degree
Projection parameter 3 name = latitude of first standard parallel
Projection parameter 4 name = latitude of second standard parallel

Projection parameter 5 name = easting at false origin
Projection parameter 5 value = 2000000
Projection parameter 6 name = northing at false origin
Projection parameter 6 value = 0
Coordinate System axis 1 name = X
Coordinate System axis 2 name = Y
Coordinate System axis 3 name = height
CS axis 3 orientation = up
CS axis 3 unit name = foot
j) Example of implicit definition of Location Data through redundant Geographic and Projected CRSs
In all of the examples (a) through (i) above, one CRS identification is given. This is sufficient when one
coordinate tuple is given in the header block. Where two coordinate tuples are given in the header block two
CRS definitions are required. In the header blocks, coordinate tuples 1 and 2 will reference these two CRSs. In
this example two CRSs are identified implicitly, the first for a geographical (latitude/longitude) coordinate tuple
and the second for a projected (map grid) coordinate tuple.

CRS code = 4267
CRS name = NAD27
CRS code = 34020

D.1.3 Location Data Coordinate Transformation stanzas
If during acquisition a coordinate transformation has been applied to derive the coordinates described through a given
Location Data stanza or a given Location Data EPSG Reference stanza (for example when the location data has been
transformed from the GPS system's WGS 84 coordinates to a local Coordinate Reference System), details of the
coordinate transformation which has been applied should be included as a Location Data Coordinate Transformation. A
coordinate transformation may be either "single", i.e. directly from source CRS A to target CRS B, or a "concatenated
operation", that is indirectly from A to B via one or more intermediate CRSs, for example from CRS A to CRS C to CRS
B. In either case the final target CRS, i.e. CRS B, is that defined in the Location Data or Location Data EPSG Reference
stanza.
As with location CRS data the coordinate transformation may be given implicitly5 through reference to the EPSG
Geodetic Parameter Dataset (Table 1.3) or described explicitly6 (Table 1.4).
If more than one CRS is used for a given survey, then an appropriate Location Data Coordinate Transformation Stanza
with a unique ID must be given for each of those CRSs. The Location Data Stanza ID for that unique CRS should be
referenced in the Location Data Coordinate Transformation Stanza (as shown below).
Multiple Location Data Transformation Stanza IDs may also be used for continuation of stanzas over 3200 bytes to ensure
proper continuity and repetition for oversized stanzas.
5
Implicit definition of a transformation applied to a given set of coordinates requires the user to specify only the appropriate transformation code and
dataset version number of the EPSG dataset from which that transformation definition was obtained. See Table 1.3 for required data for an implicit
transformation definition.
6
Explicit definition of a transformation applied to a given set of coordinates requires specifying all of the key attributes and parameters necessary to
define that transformation. See Table 1.4 for required data in an explicit transformation definition.
Table 1.3 Stanza for implicit identification of Location Data Transformation
((SEG: Location Data Coordinate Text Stanza name
Transformation EPSG Reference ver
3.0))
Location Data Coordinate Long Integer User-defined.
Transformation Stanza ID =
Location Data Stanza ID = Long Integer See tables 1.1 and 1.2. The Location Data Stanza ID for the CRS
that is the target of this transformation.
Transformation code = Long integer EPSG code range is limited to 1–32767, but The code of Transformation, as given in the
other database users may add their own code EPSG Geodetic Parameter Dataset,
extensions outside of this range. www.epsg.org
Transformation name = Text 80 character limit The name of the Transformation, as given in
the EPSG Geodetic Parameter Dataset,
www.epsg.org
Dataset version7 = Text 80 character limit The release number for the EPSG Geodetic
Parameter Dataset.
7
For all EPSG versions from EPSG v6.0 onward the code itself (without version number) would be sufficient, as code number from v6.0 onward will
always remain unique. However, adding the version number is a good bit of insurance.
Table 1.4 Stanza for explicit definition of Location Data Transformation
((SEG: Location Data Text Stanza name
Coordinate Transformation ver
3.0))
Location Data Coordinate Long Integer User-defined. Normally all seismic work will be done with a single
Transformation Stanza ID = transformation and thus the Stanza ID for this specific
transformation would be the only one populated.
Location Data Stanza ID = Long Integer See tables 1.1 and 1.2. The Location Data Stanza ID for the CRS that is the target of
this transformation.
Transformation type = From enumerated list: 24 character limit, but must Transformation = a single operation that has been applied to
be from enumerated list. initial coordinates to derive values referred to the CRS
transformation identified in the Location Data stanza.
concatenated operation
Concatenated operation = a set of multiple transformations that
have been applied sequentially.
Transformation name = Text 80 character limit The name of the Transformation
Source CRS name = Text 80 character limit The name of the CRS from which coordinates have been
transformed, for example that used within the navigation
system (usually "WGS 84").
Target CRS name = Text 80 character limit The name of the CRS to which location data is referred. A
Location Data stanza or a Location Data EPSG Reference
stanza containing this name must precede this stanza.
Transformation version = Text 24 character limit The version of the transformation between the source and target
CRSs.
The following keywords are additionally required when transformation type = transformation:
Transformation method name = Text 50 character limit For example "Geocentric translations", "Position Vector 7-
param. Transformation", " Coordinate Frame rotation",
"NADCON", "NTv2".
Then either (a) the following keyword is additionally required for transformation methods which use grid files:
Transformation parameter file 1 or more comma- 254 character limit Containing as many file names as the method requires. For
name = separated text strings example for the NTv2 method one file name is required, for the
NADCON method two file names are required.
Or (b) the following keywords are additionally required for transformation methods other than those which use grid files:

Transformation parameter 1 Text 80 character limit The number and name of parameters is dependent upon the
name = transformation method. For example the Position Vector and
Coordinate Frame methods the seven parameters required are:
 X-axis translation
 Y-axis translation
 Z-axis translation
 X-axis rotation
 Y-axis rotation
 Z-axis rotation
 Scale difference
See example (a) in A-1.4 below for the three parameters

required when the transformation method is Geocentric
Translations.
See EPSG dataset transformation method table for parameters
required for other methods.
Transformation parameter 1 Real Number IEEE double precision. See EPSG dataset for examples of values / ranges.
value =
Transformation parameter 1 Long integer EPSG code range is limited
unit code = to 1–32767, but other
At least one of EPSG unit code, unit name or unit conversion
database users may add their
ratio to standard unit (radian for angle, meter for length, unity
own code extensions outside
for scale) is required.
of this range.
Example conversion ratios: if unit = degree, conversion ratio ≈
Transformation parameter 1 Text 80 character limit, but must
0.01745329…; if unit = US Survey foot, conversion ratio ≈
unit name = be from EPSG Unit of
0.3048006096…; if unit = parts per million, conversion ratio =
Measure table Name field.
0.000001.
Transformation parameter 1 Real Number IEEE double precision.
unit conversion ratio =
: : Repeat above sequence for each transformation parameter
Transformation parameter n Text 80 character limit
name =
Transformation parameter n Real Number IEEE double precision. See EPSG dataset for examples of values / ranges.
value =
Transformation parameter n Long integer EPSG code range is limited At least one of EPSG unit code, unit name or unit conversion
unit code = to 1–32767, but other ratio to standard unit (radian for angle, meter for length, unity
database users may add their for scale) is required.
own code extensions outside Example conversion ratios: if unit = grad, conversion ratio ≈
of this range. 0.01570796…; if unit = International foot, conversion ratio =
Transformation parameter n Text 80 character limit, but must 0.3048; if unit = parts per million, conversion ratio = 0.000001.
unit name = be from EPSG Unit of
Transformation parameter n Real Number IEEE double precision.
unit conversion ratio =
The following keywords are additionally required when transformation type = concatenated operation. They should be repeated in a block for every step
with the step counter m being incremented:
Concatenated transformation Integer Integer (typically between 1 The value m is used in the following keywords.
step = and 4)
Step m source CRS name = Text 80 character limit The name of the CRS used within the navigation system
(usually "WGS 84").
Step m target CRS name = Text 80 character limit The name of the CRS to which location data is referred. A
Location Data stanza or a Location Data EPSG Reference
stanza containing this name must precede this stanza.
Step m transformation version = Text 24 character limit The version of the transformation between the source and target
CRSs.
Step m transformation method Text 50 character limit For example "Geocentric translations", "Position Vector 7-
name = param. Transformation", " Coordinate Frame rotation",
"NADCON", "NTv2".
Then either (a) the following keyword is additionally required for steps using transformation methods which use grid files:
Step m transformation Text 254 character limit Containing primary file name as the method requires.
parameter file name 1 =
...... Repeat above sequence for each transformation parameter
Step m transformation Text 254 character limit Containing “nth” file name required by specific method. For the
parameter file name n = NTv2 method one file name is required, for the NADCON
method two file names are required.
Or (b) the following keywords are additionally required for steps using transformation methods other than those which use grid files:

Step m transformation Text 80 character limit The number and name of parameters is dependent upon the
parameter 1 name = transformation method. For example the Position Vector and
Coordinate Frame methods the seven parameters required are:
 X-axis translation
 Y-axis translation
 Z-axis translation
 X-axis rotation
 Y-axis rotation
 Z-axis rotation
 Scale difference
See example (a) in A-1.4 below for the three parameters

required when the transformation method is Geocentric
Translations.
See EPSG dataset transformation method table for parameters
required for other methods.
Step m transformation Real Number IEEE double precision. See EPSG dataset for examples of values / ranges.
parameter 1 value =
Step m transformation Long integer EPSG code range is limited
parameter 1 unit code = to 1–32767, but other
database users may add their At least one of EPSG unit code, unit name or unit conversion
own code extensions outside ratio to standard unit (radian for angle, meter for length, and
of this range. unity for scale) is required.
Step m transformation Text 80 character limit, but must Example conversion ratios: if unit = degree, conversion ratio ≈
parameter 1 unit name = be from EPSG Unit of 0.01745329…; if unit = US Survey foot, conversion ratio ≈
Measure table Name field. 0.3048006096…; if unit = parts per million, conversion ratio =
Step m transformation Real Number IEEE double precision. 0.000001.
parameter 1 unit conversion
ratio =
: : Repeat above sequence for each transformation parameter
Step m transformation Text 80 character limit
parameter n name =
Step m transformation Real Number IEEE double precision. See EPSG dataset for examples of values / ranges
parameter n value =

Step m transformation Long integer EPSG code range is limited
parameter n unit code = to 1–32767, but other
database users may add their
At least one of EPSG unit code, unit name or unit conversion
own code extensions outside
ratio to standard unit (radian for angle, meter for length, unity
of this range.
for scale) is required.
Step m transformation Text 80 character limit, but must
Example conversion ratios: if unit = grad, conversion ratio ≈
parameter n unit name = be from EPSG Unit of
0.01570796…; if unit = International foot, conversion ratio =
0.3048; if unit = parts per million, conversion ratio = 0.000001.
Step m transformation Real Number IEEE double precision.
parameter n unit conversion
ratio =

D.1.4 Example Stanzas for Location Data Transformation
k) Example of implicit identification of Location Data Coordinate Transformation through a single
transformation
((SEG: Location Data Coordinate Transformation EPSG Reference ver 3.0))

Location Data Coordinate Transformation Stanza ID = 10
Transformation code = 15853
Transformation name = NAD27 to WGS 84 (81)
l) Example of implicit identification of Location Data Coordinate Transformation through a concatenated

operation
((SEG: Location Data Coordinate Transformation EPSG Reference ver 3.0))
Transformation code = 8635
Transformation name = NAD27 to NAD83(CSRS) (3)
m) Example of explicit definition of Location Data Transformation through a single transformation with a method
using parameters
((SEG: Location Data Coordinate Transformation ver 3.0))

Transformation type = transformation
Transformation name = WGS 84 to NAD27
Source CRS name = WGS 84
Target CRS name = NAD27
Transformation version = JECA-Usa GoM C
Transformation method name = Geocentric translations
Transformation parameter 1 name = X-axis translation
Transformation parameter 1 value = 7
Transformation parameter 1 unit name = meter
Transformation parameter 2 name = Y-axis translation
Transformation parameter 2 value = −151
Transformation parameter 3 name = Z-axis translation
Transformation parameter 3 value = −175
n) Example of explicit definition of Location Data Transformation through a single transformation with a method
using grid files

Transformation type = transformation
Transformation name = NAD27 to NAD83 (1)
Source CRS name = NAD27
Transformation version = NGS-Usa Conus
Transformation method name = NADCON
Transformation parameter file name 1 = conus.las,
Transformation parameter file name 2= conus.los
o) Example of explicit definition of Location Data Transformation through a concatenated operation

Transformation type = Concatenated operation
Transformation name = NAD83(CSRS) to NAD27
Source CRS name = NAD83(CSRS
Transformation version = EPSG-Can AB
Concatenated transformation step = 1
Step 1 transformation step name = NAD83(CSRS) to NAD83
Step 1 source CRS = NAD83(CSRS)
Step 1 target CRS = NAD83
Step 1 transformation version = AB Env-Can AB
Step 1 transformation method name = NTv2
Step 1 transformation parameter file name = AB_CSRS.gsb
Concatenated transformation step = 2
Step 2 transformation step name = NAD83 to NAD27
Step 2 source CRS = NAD83
Step 2 target CRS = NAD27
Step 2 transformation version = GC-Can NT2
Step 2 transformation method name = NTv2
Step 2 transformation parameter file name = NTV2_0.GSB

Appendix E: Examples and Calculations
E.1 Samples per scan type

Note:
This example is no longer valid as SEG-D rev 3.0 and above no longer has a base scan interval, and hence no longer has
a “samples per scan” value. The example is mainly here to support storing old formatted data in SEG-D rev 3.0+.
cs
S/S   C/S  2 s/c
1
where
S/S = samples per scan type
C/S = channels in this channel set (channel set descriptor Bytes 21 to 23)
2s/c = samples per channel (in this channel set)
CS = number of channel sets in this scan type (general header #1 Byte 29 or general header #2 Byte 4 and 5)
For example, for a 2-msec base scan interval with 4 auxiliary channels at 2 msec, 96 channels at 2 msec and 12 channels
at ½ msec. There are three channel sets, so CS = 3.
S/S = C/S x 2s/c  + C/S x 2s/c  + …
cs = 1 cs = 2
S/S = 4 x 1 + 96 x 1 + 12 x 4
S/S = 4 + 96 + 48 = 148
Note that all scan types must have the same number of data samples.
E.2 Skew fields per scan type

Note:
This example is no longer valid as SEG-D rev 3.0 and above no longer has a base scan interval, and hence no longer has
a “samples per scan” value. The example is mainly here to support storing old formatted data with skew blocks in SEG-D
rev 3.0+.
S/S
SK = (If the quotient is not a whole number, round up to the next largest whole number)
32
where
SK = skew fields (of 32 bytes each) per scan type (general header Byte 30)
S/S = samples per scan (Appendix E1)
Substituting for S/S from Appendix E.1:
1 CS

s/c
SK  C/S  2
32 1
(If the quotient is not a whole number, round up to the next largest whole number.)
where
CS = the number of channel sets in each scan type (general header #1 Byte 29 or #2 Byte 4 and 5)
C/S = channels in this channel set (channel set descriptor Bytes 21 to 23)
2s/c = samples per channel in this channel set.
For example, for a 2-msec base scan with 4 auxiliary channels at 2 msec, 96 channels at 2 msec and 12 channels at ½
msec
41961124
SK = 32
148
= = 4 20 32 roundup = 5 fields of 32 bytes each
32
E.3 Filter slope calculation
Modern filters may not have a constant slope, so it is necessary to define this parameter. The slope is defined as the
asymptote of effective performance as it would be in a constant slope filter. This slope is zero dB attenuation at the cut-
off frequency and a specific attenuation at the beginning of the stop band. The chosen values are 40 dB for a low-cut
filter and 60 dB for an anti-alias filter.
Low-cut filter slope calculation.
LS= 40 = 40 = 12.04
log2fLCO/f40 3.322 log10fLCO/f40 log10fLCO/f40
LS = low-cut filter slope (channel set descriptor Bytes 19 and 20),

f40 = the frequency of 40 dB low-cut filter attenuation,
fLCO = low-cut filter cut-off frequency usually 6 or 12 dB attenuation.
Alias-filter slope calculation.
AS = 60 = 60 = 18.06
log2f60/fACO 3.322 log10f60/fACO log10f60/fACO
AS = alias filter slope (channel set descriptor Bytes 15 and 16)

f60 = the frequency of 60 dB alias-filter attenuation
fACO = alias-filter cut-off frequency usually 3 or 6 dB attenuation
E.4 SEG-D file storage on non-tape media
Modern acquisition and processing systems commonly require storing SEG-D data on disk. These are a few
examples of how this can be done:
Raw disk copy of SEG-D records
As stated in chapter 3, starting with Revision 2, SEG-D data are treated as a stream of bytes. When storing
Rev 3.0 data on tape, tape block and file marks are inserted at points defined by the manufacturer.

Interpretation of data is done on the raw byte data stream. It is important to maintain the byte stream view
when storing SEG-D on disk as well, such that decoding and encoding of data is performed in the same way,
independent of its storage format. (For fixed blocksize devices, trailing padding at the end of some blocks
slightly violates this treatment and we strongly recommend that such data should be first converted, as
detailed below, from FIXREC to RECORD format before storing on disk or transmitting through a network.)
From the definitions in chapter 3 it follows that a disk file is a storage media similar to a tape, hence a tape
label must be placed at the beginning of the file, followed by a set of SEG-D records. A TOC indexing file
may or may not be a part of the file.
A good solution is to use the filename as indication of the contents of the SEG-D records in the file. To speed
up access to SEG-D data on disk, storing only one SEG-D record per file may be the best option with, for
example, the file name being <filenumber>.segd or <linename>_<filenumber>.segd.
The fields in the Tape Label should be set thusly:
- Storage unit structure will be RECORD

- Maximum block size will be 1
- Serial Number must be unique, however as disk storage is normally temporary, making it unique
within the disk might be sufficient. For single record files, using a combination of file number and
e.g. line/sequence/swath number might be a good solution. (For temporary storage, if the Serial
Number is not used as part of an indexing system, the producer has flexibility in defining its
contents.)
The file layout:
|Tape Label|SEG-D Header|Trace Data|General Trailer|EOF|
The advantage of this solution is it allows direct access of data on disk (through a memory mapped file) in the
same way as data are accessed in memory. For certain tasks, especially quality control inspection, this may
speed up the process with a factor of 10 or 100.
E.5 SEG-D record index interpretation for marine, land, seabed, transition-zone, and VSP
surveys
SEG-D uses six indices to uniquely assign a trace with a unique logical position within the record. The
interpretation of indices depends on the type of survey. The basic difference is between surveys where the
receivers are stationary (land/seabed), and where the receivers are moving (towed marine). Transition zone
surveys use a combination of the two. Other conceivable combinations are seabed and towed marine, VSP
(vertical seismic profile, i.e. receivers in one or more boreholes) and land/marine/seabed/TZ. The indices need
to be valid for all these survey types, including combinations.
The indices are:

 Line

 Point
 Point Index
 Group Index
 Depth Index
 Reshoot Index
Indices exists for both source (i.e. Source Point, Source Line), and receiver (i.e. Receiver Point, Receiver
Line).
The Group Index is used to indicate a trace belonging to a set of traces that need to be processed as a unit (and
are placed at the same position), e.g. three-component data that need to be rotated together.
The Reshoot Index is used to indicate a trace has been recorded earlier, and the data with the highest Reshoot
Index should be used in processing (normally).
Towed marine survey
A Marine survey is normally divided up in lines, and the survey is acquired by one or more vessels towing
one or more sources and one or more streamers. The lines are normally assigned an integer number. The
example below shows a complex survey using two streamer vessels with two sources each, and one source
vessel travelling behind one of the streamer vessels.
8000m
Shot#
1
1244
100m
125m
2
VSL1 1 VSL3 5
Line 123
50m
2 6
3
4
1500 m
10000m
5
100m
VSL2 3 6
4
7
Streamer
Source
8
Figure showing a complex vessel configuration for a marine seismic survey. Note, figure
is not to scale
Source / receiver line number

The receiver and source line number is give by the line number, in this case 123. In this example, the
fractional part of the source /receiver number will be used to indicate the nominal position of the equipment.
Using a pure logical numbering scheme is allowed, i.e. there are 12 separate equipment lines in the figure (8
streamer and 4 source). Equipment is e.g. allocated line number in steps of 0.5, starting counting from 123.0.
Streamer 1 has receiver line 123.0, Streamer 2 123.05, Source 1 and 5 has source line 123.1, Source 2 and
6 123.15, ..... Streamer 8 has 123.55.
However for this example, the logical positions are selected to reflect the actual offsets. The offset between
the outer streamers (1 and 8) are 1300 meters. 1 meter is selected to be 0.0005 logical units. Assuming
increasing line numbers downwards in the figure, Streamers are assigned the following line numbers:
1: 122.925, 2: 122.955, 3: 123.025, 4: 123.075, 5: 123.675, 6: 123.725, 7: 123.775, 8: 123.725.
Sources are assigned the following source line numbers:
1: 122.9875, 2: 123.0125, 4: 123.4875, 5: 123.5125, 5: 122.9875, 6: 123.0125
It is worth noting here that the number resolution in the receiver/source line numbers is not very high, so the
numbers above will be approximate.
Source / receiver point number

A similar strategy is used for source/receiver point number. The distance between sources 1 and 5 is 10000
meters. Receivers in the streamers are spaced at 12.5 meter intervals. 12.5 meters is chosen to be 1/1024
logical point units (The reason behind selecting 1/1024 as a unit is that this number is well represented in the
format). The marine acquisition line is divided up into shots (source events), with 25 meter spacing, the shot#
in the figure is 1244. The numbering starts from the first equipment (sources 1-4), counting backwards until
the last equipment (sources 5-6). The logical numbering will be the same independent of the line direction
(upline, i.e. shot# increasing, or downline, i.e shot# decreasing).
Sources 1-4 get Source Point Number 1244.0, sources 5-6 1244.78125.
Receiver 1 (on all streamers) is assigned Receiver Point Number 1244.00977, Receiver 2 1244.01074,
Receiver 3 1244.01172, ... Receiver 640 1244.63379
The Receiver Point Index will always be 1 for the marine survey.
Note: The source/receiver line/point number will only reflect the nominal position, actual position due to e.g.
streamer feather is not considered when determining the logical position determined by the indices. If actual
position is needed, the position may be stored in Position Blocks in Trace Headers.
Land
Land seismic surveys have been using Source and Receiver lines for many years, so no large example will be
give here. SEG-D may be used to map in the numbers currently used.
Seabed
Seabed surveys are a combination of a Land and Marine survey, where sensors are placed on the sea floor,
and a source vessel is moving around in the area, usually along Source Lines. Seabed covers several
operations, like seismic sensors placed on the sea floor temporarily in the form of streamers or separate sensor
units, permanently around installations, or electrical / magnetic sensors (EM survey).
The sensors are deployed in a grid defined by the Receiver Line and Point Numbers, similar to a Land survey.
Sources are moving in Source Lines similar to the example for Marine survey, and are assigned indices
accordingly. For continuous source efforts, like EM surveys, where the source fires continually, it is allowed
to set the Source Point Number to 0 if it does not fit at all. However, it is highly recommended to determine a
logical numbering scheme that allows the use of Source Point Number. This is one of the reasons why
splitting up the data into smaller records are recommended, e.g. to match the cycle of the source (see E.10
Electromagnetic (EM) survey) for more details.
Transition-zone
Transition zone may be viewed as a combination survey being parts Marine and parts Land survey. Indices
are assigned using Marine or Land methods where appropriate.
Downhole seismic / Vertical seismic profile
This covers all survey types where seismic sensors are inserted down a well. The sensors may be a dedicated
seismic string, or acquired as part of other downhole equipment. The survey may be a normal seismic survey,
Land or Marine, where the downhole data is acquired in conjunction with a larger system, or a dedicated well
centric survey, like a walkaway vertical seismic profile. The Source Line /Point Number is assigned as
normal, even with well centric surveys, the source moves in predetermined line.
Receiver Line / Point Number is assigned by giving the all receivers in the well the same Receiver Line and
Receiver Point Number, and use the Depth Index to indicate the order downhole. If the downhole string
contains more than 255 receivers, the Receiver Point Index is used to extend the numerical range of the Depth
Index. This allows a maximum of about 65000 receivers down a well. It is worth noting that all receivers in a
well are assigned the same Receiver Line /Point Number, even if the well is horizontal.
E.6 Trace edit example
Example of Trace Edits in General Trailer, built up by data from several systems, here by the acquisition
system ACQSYS, the quality control system AQC, and the positioning system NAVPOS. The edit block may
be extended by the different systems, or separate edit blocks may be created.
V SEGD Trace Edit v1.0

S 12:34:55 12-JAN-2007
W ACQSYS v2.2.3 build 231, M/S Unsinkable II
C These are the edits performed by online acquisition
H Killed traces
A killed trace
X 1;2;1-4
X 1;5;23,48-50,423
X 1;8;345
X 1;5-14;1
E END Killed traces
H Weak trace detection
A Seismic trace RMS < 1 uB
P SEIS_RMS(1,0.014)
R 1;5-14;1-558
X 1;3;123-135
X 1;15;33,55,231-234
E END Weak trace detection
S 14:15:00 12-JAN-2007
W AQC v6.4, operator John D. Operator
C These edits done by the online Quality Control system
H Noisy trace detection
A NOISY_TRACE(12,0.65)
C Noisy trace detection by comparing neighboring traces
C and performing frequency content analysis
R 1;5-14;1-558
X 1;6;1-15,234-238
X 1;8;1-15
E END Noisy trace detection
H Manual edits
A Manual edits
C Manual edits performed by operator
Y EXCLUDE
X 1;9;550-558
E END Manual edits
S 15:05:00 12-JAN-2007
W NAVPOS v1.2
C Edits done by positioning system
H Position verification
A GPS_VERIFY(4) GPS position quality verification
Y WARNING
X 1;14;1-558
C Comments entered by navigator:
C GPS positions for streamer 10 unreliable for shots 1201-1243
E END Position verification
T END SEGD Trace Edit
E.7 Source information in General Header or Trace Header
Source IDs/sets
Each source needed to be recorded must be assigned an ID, the same is required of any combined set of
sources.
Examples:
1. A SEG-D record contains four vibrators firing as a group. The record contains Source Description blocks
for each of the single vibrators, and the combined source group. The four vibrators have ids 2,12,13, and 16,
each belonging to source set 101 (i.e. vibrator group 101). The combined source is assigned the id 101, and it
does not belong to any source set, i.e. the source set is set to 0.

Source id Source set
2 101
12 101
13 101
16 101
101 0
For each of the vibrators the position is logged together with a auxillary trace for the baseplate movement. To capture the
status and actual firing time for each individual vibrator, an Additional Source Info block is used. For the vibratorgroup
the combined status is stored in an Additional Source Info block. The following source blocks are therefore stored as part
of General Header (each box is one 32 byte block):
Source #2 information blocks
Source Addtl Source Position Block Source Addtl Source

Desc Source Aux Chn Source 2 Desc Source Aux Chn
2 Info 2 Ref 2 12 Info 12 Ref 12
Position Block Source Addtl Source Position Block

Source 12 Desc Source Aux Chn Source 13
13 Info 13 Ref 13
Source Addtl Source Position Block Source Addtl

Desc Source Aux Chn Source 16 Desc Source
16 Info 16 Ref 16 101 Info 101
2. A marine airgun source is made up of three sub-strings, each consisting of three airguns (one cluster, and
two single guns). The record contains Source Description blocks for each of the airguns, one for each of the
substrings, and one for the combined source. The single/cluster guns have ids 1,2,3 (substring 1), 4,5,6
(substring 2), 7,8,9 (substring 3). Numbering should be starboard to port, front to back. The substrings are
assigned the ids 51,52,53, and the combined source id 101. The combined source have set id 101 (starboard
source is 101, the port source has set id 102, source id 102). The substrings have set ids 51,52,53.
Source id Source set

1 51
2 51
3 51
4 52
5 52
6 52
7 53
8 53
9 53
51 101
52 101
53 101

101 0
To be able to see which sources belongs to which source sets, it is important to give the source set, and the
combined source ids the same value. This means SEG-D rev 3.0 supports up to 255 different single sources
and source sets/groups.
Source information should match SPS definitions.
To be able to cope with multiple source events during the record, Source Information blocks can be recorded
as part of the Trace Extension Header (instead of in the General Header). The Additional Source Info block
must then be present for each Source Information block, and the timestamp (bytes 1–8) filled in properly to
indicate which sample the source event happened. The relevant source description blocks must also be
inserted into all traces relating to source (source signatures, baseplate measurements, raw nearfield
hydrophone data etc.), though they may also be recorded as part of any other (seismic/auxiliary) trace.
E.8 Extended Recording Mode example
Extended recording mode is mostly designed for situations where lack of resources makes creation of multiple
SEGD records a complicated or impossible task, e.g. in embedded systems where memory resources or
memory model making storing meta-information intermixed with the data difficult.
Extended recording mode allows data to be recorded in blocks of up to 4,294,967,295 samples, containing a
small trace header (84 byte minimum) followed by up to 4,294,967,295 samples of data.
Consider the following sensor node:

Sensor Node
uC
Control
Memory
DSP
Sampling
Memory
X Y Z P

The node contains one microcontroller (μC) with attached memory for control, monitoring, quality control
and external communication, and one digital signal processor (DSP) with attached memory for sampling and
data filtering from 4 sensors (a 3 component accelerometer and one hydrophone).
The node is deployed on the sea floor, and will remain there for a maximum of two weeks (1,209,600
seconds) before being picked up. Extended recording mode allows up to 65535 channelsets (or time blocks) to
be acquired in one record, each channelset being up to 4,294,967,295 samples long. As the node has 4
different channel types, which have to be stored in separate channelsets, the available number of time blocks
in extended Recording mode is 65535/4=16383. To get the minimum time block/channelset length for this
system we calculate 1209600/16383 = 73.8 seconds
One may then safely decide to choose a trace size of 120 seconds. This creates a suitable sized trace which fit
the memory model of the DSP well, has a good safety margin (can be deployed for a maximum of 22 days),
and has a good overhead to data ratio. In addition the system is created such that in case of a memory
problem, only 120 consecutive seconds of data will be lost at a time.
The microcontroller is responsible for creating the SEG-D record header and keep it in memory during the
acquisition. Whenever a new channelset is needed, the DSP notifies the microcontroller, which creates the 4
channelset descriptors. The DSP creates 4 new trace headers in its memory, each consisting of a Trace Header
(20 bytes), Trace Header Extension #1 (32 bytes), and a Timestamp Header (32 byte). It then starts writing
trace data into the new traces.
The microcontroller monitors several other sensors during the acquisition, including temperature, box
pressure, leakage sensor, power status, compass readings, tilt/orientation measurements, clock drift etc. This
information is stored in the SEG-D record Extended Header in a manufacturer specific format.
When the data is downloaded from the node, the microcontroller first sends the header data stored in its
memory, then reads the trace data from the DSP such that the download software receives a complete SEG-D
record.
E.9 SEG-D timestamp calculation

/* SEG-D UTC <--> GPS conversion
* The following is ANSI C++ code.

* It should be easily translated to most other common languages like Java, C, C#, Fortran, Perl
*/
#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
#if LONG_MAX <= 2147483647L

#if defined(_MSC_VER)
typedef __int64 Timestamp;
#define TSDECL(x) x##i64
#define tsfmt "%I64d"
#else
typedef long long Timestamp;
#define TSDECL(x) x##LL
#define tsfmt "%lld"
#endif
#else
typedef long Timestamp;
#define TSDECL(x) x##L
#define tsfmt "%ld"
#endif
const int dayArr[2][12] = { { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 },
{ 31, 29, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 } };
const char *monthArr[12] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun",

"Jul", "Aug", "Sep", "Oct", "Nov", "Dec" };
class Utc {
public:
int year;
int month; /* 1..12 */
int day; /* 1..31 */
int hour; /* 0..23 */
int minute; /* 0..59 */
int sec; /* 0..60 60=leap second */
int microsec; /* 0-999999 fraction of sec */
Utc( int y, int m, int d, int h, int min, int s, int us ) :

year(y), month(m), day(d), hour(h), minute(min), sec(s), microsec(us) {}
Utc() {}
const char* toString() const {

/* not threadsafe code */
static char str[28];
sprintf( str, "%2d %s %4d %02d:%02d:%02d.%06d",
day,monthArr[month-1],year,hour,minute,sec,microsec);
return str;
}
};
struct DayLeapsec {
int days; /* days since 6 jan 1980, may be negative */
int leapsecs;
};
struct TimestampLeapsec {
Timestamp timestamp;
int leapsecs;
};
struct TimestampJan1Year {
int year;
Timestamp timestamp;
};
#define NLEAP (sizeof(dayLeapArr)/sizeof(dayLeapArr[0]))
const DayLeapsec dayLeapArr[] = {

{-3657, -9}, /* 1 jan 1970 */
{-2745, -8}, /* 1 jul 1972 */
{-2561, -7}, /* 1 jan 1973 */
{-2196, -6}, /* 1 jan 1974 */
{-1831, -5}, /* 1 jan 1975 */
{-1466, -4}, /* 1 jan 1976 */
{-1100, -3}, /* 1 jan 1977 */
{ -735, -2}, /* 1 jan 1978 */
{ -370, -1}, /* 1 jan 1979 */

{ -5, 0}, /* 1 jan 1980 */
{ 542, 1}, /* 1 jul 1981 */
{ 907, 2}, /* 1 jul 1982 */
{1272, 3}, /* 1 jul 1983 */
{2003, 4}, /* 1 jul 1985 */
{2917, 5}, /* 1 jan 1988 */
{3648, 6}, /* 1 jan 1990 */
{4013, 7}, /* 1 jan 1991 */
{4560, 8}, /* 1 jul 1992 */
{4925, 9}, /* 1 jul 1993 */
{5290, 10}, /* 1 jul 1994 */
{5839, 11}, /* 1 jan 1996 */
{6386, 12}, /* 1 jul 1997 */
{6935, 13}, /* 1 jan 1999 */
{9492, 14}, /* 1 jan 2006 */
{10588, 15}, /* 1 jan 2009 */
{11865, 16} /* 1 jul 2012 */
};
const TimestampLeapsec tsLeapArr[] = {

{TSDECL(-315964809000000) , -9}, /* 1 jan 1970 */
{TSDECL(-237168008000000) , -8}, /* 1 jul 1972 */
{TSDECL(-221270407000000) , -7}, /* 1 jan 1973 */
{TSDECL(-189734406000000) , -6}, /* 1 jan 1974 */
{TSDECL(-158198405000000) , -5}, /* 1 jan 1975 */
{TSDECL(-126662404000000) , -4}, /* 1 jan 1976 */
{TSDECL( -95040003000000) , -3}, /* 1 jan 1977 */
{TSDECL( -63504002000000) , -2}, /* 1 jan 1978 */
{TSDECL( -31968001000000) , -1}, /* 1 jan 1979 */
{TSDECL( -432000000000) , 0}, /* 1 jan 1980 */
{TSDECL( 46828801000000) , 1}, /* 1 jul 1981 */
{TSDECL( 78364802000000) , 2}, /* 1 jul 1982 */
{TSDECL( 109900803000000) , 3}, /* 1 jul 1983 */
{TSDECL( 173059204000000) , 4}, /* 1 jul 1985 */
{TSDECL( 252028805000000) , 5}, /* 1 jan 1988 */
{TSDECL( 315187206000000) , 6}, /* 1 jan 1990 */
{TSDECL( 346723207000000) , 7}, /* 1 jan 1991 */
{TSDECL( 393984008000000) , 8}, /* 1 jul 1992 */
{TSDECL( 425520009000000) , 9}, /* 1 jul 1993 */
{TSDECL( 457056010000000) , 10}, /* 1 jul 1994 */
{TSDECL( 504489611000000) , 11}, /* 1 jan 1996 */
{TSDECL( 551750412000000) , 12}, /* 1 jul 1997 */
{TSDECL( 599184013000000) , 13}, /* 1 jan 1999 */
{TSDECL( 820108814000000) , 14}, /* 1 jan 2006 */
{TSDECL( 914803215000000) , 15}, /* 1 jan 2009 */
{TSDECL(1025136016000000) , 16} /* 1 jul 2012 */
};
const TimestampJan1Year tsJan1YearArr[] = {

{ 1970, TSDECL(-315964809000000) },
{ 1971, TSDECL(-284428809000000) },
{ 1972, TSDECL(-252892809000000) },
{ 1973, TSDECL(-221270407000000) },
{ 1974, TSDECL(-189734406000000) },
{ 1975, TSDECL(-158198405000000) },
{ 1976, TSDECL(-126662404000000) },
{ 1977, TSDECL(-95040003000000) },
{ 1978, TSDECL(-63504002000000) },
{ 1979, TSDECL(-31968001000000) },
{ 1980, TSDECL(-432000000000) },
{ 1981, TSDECL(31190400000000) },
{ 1982, TSDECL(62726401000000) },
{ 1983, TSDECL(94262402000000) },

{ 1984, TSDECL(125798403000000) },
{ 1985, TSDECL(157420803000000) },
{ 1986, TSDECL(188956804000000) },
{ 1987, TSDECL(220492804000000) },
{ 1988, TSDECL(252028805000000) },
{ 1989, TSDECL(283651205000000) },
{ 1990, TSDECL(315187206000000) },
{ 1991, TSDECL(346723207000000) },
{ 1992, TSDECL(378259207000000) },
{ 1993, TSDECL(409881608000000) },
{ 1994, TSDECL(441417609000000) },
{ 1995, TSDECL(472953610000000) },
{ 1996, TSDECL(504489611000000) },
{ 1997, TSDECL(536112011000000) },
{ 1998, TSDECL(567648012000000) },
{ 1999, TSDECL(599184013000000) },
{ 2000, TSDECL(630720013000000) },
{ 2001, TSDECL(662342413000000) },
{ 2002, TSDECL(693878413000000) },
{ 2003, TSDECL(725414413000000) },
{ 2004, TSDECL(756950413000000) },
{ 2005, TSDECL(788572813000000) },
{ 2006, TSDECL(820108814000000) },
{ 2007, TSDECL(851644814000000) },
{ 2008, TSDECL(883180814000000) },
{ 2009, TSDECL(914803215000000) },
{ 2010, TSDECL(946339215000000) },
{ 2011, TSDECL(977875215000000) },
{ 2012, TSDECL(1009411215000000) }
};
int isLeap( int year ) {

return (((year) % 4) == 0 && (((year) % 100) != 0 || ((year) % 400) == 0));
}
int month_dayToJulian( int day, int month, int leapIX ) {

int julian=day;
for( int i=0; i<(month-1); i++ ) julian += dayArr[leapIX][i];
return julian;
}
int daysSinceT0( int year, int julianDay ) {

int days=0;
if( year >= 1980 ) {
days=julianDay-6; /* correct for starting day 6 jan 1980 */
for( int y=1980; y<year; y++ )
days += 365+isLeap(y);
} else {
days = julianDay - 365 - isLeap(year) - 6;
for( int y=1979; y>year; y--)
days -= 365+isLeap(y);
}
return days;
}
int leapSecs( int daysSinceT0 ) {

for( int i=NLEAP-1; i>=0; i-- ) {
if(daysSinceT0 >= dayLeapArr[i].days ) {
/* fprintf(stdout, "leapSecs: %d\n", dayLeapArr[i].leapsecs); */
return dayLeapArr[i].leapsecs;
}
}
fprintf(stderr, "Illegal number in leapSec calculation, is date after 1970?\n");

return 0; /* should never happen with legal SEG-D timestamps, throw exception here */
}
int leapSecs( Timestamp ts ) {

for( int i=NLEAP-1; i>=0; i-- ) {
if(ts >= tsLeapArr[i].timestamp ) {
/* fprintf(stdout, "leapSecs: %d\n", tsLeapArr[i].leapsecs); */
return tsLeapArr[i].leapsecs;
}
}
fprintf(stderr, "Illegal number in leapSec calculation, is date after 1970?\n");
return 0; /* should never happen with legal SEG-D timestamps, throw exception here */
}
Timestamp utcToTimestamp( const Utc& utc ) {

int leapIX = isLeap(utc.year) ? 1 : 0; /* february */
int julian = month_dayToJulian(utc.day,utc.month,leapIX);
int nd = daysSinceT0(utc.year,julian); /* nd negative if date before 6 jan 1980 */
Timestamp ts = 1000000*(Timestamp)((Timestamp)nd*24*3600 + utc.hour*3600 + utc.minute*60 + utc.sec) +
utc.microsec;
return ts + leapSecs(nd)*1000000;
}
Utc timestampToUtc( Timestamp ts ) {

Utc result(0,0,0,0,0,0,0);
int iy, nd, md, im;
int leapIX;
Timestamp tsJan1;
for(iy = 0 ; iy < (sizeof(tsJan1YearArr)/sizeof(tsJan1YearArr[0])); ++iy) {
if(tsJan1YearArr[iy].timestamp <= ts) {
result.year = tsJan1YearArr[iy].year;
} else {
break;
}
}
/* if off the end of the charts, return all zeros */
if(result.year == 0) return result;
else tsJan1 = tsJan1YearArr[iy-1].timestamp;
/* reduce to number of microseconds since beginning of year */

ts -= (1000000 * leapSecs(ts));
tsJan1 -= (1000000 * leapSecs(tsJan1));
ts -= tsJan1;
/* extract microseconds */
result.microsec = (int) (ts%1000000);
ts -= result.microsec;
ts /= 1000000;
/* extract seconds */
result.sec = (int) (ts%60);
ts -= result.sec;
ts /= 60;
/* extract minutes */
result.minute = (int) (ts%60);
ts -= result.minute;
ts /= 60;
/* extract hours */
result.hour = (int) (ts%24);
ts /= 24;

/* figure month and day from number of days since start of year */
nd = (int) (ts);
md = 0;
leapIX = isLeap(result.year) ? 1 : 0; /* february */
for( im = 0; im < 12; ++im ) {
if( md > nd ) break;
md += dayArr[leapIX][im];
}
result.month = im;
result.day = 1 + nd + dayArr[leapIX][im-1] - md;
if(result.day == 32) { /* leap second */

result.day = 31; result.hour = 23; result.minute = 59; result.sec = 60;
}
return result;
}
extern "C" {
void GPStoDate(Timestamp ts, int *year, int *month, int *day,
int *hour, int *minute, int *sec,
int *microsec)
{
Utc testTime = timestampToUtc( ts );
*year = testTime.year;
*month = testTime.month;
*day = testTime.day;
*hour = testTime.hour;
*minute = testTime.minute;
*sec = testTime.sec;
*microsec = testTime.microsec;
}
}
#ifdef TEST
int main(int argc, char **argv)
{
int yrlist[] = { 1970, 1971, 1972, 1973, 1974, 1975, 1976, 1977, 1978, 1979,
1980, 1981, 1982, 1983, 1984, 1985, 1986, 1987, 1988, 1989,
1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
2010, 2011, 2012 };
int mnlist[] = { 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1 };
size_t i;
Utc testTime(2005,12,31,23,59,60,0);
Timestamp ts;
ts = utcToTimestamp(testTime);
fprintf(stdout,"%s is Timestamp " tsfmt "\n", testTime.toString(), ts);
testTime = timestampToUtc( ts );
fprintf(stdout,"%s is Timestamp " tsfmt "\n", testTime.toString(), ts);
testTime.day = 1;
testTime.hour = 0;
testTime.minute = 0;
testTime.sec = 0;
testTime.microsec = 0;
for(i=0; i<(sizeof(yrlist)/sizeof(yrlist[0])); ++i) {

testTime.year = yrlist[i];

testTime.month = mnlist[i];
fprintf(stdout,"%s is Timestamp " tsfmt "\n", testTime.toString(), utcToTimestamp(testTime));
}
return EXIT_SUCCESS;
}
#endif/* TEST */
E.10 Electromagnetic (EM) survey
An Electromagnetic survey is acquired using 100 receivers deployed on the sea floor, one source vessel towing a 300m
long source and 20 receivers connected to a streamer towed behind the source vessel. This hypothetical controlled source
electromagnetic (CSEM) setup is chosen to show all aspects of an EM survey. At the same time magnetotelluric (MT)
data will be recorded for all seafloor receivers.
Source Line 1023
Source Line 1024
Source Line 1025
Source Line 1026
Source Line 1027
Figure shows a overview of an Electromagnetic survey using EM sensors on the sea floor,
and a source vessels with towed sensors behind. Note: The relative sizes between equipment
are not correct.
Each seafloor sensor unit consists of 6 different magnetic and electric field sensors, which produces 6 different data
traces. The sensor units are completely independent, with no external synchronization while they are deployed. The sensor
units acquire data in SEGD format similar to the example described in E.8 Extended Recording Mode example.

Receiver 1
Receiver 2
Receiver 3
Receiver 4
Receiver 5
Receiver 6
Receiver 7
:
Receiver 98
Receiver 99
Receiver 100
Source
Towed Receiver 1
Towed Receiver 2
Towed Receiver 3
Towed Receiver 4
:
Towed Receiver 20
Line 1023 Line 1024 Line 1025 Line 1026 Line 1027 Time
Equipment deployed, and acquiring/generating data Production line
Figure shows an overview of production in an EM survey, with some sensors deployed on the seafloor, and
some attached to the source vessel.
The sensors are placed on the sea floor, and data are acquired organized in source lines. After several days the sensors are
retrieved, and the data from each sensor unit are read and stored in the acquisition system onboard the vessel as separate
files.
Seafloor receiver data:

The raw data records from each seabed sensor unit consists of 6 different channelsets, one for each different channel,
recorded as a continuous record using continuous recording mode, splitting traces into 120 second pieces (see E.8
Extended Recording Mode example for further information). As the raw data from each sensor unit is acquired using
drifting clocks, the data must be time drift corrected to match GPS time prior to merging with other sensor units.
Towed receiver data:

The data from source and towed receivers are acquired in 18 second normal SEG-D records (which matches the source
signal pattern cycle), i.e. each individual SEG-D record contains all source and towed receiver data for 18 seconds. The
auxiliary data for the source consists of the reference signal, and a measured signal (electrical field sensor close to the
source). The data from the source (auxiliary traces), and the towed sensors are synchronized to GPS as they are acquired,
and hence contains no time drift.
The client deliverable will be two datasets:

 CSEM: The data will be organized as SEG-D records containing data from all sensors organized into lines similar
to a Land/Seabed survey. The EM source emits a continuous signal, so there are no real source events like in
standard Marine/Land/Seabed surveys. The source however cycles through a signal pattern which is repeated
every 18 seconds, and it is decided to create SEG-D records matching this cycle. Hence, data will be stored as
normal SEG-D records each 18 sec long (not using extended recording mode).

 MT: The data will be organized into SEG-D records containing data from all seabed sensors for a period of time.
Since there are no source events, the record size may be arbitrarily chosen, in this example 120 seconds. The data
will then be grouped into one record set per day.
SEG-D records
Source SEG-D records
Towed receivers Source CSEM
Quality Control
Line 1052 All receivers dataset
Line 1052
1 file/multiple 1 file/multiple SEG-D

SEG-D records records per CSEM line
RAW SEG-D records SEG-D records

Seabed Sensor records
Unit 1 Sea floor recv 1-100
RAW SEG-D SEG-D records
Day 1
Seabed Sensor Unit 1 Sea floor recv 1-100
RAW SEG-D records Quality Control SEG-D records
Day 1
Seabed Sensor Unit 1 Time Drift Correction Sea floor recv 1-100
RAW SEG-D record Data Merge SEG-D records
Day 1
Seabed Sensor Unit 1 Sea floor recv
SEG-D 1-100
records
MT dataset
RAW SEG-D record Day 1
Seabed recv 1-100
Seabed Sensor Unit 1 Day 1
100 files/1 SEG-D 1 file/multiple SEG-D

record for each file, records per day
Extended recording
mode
Summary of data flow - extended recording mode records are blue, normal recording mode records are black.
The data from the seafloor sensors are stored in files (one per unit) containing all the data from the entire time the sensor
unit was deployed. Before the data from a sensor unit can be merged with other data, it is quality controlled and time drift
corrected.
CSEM
For each towline the data is selected from the active sensor unit records based on towline start and end time, and merged
with the records from the Source and Towed Receivers. The source data ends up as aux traces. The client deliverable
SEGD record contains data from the source and all sensors for the towline time period.
MT
For MT data, a record will contain all channels for all active receivers. A fixed record length is chosen, in this example
120 seconds, and multiple 120 sec SEG-D records for a given time period (in this example one day) is stored in each disk
file. If survey is a combined MT/CSEM survey, there is no need to remove CSEM data from the MT dataset.

Example CSEM SEG-D Block layout.
Length of record = nomnal wavelet length
SOURCE COORDINATE
ELECTROM ADDITIONAL Channel Set
General AUXILIARY REFERENCE Trace related data
AGNETIC SOURCE Descriptor
Header 1-3 CHANNEL SYSTEM See below
SOURCE INFO 1..N
REFERENCE IDENTIFICATION
Aux Data nominal source wavelet
EM Source
Trace Samples
Trace Hdr Description
Header Ext Nominal wavelet
(nominal)
Aux Data measured source waveform
EM Source Meaurement Position Relative

Trace Sensor Samples
Trace Hdr Sensor Info Description block block position block
Header Ext Calibration Measured waveform
(nominal) 1..N 1..N 1..N
EM MT / Electric field sea floor trace data (stationary nodes)
Sensor
Trace Time Orientaion Position EM Receiver
Trace Hdr Sensor Info Calibration EM Samples
Header Ext Drift Info block Description
1..N
EM MT / Electric field towed trace data (moving nodes)
Sensor
Trace Orientaion Position EM Receiver
Trace Hdr Sensor Info Calibration EM Samples
Header Ext Info 1..N block 1..N Description
1..N
Figure shows CSEM SEG-D record block layout (block sizes are not to scale)
This figure shows how to map EM specific data and header values into SEG-D. A few comments:
 Note that source position will have dipole midpoint in Position block and electrode position in the Relative
position blocks.
 Conductivity and other relevant data on the towfish will be in the Measurement blocks.
 The example covers both towed and stationary receivers. The actual selection of block configuration varies
between the two situations. The main difference is towed receivers will have multiple position and orientation
trace header blocks for the EM traces because the receiver is moving during the record.
E.11 Extended Recording Mode 2
This example deals with a more advanced usage of the Extended Recording mode. The Electromagnetic survey example
above (E.10) used Extended Recording mode to acquire data continuously from a sensor, with no connection to external
events.
This can be illustrated like this:

T01 T02 T03
RL RL
{acquisition
unit} time
Here T0x refers to the timestamp (Timestamp block) in each channelset, and the record length RL is the length of each
Channel Set. Hence the channel is acquired as one long continuous trace.
Land vibrator survey using autonomous acquisition nodes
Now consider a Land survey using vibrators as sources and a seismic spread consisting of autonomous acquisition
nodes.
The individual vibrator acquires an auxillary trace (base plate movement) every shot, which needs to be stored on the
vibrator until the end of the day when it is downloaded. The seismic sensors acquire data for several days before it is
picked up and the data downloaded.
The firing time T0 is distributed from the vibrators to the acquisition nodes which then records data for a certain time
(record length RL). For technical reasons the generation of source firing time is not synchronized with the acquisition
sample rate8. Also note that the record length of the traces are varying.
T01 T01+ T02 T02

+
T03
RL RL
{source}
{acquisition
unit} time
Both source and acquisition nodes will use Extended Recording Mode to store the data. Note there are holes in the data,
so the time stamp of the first sample of the next Channel Set is not given by the start of the previous plus the number of
samples in it multiplied by the sample rate.
Source
The source records an auxillary data Channel Set for each shot, and stores the Source Description block, Additional
Source Info block and the other source information as part of the Trace Header. (These may also be stored as part of the
General Header, but this limits the number of shots possible to store in one record.)
The following table shows the values of some important header fields for the SEG-D record:
8
Note it is highly recommended to synchronize source firing with the acquisition sample rate as this simplifies the
processing of the data. Not doing so also complicates the acquisition as the offset must be detected and recorded (as
sample skew or by using timestamp adjustment).

Byte No. Fmt Description Value
General Header block #3 (Timestamp and size header)
1-8 bin Time Zero for this record (SEG-D Time of T 01
timestamp).
29 ubin Extended Recording Mode 116
Channel Set Descriptor
5-8 bin Channel set number 1 2
5-8 bin Channel set start time (us) 0s 0s
9-12 bin Channel set end time (us) 0s 0s
13-16 bin Number of Samples 7000 5000
Demultiplexed Trace Header
7-9 bin First Timing Word (1/256 ms) 0s 0s
11 ubin Sample Skew (1/256 of the sampling 0 0
interval)
Timestamp Header
1-8 bin Time Zero for this data block T 01 T 02
Acquisition node
As the acquisition node is not synchronized with the source, the acquisition starts at the next sample after the source
event. At least two options exist for how this can be stored
1. Use the time of the timestamp of the following sample as time in Timestamp Header, and leave it to the
processing system to detect the skew between source and acquisition node.

1-8 bin Time Zero for this record (SEG-D 
Time of T 01
timestamp).
interval)
Timestamp Header
1-8 bin Time Zero for this data block  
T 01 T 02
2. Use the source time in the Timestamp Header block, and use Sample Skew in the trace header to indicate the
offset between source and acquisition node.

1-8 bin Time Zero for this record (SEG-D Time of T 01
timestamp).
interval)
Timestamp Header
1-8 bin Time Zero for this data block T0 T 02
1
It must be noted that a drawback of option 1 is that the data blocks in the different records do not have the same
timestamp (nodes have a different timestamp than the source). The consumer of the data must therefore find the nearest
match from all nodes.

Appendix F: Unit of Measure Integer Codes
Unit of Measure Integer Codes used in the SEG-D Measurement block are assigned by Energistics, which maintains the
current list of codes.
To request a modification of the integer codes, contact:
Energistics
Suite 1075
+1 281 243-2121 telephone
+1 281 243-2132 fax
[email protected]
http://www.energistics.org/
The following is a snapshot of the Energistics Unit of Measure Integer Codes v 0.9 (done on 11-apr-2012). For an updated
list please refer to http://www.energistics.org/unit-of-measure.
Energistics Unit of Measure

Integer Codes v0.9
This specification assigns an integer code to a subset of information in the Energistics Unit of
Measure specification. This initial version assigns integer codes to quantity class names and to the
“base for conversion” unit symbols in the draft v3.0a Energistics Unit of Measure (UOM)
specification.
The intent is to release version 1.0 of this specification when the Energistics Unit of Measure v3.0
specification is finalized. It is possible that the names and symbols will change when the UOM
specification is finalized but if they do then the v1.0 Code specification will map to those names if
the underlying semantics do not change. If the semantics change then the existing codes may be
deprecated but will not be deleted. If new classes are added to the final UOM specification then
new codes will be added to the Code specification.
The primary requirement for this specification is the “Society of Exploration Geophysicists” new
“SEGD Rev3.0” format that utilizes a two byte code for unit information in a special Measurement
Block.
Quantity Class Codes

Quantity Class Code
(mass per time) per area 1001
(mass per time) per length 1002
(mass per volume) per length 1003
(mole per time) per area 1004
(volume per time) length 1005
(volume per time) per area 1006

Quantity Class Code
(volume per time) per length 1007
(volume per time) per time 1008
(volume per time) per volume 1009
absorbed dose 1010
acceleration linear 1011
activity (of radioactivity) 1012
amount of substance 1013
angle per length 1014
angle per volume 1015
angular acceleration 1016
angular velocity 1017
area 1018
area per area 1019
area per volume 1020
attenuation 1021
attenuation per length 1022
capacitance 1023
concentration of B 1024
conductivity 1025
cross section absorption 1026
current density 1027
Darcy flow coefficient 1028
data transmission speed 1029
delta temperature 1030
diffusion coefficient 1031
digital storage 1032
dimensionless 1033
dose equivalent 1034
dose equivalent rate 1035
dynamic viscosity 1036
electric charge 1037
electric charge density 1038
electric charge per area 1039
electric conductance 1040
electric current 1041
electric dipole moment 1042
electric field strength 1043
electric potential 1044
electric resistance 1045
electrical resistivity 1046
electromagnetic moment 1047
energy 1048
energy length per area 1049
energy length per time area temperature 1050
energy per area 1051
energy per length 1052

Quantity Class Code
energy per volume 1053
exposure (radioactivity) 1054
force 1055
force area 1056
force length per length 1057
force per force 1058
force per length 1059
force per volume 1060
frequency 1061
frequency interval 1062
heat capacity 1063
heat flow rate 1064
heat transfer coefficient 1065
illuminance 1066
isothermal compressibility 1067
kinematic viscosity 1068
length 1069
length per length 1070
length per mass 1071
length per pressure 1072
length per temperature 1073
length per volume 1074
level of power intensity 1075
light exposure 1076
linear thermal expansion 1077
luminance 1078
luminous efficacy 1079
luminous flux 1080
luminous intensity 1081
magnetic dipole moment 1082
magnetic field strength 1083
magnetic flux 1084
magnetic flux density 1085
magnetic flux density per length 1086
magnetic permeability 1087
magnetic vector potential 1088
mass 1089
mass attenuation coefficient 1090
mass length 1091
mass per area 1092
mass per energy 1093
mass per length 1094
mass per mass 1095
mass per time 1096
mass per volume 1097
mobility 1098

Quantity Class Code
molar energy 1099
molar heat capacity 1100
molar volume 1101
mole per area 1102
mole per time 1103
moment of force 1104
moment of inertia 1105
momentum 1106
nonDarcy flow coefficient 1107
normalized power 1108
parachor 1109
per area 1110
per electric potential 1111
per force 1112
per length 1113
per mass 1114
per pressure 1115
per time 1116
per volume 1117
permeability length 1118
permeability rock 1119
permeance 1120
permittivity 1121
plane angle 1122
potential difference per power drop 1123
power 1124
power per area 1125
power per power 1126
power per volume 1127
pressure 1128
pressure per time 1129
pressure squared 1130
pressure squared per force (time per area) 1131
pressure time per volume 1132
productivity index 1133
quantity of light 1134
radiance 1135
radiant intensity 1136
reluctance 1137
resistivity per length 1138
second moment of area 1139
solid angle 1140
specific activity (of radioactivity) 1141
specific energy 1142
specific heat capacity 1143
specific productivity index 1144

Quantity Class Code
specific volume 1145
temperature per length 1146
temperature per pressure 1147
temperature per time 1148
thermal conductance 1149
thermal conductivity 1150
thermal diffusivity 1151
thermal insulance 1152
thermal resistance 1153
thermodynamic temperature 1154
time 1155
time per length 1156
time per mass 1157
time per time 1158
time per volume 1159
unit productivity index 1160
velocity 1161
volume 1162
volume flow rate per volume flow rate 1163
volume per area 1164
volume per length 1165
volume per pressure 1166
volume per rotation 1167
volume per time 1168
volume per volume 1169
volumetric heat transfer coefficient 1170
volumetric thermal expansion 1171

Unit Symbol Codes
Symbol Code Symbol Code Symbol Code
% 2001 kg 2050 O 2099
1/H 2002 kg.m 2051 ohm 2100
1/K 2003 kg.m/s 2052 ohm.m 2101
1/kg 2004 kg.m2 2053 ohm/m 2102
1/m 2005 kg/(m2.s) 2054 Pa 2103
1/m2 2006 kg/J 2055 Pa.s 2104
1/m3 2007 kg/m 2056 Pa.s/m3 2105
1/N 2008 kg/m2 2057 Pa.s/m6 2106
1/Pa 2009 kg/m3 2058 Pa/m3 2107
1/s 2010 kg/m4 2059 Pa/s 2108
1/V 2011 kg/s 2060 Pa2 2109
A 2012 lm 2061 rad 2110
A.m2 2013 lm.s 2062 rad/m 2111
A/m 2014 lm/W 2063 rad/m3 2112
A/m2 2015 lx 2064 rad/s 2113
B 2016 lx.s 2065 rad/s2 2114
B.W 2017 m 2066 S 2115
B/m 2018 m/K 2067 s 2116
B/O 2019 m/kg 2068 s/kg 2117
bit 2020 m/Pa 2069 S/m 2118
bit/s 2021 m/s 2070 s/m 2119
Bq 2022 m/s2 2071 s/m3 2120
Bq/kg 2023 m2 2072 sr 2121
C 2024 m2/(Pa.s) 2073 Sv 2122
C.m 2025 m2/kg 2074 Sv/s 2123
C/kg 2026 m2/mol 2075 T 2124
C/m2 2027 m2/s 2076 T/m 2125
C/m3 2028 m3 2077 V 2126
cd 2029 m3/(Pa.s) 2078 V/B 2127
cd/m2 2030 m3/(Pa2.s2) 2079 V/m 2128
F 2031 m3/J 2080 W 2129
F/m 2032 m3/kg 2081 W/(m.K) 2130
Gy 2033 m3/mol 2082 W/(m2.K) 2131
H 2034 m3/Pa 2083 W/(m2.sr) 2132
H/m 2035 m3/rad 2084 W/(m3.K) 2133
Hz 2036 m3/s 2085 W/K 2134
J 2037 m3/s2 2086 W/m2 2135
J/(kg.K) 2038 m4 2087 W/m3 2136
J/(mol.K) 2039 m4/s 2088 W/sr 2137
J/K 2040 mol 2089 Wb 2138
J/kg 2041 mol/(s.m2) 2090 Wb.m 2139
J/m3 2042 mol/m2 2091 Wb/m 2140
J/mol 2043 mol/m3 2092
K 2044 mol/s 2093
K.m2/W 2045 N 2094
K/m 2046 N.m2 2095
K/Pa 2047 N/m 2096
K/s 2048 N/m3 2097
K/W 2049 N4/(kg.m7) 2098

SEG-D Rev3 0 Format Jun2012

Uploaded by

Copyright:

Available Formats

SEG-D Rev3 0 Format Jun2012

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SEG-D Rev3 0 Format Jun2012

Uploaded by

Copyright:

Available Formats

SEG-D, Rev 3.

The following individuals have been active participants in this effort:

Jill Lewis Troika International Technical Standards Chair

Numerous other people have also participated at various times.

SEG-D Rev 3.0 5 June 2012

Society of Exploration Geophysicists

Attention: SEG Technical Standards Committee

SEG-D Rev 3.0 6 June 2012

1. Revision number changed from 2.1 to 3.0, see

SEG-D Rev 3.0 7 June 2012

23. Allow recording data in 64 bit IEEE

SEG-D Rev 3.0 8 June 2012

8080 64 bit IEEE float demultiplexed

32. Several examples have been added to Appendix E.

33. Revision 2.x Appendix D “Header Descriptors” has been removed.

SEG-D Rev 3.0 9 June 2012

SEG-D Rev 3.0 10 June 2012

8. The maximum number of Trace Header Extensions is now limited to 15.

EFH3 EFH2 EFH1 EFH0 THE3 THE2 THE1 THE0

SEG-D Rev 3.0 11 June 2012

A) Variable block length devices.

C) Fixed block length devices

SEG-D Rev 3.0 12 June 2012

2.3 Changes Introduced in Rev 1

SEG-D Rev 3.0 13 June 2012

11. Allow recording data in IEEE and other new formats.

0036 24 bit 2's compliment integer multiplexed

The IEEE format is fully documented in the IEEE standard,

The IEEE format is summarized as follows:

if e = 255 & f ≠ 0. .v = NaN Not-a-Number (see Note 2)

where e = binary value of all C's (exponent)

SEG-D Rev 3.0 14 June 2012

TR=0 No edit of this trace

SEG-D Rev 3.0 15 June 2012

SEG-D Rev 3.0 16 June 2012

Record Header Trace Data Record Trailer

Start or record End or record

SEG-D Rev 3.0 17 June 2012

SEG-D Rev 3.0 18 June 2012

SEG-D Rev 3.0 19 June 2012

SEGD channel description header

SEGD record header

Trace 1 Trace 2 Trace n1 Trace 1 Trace n2 Trace 1 Trace nn

Channelset 1 Channelset 2 Channelset n

Scantype 1 Scantype 2 Last scantype

Trace header (up to 8180 bytes)

Figure 1. Record Format

SEG-D Rev 3.0 20 June 2012

Record Header (partial)

Data Chs 1 / Tr 1 Trace Header

Data Channelset n/Trace nn

General Trailer, block 1

General Trailer, block ntrailer

Maximum Physical Block Length of Device

Figure 2. Variable Block Length Format Example

SEG-D Rev 3.0 21 June 2012

Record Header (partial)

Data Chs 1 / Tr 1 Trace Header Data Chset 1 / Trace 2

Data Channelset n/Trace nn Pad (0x0)