Seg 2SEG standards

7/27/2019 Seg 2SEG standards

1/20

1 of 20

Recommended standard for seismic (/radar) data tiles in the personalcomputer environment1

Subcommittee of the SEG Engineering and Groundwater GeophysicsCommittee, S. E Pullan, Chairman2

11990 Society of Exploration Geophysicists. All rights reserved.This report is the work of the Subcommittee of the SEG Engineering and Groundwater Geophysics

Committee

2Geological Survey of Canada, 601 Booth St., Ottawa, Ont. Canada KIA OES.

This paper is the result of the work of asubcommittee of SEG's Engineering andGroundwater Geophysics Committee. Itrecommends a data file format for raw or

processed shallow seismic or digital radardata in the small computer environment. It isrecommended that this format be known asthe SEG-2 format.

INTRODUCTION

The application of seismic reflection andground-penetrating radar methods toengineering, groundwater, andenvironmental problems has increaseddramatically over the last 10 years, spurred

by the rapid development of newinstrumentation and personal computers.This "coming of age" of shallow reflectiontechniques has been accompanied by therecent development of several differentsoftware packages for processing anddisplaying data. However, this expansion inthe user's processing potential has been,somewhat hindered by the lack of astandard data format. All software packageshave been based on their own, or amanufacturer's, specific data format.

At the October 1987 meeting of SEG's

Engineering and Groundwater GeophysicsCommittee, it was agreed in principle that astandard format for engineering seismicdata in the personal computer environment

was needed, and a subcommittee wascreated to set up such a standard. Thispaper is the result of the work of thatsubcommittee. The standard format

This document has been converted from the original publication:

Pullan, S. E., 1990, Recommended standard for seismic (/radar) files in the personalcomputer environment: Geophysics, 55, no. 09, 1260-1271.

FIG. 1. File format


2/20

2 of 20

recommended in this paper is a file formatfor raw or processed shallow seismic ordigital radar data in the small computerenvironment. It is not expected that data willnecessarily be stored or recorded by

recording instruments in this format.However, instrument manufacturers areasked to provide the means of transferringdata acquired by their instruments into thisformat. It is hoped that software developers

FIG. 2, File descriptor block.


3/20

3 of 20

may then assume that data from any sourcewill be input to their programs in this format

STANDARD SPECIFICATION

II. ScopeThis is a recommended standard for theconstruction of seismic or digital radar datafiles in personal computer environments.The seismic (/radar) data may be either rawdata or processed data organized in one ormore blocks of trace data. The computerenvironment includes but is not limited toIBM and compatible computers runningDOS or OS/2, Macintoshes, and UNIX workstations. This standard specifies a format forplacing raw or processed data samples with

associated overhead information on to onefile for access by application programs. Thisstandard does not involve itself with filemanagement concerns such as how dataare put on disk or tape media.

II. Requirements for standard

This standard shall be a free-form standardcapable of allowing as much or as littleoverhead data as the data-generatingapplication software or recordingseismograph can provide. It shall not

depend on the nuances of oneprogramming language, and shall providefor the sharing of data by any of thepersonal computers or workstationscommonly used for processing seismic datatoday and into the foreseeable future. Thisstandard shall be easy to maintain andrequire a minimum of revision.

The position of overhead data within the filemust not be critical. It must not benecessary to put in blank lines for missingdata. Instead, each data item should be in a

string with an identifying keyword. In thisway, included data items may be chosenfrom a large list of possible items withoutcreating extremely large and cumbersomedata files.

Care must be taken not to assume tokenand line delimiters such as NULLcharacters, CR, CR/LF, etc. Instead this

information and other informationdependent upon the data-generatingcomputer, language, and operating systemshould be included in the file in knownlocations to allow other computers andsoftware the ability to parse the overhead

data and properly interpret the data.

III. Proposed format

A. File structure

The file consists of a File Descriptor Block,one or more Trace Descriptor Blocks, andone or more Data Blocks. The FileDescriptor Block provides informationrequired to parse the rest of the overheaddata and other information common to alltraces in the file. Each Trace DescriptorBlock corresponds to one Data Block andprovides location, format, and otherinformation pertinent to that Data Block. TheData Blocks immediately follow theircorresponding Trace Descriptor Blocks andconsist of fixed point or floating pointnumbers as specified in the TraceDescriptor Block. There is a one to onecorrespondence between Data Blocks andTrace Descriptor Blocks. The blocks mustbe arranged in the prder shown in figure 1..

Pointers are used to indicate locations ofblocks with respect to the beginning of thefile. Pointers are always unsigned longintegers (32 bits) rather than the segment:offset format common to some processors.

All addressing is to byte boundaries. Allblocks must start on double word (32 bit)boundaries.

B. Block structures

B1. File Descriptor Block.

