1. Should our academic community be more formal in honoring true SEGY? David Okaya Univ. Southern California IEEE OBS gather read in as IBM (A) Are we overly lax with our usage of the SEGY standard? There are many sets of data using different flavors of SEGY. (B) True SEGY: big-endian IBM float*4. We acknowledge that I*2, I*4, and IEEE are permissible within the standard. (C)Endian-ness is explicitly defined in Rev-1 as big. It's common to encounter little-endian and IEEE. Endian-ness needs to be conveyed if IEEE is used. (IBM is always used in big-).

2. (D) Important academic seismology applications are not true SEGY. -Antelope "db2segy" is local IEEE and with incomplete headers. -GMT "pssegy" is big-endian IEEE. -PASSCAL software is trace SEGY (Int*4), not file SEGY. File suffix is now.rsy not.sgy. Many of PASSCAL software segy2xxx or xxx2segy is for trace SEGY. (E) Do we want action on these? Or establish community agreement to: Use IBM-big more often as default combination. Avoid "anything is OK" approach. Define a 'best practices' for file exchange - what small amount of external metadata (readme) should go with files? Some file/trace headers are sacrosanct; others can be violated (trace length). Collate and make available SEGY utility software tools written within community. Keep up with SEG regarding future plans for SEGY. (perhaps some of this is moot based on future SEG plans). Too late to rename PASSCAL segy software? Still being used?

3. Q: If we are increasing the amount of data that we collect in continuous mode or in continuous block mode, is there a point when these data should be stored in miniseed in the DMC? Similar to a portable broadband experiment? Extraction tools would be needed to produce SEGY gather files.