The first block in the file is the FileDescriptor Block. The construction of theFile Descriptor Block is shown in Figure 2.This block is required and holds informationpertaining to the structure and interpretationof the file and data common to all traces inthe file This block consists of (i) 32 bytesproviding the block identifier, file standardrevision number, size of the Trace Pointer


4/20

4 of 20

Subblock (see below), number of traces inthis File, string and line terminatorinformation; (ii) a Trace Pointer Subblockgiving pointers to the start of each TraceDescriptor Block in the file; and (iii) a seriesof optional strings which contain information

such as the type of data to follow,acquisition parameters, etc, and any notesthat may incorporate operator observationsand/or environmental descriptions whichapply to the entire file.

The first two bytes (bytes 0 and 1) of thisblock (and of the file) contain the integer3a55h. This integer identifies the file as aseismic (/radar) data file following thisstandard, identifies this block as the FileDescriptor Block, and provides the means todetermine whether the Iow byte (least-significant bits) of multibyte entities iswritten first or last. If the first byte of the fileis 55h, the file is recorded low byte first ason an IBM PC; but if the first byte is 3ah, thefile is recorded Iow byte last as on some68000 based UNIX machines.

The next two bytes (bytes 2 and 3) containan integer stating the revision number ofthis standard used by the data-generatingdevice or program. The version defined bythis paper shall be referred to as version 1.

Bytes 4 and 5 contain an unsigned integergiving the size (M) of the Trace PointerSubblock in bytes. The integer byte order ofthis and all following integers is interpretedaccording to the first two bytes of this fileThis number, as ail block sizes, must bedivisible by 4 since all blocks must start ondouble word boundaries. This number mustbe between 4 and 65,532.

Within these restrictions, the size of thissubblock is completely up to the user. Forexample, it could be just large enough to

hold the pointers to the 12 Trace DescriptorBlocks corresponding to a single recordfrom a 12-channel seismograph (i.e. 48bytes); or it could be large enough to holdthe pointers to all processed traces in anentire seismic (/radar) line. The subblockdoes not have to be full; the number oftraces actually contained in the file (N) is

specified in bytes 6 and 7. N is an unsignedinteger with an allowable range of 1 to16,383. N must be less than or equal toM/4.

The String Terminator is one or two

nonprintable ASCII characters (decimalASCII codes 0 through 31) used to separatethe strings that hold the information incharacter string form in this block (the FileDescriptor Block) and the Trace DescriptorBlocks. Byte 8 is 01h or 02h depending -Characters in the String Terminator and thetwo following bytes contain the StringTerminator characters. If only one characteris used, that character is in byte 9.

The Line Terminator is one or twononprintable ASCII characters (normally CR

or CR and LF) used to separate the lines oftext in a NOTE string. Byte 11 is 01h or 02hdepending on the number of characters inthe Line Terminator and the two followingbytes contain the Line Terminatorcharacters. !f only one character is usedthat character is in byte 12,

The restriction of allowable String and LineTerminators to nonprintable ASCIIcharacters is to avoid any potential conflictswith the characters allowed in the definitionof such strings as JOB-iD, etc.

Bytes 14 through 31 are reserved.

The Trace Pointer Subblock starts at byte32, and contains pointers (unsigned longintegers) to the start of each TraceDescriptor Block contained in the file Thelength of this subblock in bytes (M) isspecified in bytes 4 and 5, and the numberof pointers contained in the subblock (N) isspecified in bytes 6 and 7 (see above). Thisfixed format allows a file to be built up onetrace at a time by upgrading the value N

and adding a pointer to the new trace in theTrace Pointer Subblock, but withoutotherwise changing the file format.

Following the Trace Pointer Subblock is afree format section containing strings toprovide optional information pertinent to ailtraces in the record. Each string starts withan offset to the next string, is followed by a


5/20

5 of 20

keyword and related parameters, and isterminated by the string terminator (seesection C on String Formats below).

B2. Trace Descriptor Block.

There is a one to one correspondence

between Data Blocks and the TraceDescriptor Block that describes that DataBlock. The file must contain at least oneTrace Descriptor Block and of the TraceDescriptor Block is shown in Figure 3. Thefirst thirty-two bytes must be included toprovide the block identifier, the size of the

block, the size of the Data Block, and thedata format code. The strings follow withinformation pertinent to that block such asreceiver and shot locations, sample rate,delay, stack count, etc.

The first two bytes contain the unsignedinteger 4422h to identify this block as aTrace Descriptor Block. Bytes 2 and 3contain an unsigned integer giving the sizeof this block in byes. This number, as allblock sizes, must be divisible by 4 since allblocks must start on double wordboundaries. This number must be between

FIG. 3. Trace descriptor block


6/20

6 of 20

32 and 65,532.

Bytes 4 through 7 contain an unsigned long(32 bit) integer giving the size of thefollowing Data Block in bytes. This numbermust be divisible by 4. Bytes 8 through 11

contain an unsigned long integer giving thenumber of samples in the Data Block.

Byte 12 specifies the format of the data inthe following Data Block according to thetable below:

ByteValue

Data Format

01h 16-bit fixed point

02h 32-bit fixed point

03h 20-bit floating point (SEG-D)

04h 33-bit floating point (IEEEstandard)

05h 64-bit floating point (IEEEstandard)

The fixed point formats imply the2'slcomplement convention. All formats aredefined in Appendix B.

Bytes 13 through 31 are reserved.

A series of free format strings providinginformation on the acquisition or processinghistory of the data are found starting at byte32. Any number of these strings may beincluded depending on the nature of thedata or the processing applied. Somestrings will obviously be required for mostprocessing or display sequences that maybe applied to the data, and every effortshould be made to include all pertinentinformation in this section of the TraceDescriptor Blocks. especially in raw data

files. The string format is discussed below insection C.

B3. Data Block.

A Data Block follows each Trace DescriptorBlock. Each Data Block is a collection ofnumbers of the size and in the formatspecified in the preceding Trace DescriptorBlock.

C. String format

The File and Trace Descriptor Blockscontain strings that provide other required oroptional information. All strings start with anoffset (2 bytes) to the next string and akeyword that identifies the nature of thestring, contain a numeric and/oralphanumeric value(s), and end with thestring terminator indicated in the FileDescriptor Block. An offset of 0 (2 bytes),after the final string, marks the end of thestring list. Keywords cannot have embeddedspaces. The keyword and the associateddata are separated by spaces or tabs. Allalpha characters in the keywordsthemselves must be uppercase. Where theargument associated with a keyword ischosen from a list of specified words, thearguments themselves cannot haveembedded spaces and must be inuppercase characters. Not all stringsmentioned need be included in thedescriptor blocks. Unrecognized keywordswill not terminate the process. To assistapplication program string searches, stringsmust be ordered alphabetically according tokeyword. The only exception to this rule isthe NOTE string, which is always at the endof the string list, if it exists at all.

Numeric values may be decimal integers ordecimal floating point numbers. Negativedecimal numbers are preceded by a minussign (-). Decimal floating point numbers mayuse an "E" to express the number inscientific notation. Decimal points must befollowed by a numeric character. Thenumbers in the following list are allowablenumeric expressions. Unless statedotherwise, integers must have magnitudeless than 32,000 116 bits).

12,-3, 12.657, -34.6, 1.34SE24,-2.3E6,

5.6E-11, -2.0E-9

Some values like time and date may beexpressed in the recommended formatindicated below. Examples of the stringsubblocks that may be found in a FileDescriptor Block and Trace Descriptor Blockare shown in Appendix C.


7/20

7 of 20

C1. Strings that may be included in the FileDescriptor Block.

The File Descriptor Block may contain anyor all of the following strings. The keywordsthemselves must be in uppercasecharacters and cannot have embeddedspaces. Where keywords are two or morewords, the words are separated by anunderscore (decimal ASCII code 95). Wherethe argument associated with a keyword ischosen from a list of specified words, thearguments themselves cannot haveembedded spaces and must be inuppercase characters. The keywords mustbe arranged in alphabetical order except forthe NOTE string, which will be at the end ofthe string list, if it exists at all. The stringsthat are likely to be required by application

software routines are denoted with anasterisk. It is strongly recommended thatthese strings exist in all File DescriptorBlocks.

ACQUISITION_DATE

It is recommended that the date bespecified in dd/mm/yyyy format. Underthis convention, April 1, 1988, would bestored as 01/04/88. Alternatively, inorder to avoid any possible confusion inthe ordering of the day and month, the

date could be in dd/mmm/yyyy format,with mmm being a three-letterabbreviation of the month. For example,

April 1, 1988 would be stored as01/APR/1988

ACQUISITION_TIME

It is recommended that the time bestored in the 24-hour hh:mm:ss format.For example, 3:30 PM would be storedas 15:30:00.

CLIENT

Name of company or organizationsponsoring data acquisition andprocessing.

COMPANY

This is the name of the companyresponsible for acquiring and/orprocessing the data.

GENERAL_CONSTANT

This value must be a positive decimalnumber of t2 or fewer digits.

INSTRUMENT

This identifies the instrument used toacquire the data in the file.

JOB_ID

The JOB-ID can be any string ofprintable ASCII characters (decimal

ASCII codes 32 through 126).

OBSERVER

The name of the individual responsiblefor data acquisition.

PROCESSING_DATE The date a processed file was created.The date is specified as described in

ACQUISITION_DATE.

PROCESSING TIME

The time a processed file was created.The time is specified as described in

ACQUISITION_TIME.

*TRACE-SORT

The sort method can be

AS_ACQUIRED, CDP_GATHER,CDP_STACK, COMMON_OFFSET,COMMON_RECEIVER, orCOMMON_SOURCE.

*UNITS

This defines the linear units usedthroughout this file. Allowable systemsare FEET, METERS, INCHES,CENTIMETERS or NONE. If NONE isselected, all measurement interpretationmust be made by the user.

NOTE

This string appears as the last string inthe list if it exists at all. The format ofthis string differs from all other strings inthat it may contain several lines of text.Each line of text is terminated by theLine Terminator indicated in the File


8/20

8 of 20

Descriptor Block. The end of the stringis indicated by the String Terminator.

C2. Strings that may be included in theTrace Descriptor Block.

The Trace Descriptor Block may contain

any or all of the following strings. Thekeywords themselves must be in uppercasecharacters and cannot have embeddedspaces. Where keywords are two or morewords, the words are separated by anunderscore (decimal ASCII code 95). Wherethe argument associated with a keyword ischosen from a list of specified words, thearguments themselves cannot haveembedded spaces and must be inuppercase characters. The keywords mustbe arranged in alphabetical order except for

the NOTE string, which will be at the end ofthe string list, if it exists at all. The stringsthat are likely to be requiredby applicationsoftware routines are detected with anastrisk. It is strongly recommended thatthese strings exist in all Trace DescriptorBlocks.

ALIAS_FILTER< frequency > < slope >

The ALIAS_FILTER values are decimalinteger or floating point numbers (can bemixed) expressing the anti-aliasing filter

3 dB frequency in Hz and slope in dBper octave A value of 0 for thefrequency indicates and anti-aliasingfilter was not implemented.

AMPLITUDE_RECOVERY

The method can be NONE, AGC,SPHERICAL_DIVERGENCE, or anyappropriate description of the methodused. If AMPLITUDE_RECOVERY isincluded in the string list, some method

must be specified immediately after thekeyword. The parameter list is thecollection of parameters related tomethod, such as ACC window.

BAND_REJECT_FILTER < Iowpass freq >< Iowpass slope> < highpass freq >

The BAND_REJECT_FILTER valuesare decimal integer or floating pointnumbers (can be mixed) expressing theIow-pass 3 dB frequency in Hz andslope in dB per octave, followed by thehigh-pass 3 dB frequency in Hz and

slope in dB per octave. Theseparameters specify a band-reject filterapplied by the seismograph during dataacquisition. Values of 0 for thefrequency parameters indicate the filterwas not implemented.

CDP_NUMBER

The CDP_NUMBER is a decimal integerassigned to a particular CDP gather orstacked trace

CDP_TRACE

The CDP_TRACE is a positive decimalinteger giving the trace number withinthe CDP gather. Each gather starts withtrace number one.

CHANNEL_NUMBER

The channel number is a positiveinteger less than 32,000 identifying thereceiver group channel of the recordinginstrument associated with the datacorresponding to the Data Block. If the

CHANNEL_NUMBER string is used inone Trace Descriptor Block, it must beused in all Trace Descriptor Blocks inthe File. More than one Data Block maybe associated with oneCHANNEL_NUMBER if this isnecessary to accommodate suchspecial circumstances as dynamicallyswitched sample rates, time gaps, orother aberrations. All Data Blocks thatare associated with one channel mustbe arranged such that earlier data

precede later data, and data b;ockscannot overlap in time.

DATUM < value >

The DATUM is a decimal integer orfloating point number giving theelevation (understood to be with respectto mean sea level) about which thesource and receiver locations (z-values)


9/20

9 of 20

are specified. The value is given in theunits specified in the "UNITS" string ofthe File Descriptor Block.

*DELAY

The value is a floating point number

expressing the time (in seconds)elapsed from the start pulse to recordingthe first sample in the Data Block.

DESCALING_FACTOR

The DESCALING_FACTOR is a floatingpoint number used to get the voltage inmillivolts from a sample value accordingto the formula: voltage due to one shot =data point xDESCALING_FACTOR/STACK

DIGITAL_BAND_REJECT_FILTER < Iowpass slope < highpass slope >

The DIGITAL_BAND_REJECT_FILTERvalues are decimal integer or floatingpoint numbers (can be mixed)expressing the Iow-pass 3 dB frequencyin Hz and slope in dB per octave,followed by the high-pass 3 dBfrequency in Hz and slope in dB peroctave These parameters specify adigital band reject filter applied after

data acquisition or during processing.Values of 0 for the frequencyparameters indicate the filter was notimplemented

DIGITAL_HIGH_CUT_FILTER

The DIGITAL_HIGH_CUT_FILTERvalues are decimal integer or floatingpoint numbers (can be mixed)expressing the highcut filter 3 dBfrequency in Hz and slope in dB per

octave of a digital filter applied after dataacquisition or during processing. A valueof 0 for the frequency indicates the filterwas not implemented.

DIGITAL_LOW_CUT_FILTER < frequency>

The DIGITAL_LOW_CUT_FILTERvalues are decimal integer or floating

point numbers (can be mixed)expressing the Iow-cut filter 3 dBfrequency in Hz and slope in dB peroctave of a digital filter applied after dataacquisition or during processing. A valueof 0 for the frequency indicates the filter

was not implemented.

END_OF_GROUP

The END_OF_GROUP is used to flag atrace (or traces) within the file as the lasttrace (s) in a user-defined group or sort.

A value of 1 indicates that this trace isthe last trace in the group; the only otherallowable value is zero.

FIXED_GAIN

If a fixed-gain recording instrument was

used, this integer value gives the gain indB (including preamp) applied by therecording instrument to this trace duringrecording.

HIGH_CUT_FILTER

The HIGH_CUT_FILTER values aredecimal integer or floating pointnumbers (can be mixed) expressing thehighcut 3 dB frequency in Hz and slopein dB per octave applied by theseismograph during data acquisition. A

value of 0 for the frequency indicatesthe filter was not implemented.

LINE_ID

The LINE_ID can be any string ofprintable ASCII characters (decimal

ASCII codes 32 through 126).

LOW_CUT_FILTER

The LOW_CUT_FILTER values aredecimal integer or floating pointnumbers (can be mixed) expressing the

Iow-cut filter 3 dB frequency in Hz andslope in dB per octave applied by theseismograph during data acquisition. Avalue of 0 for the frequency indicatesthe filter was not implemented.

NOTCH_FREQUENCY

The NOTCH_FREQUENCY value is apositive decimal integer or floating point


10/20

10 of 20

number expressing the notch-filterfrequency in Hz. A value of 0 indicates anotch filter was not implemented.

POLARITY

The only allowed values are 1 and -1,

depending upon whether an upwardground movement at the phone causesa positive or negative data sample.

RAW_RECORD

The RAW_RECORD gives the file name(and extension) of the raw data file fromwhich this trace was derived.

RECEIVER

Receivers could be, for example,

VERTICAL_GEOPHONE,SH_HORIZONTAL_GEOPHONE,SV_HORIZONTAL_GEOPHONE,

ACCELEROMETER, ANTENNA, or anyappropriate description of the type ofreceiver used. If a second parameter isgiven, it specifies the number ofreceivers per receiver group.

RECEIVER_GEOMETRY [in] < x value > [ < z value > ]

This is the location of the nth receiver of

a receiver group with respect to thespecified RECEIVER-LOCATION (seebelow). The x, y, and z values may bedecimal integers or decimal floatingpoint numbers, and are to be given inthe units specified in the "UNITS" stringof the File Descriptor Block. If only onevalue is stated, it is understood to be thedimension along the line (i.e., x).Otherwise, all three values must begiven, in order to avoid ambiguity withregard to the meaning of a second value

The z value is understood to define theelevation or depth (e.g., in a borehole),with positive values implying the upwarddirection, and negative values implyingthe downward direction, about theDATUM defined above.

RECEIVER_LOCATION [ ]

This is the location of a receiver orcenter of the receiver group with respectto the start of line, or any by the user.The x, y, and z values may be decimalintegers and/or decimal floating pointnumbers, and are to be given in the

units specified in the "UNITS" string ofthe File Descriptor Block. If only onevalue is stated, it is understood to be thedimension along the line (i.e., x).Otherwise all three values must begiven, in order to avoid ambiguity withregard to the meaning of a second valueThe z value is understood to define theelevation or depth (e.g., in a borehole),with positive values implying the upwarddirection and negative values implyingthe downward direction. This value is

understood to be given with respect tothe DATUM defined above.

RECEIVER_SPECS < manufacturer name> < model number or frequency >

This is the name of the manufacturerand model number and/or frequency ofthe receivers used to acquire the data.

RECEIVER_STATION_NUMBER

The RECEIVER_STATION_NUMBER isa decimal integer assigned to a

particular receiver location.*SAMPLE-INTERVAL

The value is a floating point numberexpressing the period between samplesin seconds.

SHOT_SEQUENCE_NUMBER < value >

The SHOT_SEQUENCE_NUMBER is apositive decimal integer that the userassigns to the original field file to allow auser-defined sequential ordering of files

(or traces) during subsequentprocessing runs.

SKEW

The SKEW value of a channel is afloating point number expressing thetime in seconds between the time therecording instrument starts a samplescan along all the channels, and the


11/20

11 of 20

time data were actually acquired at thistarticular channel.

SOURCE < source > < parameter list >

Source can be HAMMER,WEIGHT_DROP, GUN, DYNAMITE,

VIBRATOR, or any appropriatedescription of the source used. Theparameter list may specify any furtherinformation about the source; such asthe size of the hammer or weight drop,the type of shells fired, size and type ofcharge detonated, or the sewwpfrequencies, etc of the vibrator.

SOURCE_GEOMETRY [n/N] [ ]

This is the location of the nth element of

a source array (consisting of Nelements) with respect to the specifiedSOURCE_LOCATION (see below). Thex, y and z values may be decimalintegers or decimal floating pointnumbers, and are to be given in theunits specified in the "UNITS" string ofthe File Descriptor Block. If only onevalue is stated, it is understood to be thedimension along the line (i.e., x).Otherwise, all three values must begiven, in order to avoid ambiguity with

regard to the is understood to define theelevation or depth (e.g., in a shothole),with positive values implying the upwardand negative values implying thedownward direction, about the DATUMdefined above.

SOURCE_LOCATION [ < Yvalue > < z value >]

This is the location of the source (orcenter of a source array) with respect tothe start of line, or any fixed point

defined by the user. The x, y, and zvalues may be decimal integers and/ordecimal floating point numbers, and areto be given in the limits specified in the"UNITS" string of the File DescriptorBlock. If only one value is stated, it isunderstood to be the dimension alongthe line (i.e., x). Otherwise, all threevalues must be given: in order to avoid

ambiguity with regard to the meaning ofa second value. The z value isunderstood to define the elevation ordepth (e.g., in a shothole), with positivevalues implying the upward directionand negative values implying the

downward direction. This value isunderstood to be defined with respect tothe DATUM defined above.

SOURCE_STATION_NUMBER < value >

The SOURCE_STATION_NUMBER is adecimal integer assigned to a particularsource location.

STACK

This stack-count is a positive integerindicating the number of shots which

were summed to obtain this trace.

STATIC_CORRECTIONS < source static >< receiver static >

The 3 values specified afterSTATIC_CORRECTIONS are floatingpoint numbers expressing the time shifts(in seconds) that are attributed to thesource and receiver, and the total staticcorrection applied to the data in thefollowing Data Block. If no staticcorrection has been applied to the data,

the third value is zero.TRACE_TYPE

The trace type is SEISMIC_DATA,DEAD, TEST_DATA, UPHOLE, orRADAR_DATA.

NOTE < text >

This string appears as the last string inthe list if it exits at all. The format of thisstring is as described under the NOTEstring in section C1 above.

Acknowledgments

This standard is the result of input from alarge number of people representinginstrument manufacturers, softwaredevelopers, and a number of interestedusers. Although they are too numerous toname here, their comments andsuggestions have been much appreciated


12/20

12 of 20

and have greatly contributed to the finalresult.

The contributions of Badru Hyatt fromEG&G Geometries, Sunnyvale, California,and Ted Norminton from Carleton

University, Ottawa, Ontario, must beespecially recognized. Badru wasresponsible for writing the first draft of thestandard, and both Badru and Ted havebeen involved in discussions of all thechanges and modifications that have beenmade along the way.

References

Barry K. M., Cavers, D. A., and Kneale, C.W., 1975. Recommended standards fordigital tape formats: Geophysics, 40, p344-

352.Digital field tape format standard SEG D:in Digital Tape Standards, 1980, Soc.Explor. Geophvs. p31-65

IEEE Standard for binary floating - pointarithmetic: ANSI/IEEE Standard 754-1985,18 p.


13/20

13 of 20

APPENDIX A

DEFINITIONS

Byte

an 8 bit valueif signed this value can range from -128 . . .127if unsigned this value can range from 0 . . .255

Integer

a 16 bit valueif signed this value can range from -32768 .. . 32767if unsigned this value can range from 0 . . .65535

Long integer

a 32 bit valueif signed this value can range from-2147483648 . . . 2147483647if unsigned this value can range from 0 . . .4294967295

Decimal integer

a base ten integere.g., 12, -3, 10, 352, -511, etc

Decimal floating point number

a base ten floating point number which mayuse an "E" to express the number inscientific notation e.g., 12657, -34.6,1.345E24, -2.3E6, 5.61E-11, -2.0E-9


14/20

14 of 20

APPENDIX B

SPECIFICATION OF ALLOWABLEDATA FORMATS

Fixed point formats

The two fixed point formats allowed by thisstandard are specified as described in Barryet al. (1975). Both formats imply the 2'scomplement convention.

FIG. B-1. Description of one data sample in 16-bit fixed point format (S= sign bit QD = data bit, HB = high byte, LB = Iow byte (least significantbits), msb = most significant bit, lsb = least-significant bit). In this casethe msb is the value corresponding to 214, while the Isb is the valuecorresponding to 2. Note that the order of the two bytes (i.e., LBbefore or after HB) is dependent on the specification of the first twobytes of the File Descriptor Block.

FIG. B-2. Description of one data sample in 32-bit fixed-point format (S= sign bit, (QD = data bit, HB = high byte LB = Iow byte (leastsignificant bits) msb = most significant bit, Isb = least significant bit). Inthis case the msb is the value corresponding to 230, while the Isb is thevalue corresponding to 2. Note that, the order of the four bytes (i.e.,LB first or HB first) is dependent on the specification of the first twobytes of the File Descriptor


15/20

15 of 20

1. 16-bit fixed point format (data formatcode = 01h)

The 16-bit fixed point format uses twosuccessive bytes to record each datasample. Each sample consists of a sign-bit

S (1 implies negative) and 15 data bits QD.with a radix point at the right of the leastsignificant bit. The format is shownschematically in Figure B-1.

16-bit fixed point format numbers are of the2's complement type [i.e., if (a) is a 16-bitfixed point number, then (a) + (- a) = 216].For example,

1 (dec) = 0000 0000 0000 00011 (dec) = 0000 0000 0000 00011 (dec) = 0000 0000 0000 00011 (dec) = 0000 0000 0000 0001

----1 (dec) = 1111 1111 1111 11111 (dec) = 1111 1111 1111 11111 (dec) = 1111 1111 1111 11111 (dec) = 1111 1111 1111 1111

(1) + ((1) + ((1) + ((1) + (----1) = 1000 0000 0000 00001) = 1000 0000 0000 00001) = 1000 0000 0000 00001) = 1000 0000 0000 0000

The largest available 16-bit fixed-pointnumber is 32767 (0111 1111 1111 1111).The smallest available 16-bit fixed pointnumber is -32768 (1000 0000 0000 0000)

2. 32-bit fixed-point format (data formatcode = 02h).

The 32-bit fixed-point format uses foursuccessive bytes to record each datasample. Each sample consists of a sign bitS (1 implies negative) and 31 data bits QD,

with a radix point at the right of the leastsignificant bit. The format is shownschematically in Figure B-2.

32-bit fixed point format numbers are of the2 complement type [i.e., if (a) is a 32 bitfixed point number then (a) + (-a) = 232]. Forexample,

1= 0000 0000 0000 0000 0000 0000 0000 00011= 0000 0000 0000 0000 0000 0000 0000 00011= 0000 0000 0000 0000 0000 0000 0000 00011= 0000 0000 0000 0000 0000 0000 0000 0001

----1= 1111 1111 1111 1111 1111 1111 1111 11111= 1111 1111 1111 1111 1111 1111 1111 11111= 1111 1111 1111 1111 1111 1111 1111 11111= 1111 1111 1111 1111 1111 1111 1111 1111

1+(1+(1+(1+(----1)=1)=1)=1)=

1000 0000 0000 0000 0000 0000 0000 00001000 0000 0000 0000 0000 0000 0000 00001000 0000 0000 0000 0000 0000 0000 00001000 0000 0000 0000 0000 0000 0000 0000

The largest available 32-bit fixed-pointnumber is 2147483647. The smallestavailable 32-bit fixed-point number is-2147483648.

Floating point formats

The 20-bit floating-point format allowed bythis standard is based on the Digital fieldtape format standards -SEG-D (2 -bytebinary exponent data recording method demultiplexed). However, in order to be ableto express the most significant bits of a32-bit fixed point number, the data sampleis written as a scaled signed integer ratherthan a signed fraction.

The 32-bit and 64-bit floating point formatsallowed by this standard are specified asdescribed in IEEE standard for BinaryFloatingPoint Arithmetic (ANSI/IEEE Std7541985).


16/20

16 of 20

3. 20-bit floating point format (dataformat code = 03h)

The 20-bit floating-point format uses 10successive bytes to record four datasamples. The first two bytes contain theexponents for the following four samples.Each exponent is a four bit positive binaryexponent of 2 written as 2cccc where CCCC

can assume values of 0 through 15. Thefour exponents are in sample order for thefour samples starting with the first sample inbits 0-3 of the low byte (see Figure B-3).

Each data sample consists of a sign bit S (1implies negative), and a 15-bit twocomplement binary integer. The radix pointis to the right of the least significant bit withthe Isb being defined as 2. The sign and

FIG. B-3. Description of four successive data samples in 32-bit floating point format (S = signbit, C = binary exponent bit QD = data bit, HB = high byte, LB = Iow byte (least significant bits),msb = most significant bit, Isb = least significant bit). Note that the order of each group of twobytes (i.e., LB first or HB first) is dependent on the specification of the first two bytes of the FileDescriptor Block.

FIG. B-4. Description of one data sample in 32-bit floating-point format(S: sign bit, C: binary exponent bit, QD = data bit, HB= high byte, LB =low byte (least significant bits), msb = most significant bit, Isb = leastsignificant bit). Note that the order of the 4 bytes (i.e., LB first or HBfirst) is dependent on the specification of the first two bytes of the FileDescriptor Block.


17/20

17 of 20

mantissa can assume values between-32768 and 32767. Negative zero is invalidand must be converted to positive zero.

Note that in utilizing this data recordingmethod, the number of samples per trace

must be exactly divisible by 4 in order topreserve the data grouping of this method.


The 32-bit floating-point format uses foursuccessive bytes to record each datasample. Each sample consists of a sign bitS (1 implies negative), an 8-bit biasedbinary exponent of 2, and a 23-bit positivebinary fraction. The format is shownschematically in Figure B-4.

The exponent has been biased by 127,such that the value to be used indetermining the represented number is2(CCCCCCCC-127), where CCCCCCCC canassume values from 0 to 255. Thus,2(CCCCCCC-27, ranges from 2-126 to 2127 (or 1.18x 10-38 to 3.40 x 1038 . Note thatCCCCCCCC = 0 or 255 are special cases(see below).

The fraction represents a normalized (mostsignificant bit always 1) positive value.Since the most significant bit is always 1 it isnot present in the 23 bits specified in theformat (the actual fraction is composed ofthe specified 23 bits preceded by the

implied 1). The radix point is after theimplied 1 which is defined as 2. Forexample:

1 = 0 01111111 000000000000000000000001 = 0 01111111 000000000000000000000001 = 0 01111111 000000000000000000000001 = 0 01111111 00000000000000000000000

sign exponent fractionsign exponent fractionsign exponent fractionsign exponent fraction

= + 2= + 2= + 2= + 2(127(127(127(127----127)127)127)127) {00000000000000000000000}{00000000000000000000000}{00000000000000000000000}{00000000000000000000000}

= (+1) x 2= (+1) x 2= (+1) x 2= (+1) x 20000

----2= 1 10000000 000000000000000000000002= 1 10000000 000000000000000000000002= 1 10000000 000000000000000000000002= 1 10000000 00000000000000000000000sign exponentsign exponentsign exponentsign exponent fractionfractionfractionfraction

= + 2= + 2= + 2= + 2(128(128(128(128----127)127)127)127) {00000000000000000000000}{00000000000000000000000}{00000000000000000000000}{00000000000000000000000}

= (= (= (= (----1) x 21) x 21) x 21) x 2----1111

The sign and fraction (with implied digit) ofthe above format can represent values from- 2 + 2-23 to 2 2-23. Special cases:

FIG. B-5. Description of one data sample in 64 bit floating point format(S = sign bit, C = binary exponent bit, QD = data bit, HB = high byte, LB= low byte (least significant bits) msb = most significant bit, Isb = leastsignificant bit). Note that the order of the 8 bytes (i.e., LB first or Iff3first) is dependent on the specification of the first two bytes of the FileDescriptor Block.


18/20

18 of 20

Exponentbits (C)

Mantissabits (QD)

Meaning

All 0 All 0 Floatingpoint 0

All 0 Nonzero Underflow

All 1 All 0 Infinity

All 1 Nonzero Not anumber


The 64-bit floating-point format uses 8successive bytes to record each datasample. Each sample consists of a sign bitS (1 implies negative), an 11-bit biased

binary exponent of 2, and a 52-bit positivebinary fraction. The format is shownschematically in Figure B-5.

The exponent has been biased by 1023,such that the value to be used indetermining the represented number is2(ccccccccccc-1023), where CCCCCCCCCCC canassume values from 0 to 2047. Thus,2(ccccccccccc-1023) ranges from 2-1022 to 21023 (or2.23 x 10-308 to 1.80 x 10-308 ). Note thatCCCCCCCCCCC = 0 or 1023 are special

cases (see below).The fraction represents a normalized (mostsignificant bit always 1) positive value.Since the most significant bit is always 1 it isnot present in the 52 bits specified in theformat (the actual fraction is composed ofthe 52 specified bits preceded by theimplied 1). The radix point is after theimplied 1 which is defined as 20. The signand fraction (with implied digit) of the aboveformat can represent values from 2 + 252to 2-252. The special cases listed under the

32-bit floating-point math also apply in thiscase.


19/20

19 of 20

APPENDIX C

EXAMPLES OF STRING FORMATSUBBLOCKS

In the examples shown in Figures C- 1 andC-2, it is assumed that the String Terminator

has been defined in bytes 8 - 10 of the FileDescriptor Block as the NULL character(00), and that the Line Terminator has beendefined in bytes 11 -13 as line feed (0A)followed by carriage return (0D).

FIG. C-1. Example of a string sub-block that may be part of a File Descriptor Block.The two bytes immediately preceding a keyword give the offset to the next string.The two bytes are indicated by the symbol I_I_I, but the offset itself is shown in smallbracketed decimal characters in this example.


20/20

20 of 20

FIG. C 2, Example of a string sub-block that may be part of a Trace Descriptor Block. Thetwo bytes immediately preceding a keyword give the offset to the next string. The two bytesare indicated by the symbol I_I_I, but the offset itself is shown in small bracketed decimalcharacters in this example.

Documents

Seg 2SEG standards