SU700 File Layout And Sample Data

SU700 media separates song/sample references, sample audio, and song settings into three file classes. These files do not use the A-series FSFSDEV3SPLX object headers or the SMPL/SBNK/SBAC/PROG layouts. Filesystem support and import capabilities are described separately under SU700 Profile.

SU700 Song And Track Records describes SSQ parameter and event encodings; SU700 Effects Records describes its effect scenes and type-dependent parameters. All offsets refer to stored files or explicitly named record bodies, not device memory. Normal editing ranges are distinguished from values accepted during loading.

Placement And Names

File	FAT12 floppy	SFS hard-disk volume	Contents
`SONGCONT.DAT`	Root	Volume root	Twenty song slots and their sample basenames.
`*.SSP`	Root	`SUSP` directory	Sample metadata and native audio blocks.
`*.SSQ`	Root	`SUSQ` directory	Song setup, track parameters, scenes, effects and events.

The control table supplies basenames; filenames are not derived from slot numbers. FAT 8.3 names omit trailing stem-padding spaces when displayed, while SFS filenames retain the stored eight-byte basename before the extension. For example, basename BEAT01 corresponds to FAT name BEAT01.SSQ and SFS name BEAT01 .SSQ. Preserve the control bytes rather than applying one whitespace-normalization rule to both containers.

The divided-floppy packaging and continuation rules are not fully specified here. A disk with recognizable control data but missing referenced files does not define a complete transferable song set.

SONGCONT.DAT

The file is exactly 7400 (0x1ce8) bytes: twenty records of 370 (0x172) bytes. For zero-based song slot s, the record begins at s * 0x172. Offsets below are relative to that record:

Offset	Size	Meaning
`0x000`	9	Song basename storage: eight name bytes and a terminator.
`0x009 + n * 9`, `n=0..39`	9 each	Forty sample basename slots.
`0x171`	1	Song state. `0` is inactive; `1` is active.

A sample slot whose first byte is zero is empty. The rest of that slot need not be zero. An inactive song record may retain a default song name. The state byte is not a sample count and can remain set after content changes; other state values have no general meaning specified here. Neither a nonempty name nor a present control table proves that every referenced payload was saved successfully. Resolve active references against the actual directory contents.

Track Identities

Sample slot n corresponds to track identity n + 3 throughout the control table, the forty SSQ track records and the forty sample-scene snapshots. They are grouped by track family, not by the ten pads visible in one bank:

Sample slots	Track identities	Family	Default suffixes
0..7	3..10	LOOP	LP01..LP08
8..23	11..26	COMPOSED LOOP	CL01..CL16
24..39	27..42	FREE	FR01..FR16

For zero-based bank b = 0..3, LOOP pads 1/2 have identities 3 + 2*b and 4 + 2*b; COMPOSED LOOP pads 1..4 have identities 11 + 4*b through 14 + 4*b; FREE pads 1..4 have identities 27 + 4*b through 30 + 4*b. AUDIO IN is identity 2 and MASTER is identity 1 in every bank. They have effects/control records but no additional SONGCONT sample slots. Identity 0 has no established visible sample-track meaning.

Default sample basenames combine S, the two-digit one-based song number, the family suffix, one space and a NUL: for example S01LP01 plus NUL. Defaults are not lookup keys when the table contains another name.

Name And State Behavior

The ordinary name-copy operation copies eight bytes and appends NUL; it does not stop at an embedded NUL or add space padding. Name comparison uses exactly eight bytes, without case folding or trimming. Filename construction also has NUL-terminated consumers, so arbitrary unterminated fields have no generally safe interpretation. Preserve all nine stored bytes while bounding inspection to the field; do not read through the next slot searching for a terminator.

Reset uses default song names SONG01 through SONG20, clears only the first byte of each sample slot and sets state zero. Refresh sets state one when sample references or qualifying sequence content exist, but does not clear an existing state when they disappear. Time-only sequence streams do not by themselves mark a song present. State therefore cannot be regenerated from the count of sample references.

Song lookup, switching and save gating use nonzero state, while initial song selection and some replacement/removal operations require exactly one. Preserve unusual values rather than converting every nonzero value to one. Song rename checks reject eight spaces and exact eight-byte duplicates among all other song records, including inactive records. This is not a complete character-set specification. An inactive rename changes its stored name without requiring an SSQ rename; an active rename also changes the referenced SSQ name.

Cross-File Loading And Completeness

The control file can be saved before the SSQ/SSP files it names. Short transfers are not consistently rejected by device file-I/O paths. Neither an existing control table nor declared payload lengths constitute a transaction-completion marker; check actual lengths and all active references independently.

Bulk song loading restores SSQ first and then loads the referenced SSP files. SSP loading replaces channel/frame/rate/width/window data and active allocation state before a new internal song snapshot is saved. Earlier LOOP setup can use the saved SSQ allocation fields before replacement. Missing samples and alternate replacement paths are not fully specified: this ordering does not authorize zeroing allocation fields or treating contradictory metadata as harmless.

SSP: Sample Storage

Native samples use big-endian FORM/AIFF chunk framing. The FORM length at file offset 4, plus eight bytes, gives the file length; AIFF is at offset 8. Each following chunk has a four-byte tag and a big-endian 32-bit body size. Advance by 8 + body_size + (body_size & 1) bytes. Chunk sizes must remain within the enclosing FORM.

The native layout contains COMM, MARK, NAME, INST, and APPL chunks; stereo stores two audio-bearing APPL chunks. Walk chunk lengths rather than assuming fixed absolute positions.

COMM describes channel count, frame count, sample width and the extended sample-rate value. The native audio layouts described here are mono/stereo with 8- or 16-bit samples.
MARK marker ID 1 supplies the start and ID 2 the end. Marker names do not determine their roles.
NAME carries the sample name. The sample-name load operation retains up to eight bytes, padding a shorter name with spaces.
INST remains part of the saved file, but the native sample-load path does not restore it as independent instrument settings.
Native APPL blocks carry the audio instead of ordinary AIFF SSND storage.

Native SSP loading interprets MARK; ordinary AIFF/SSND import follows a different path that does not restore those markers. Completion requires COMM and one native audio block for mono or two for stereo; MARK, NAME and INST are not required by that completion check. It counts stereo APPL blocks rather than proving that one of each signature was supplied. A complete stereo file still needs both distinct channel payloads; a block count alone is insufficient.

Common Sample Metadata

The COMM body is 18 bytes. Its offsets are:

Offset	Type/size	Meaning
0	u16be	Channel count, 1 or 2.
2	u32be	Physical frame count; the sample loader requires more than four.
6	u16be	Sample width; the native representations described here use 8 or 16 bits.
8	10 bytes	AIFF extended sample rate: sign/exponent, then a 64-bit mantissa.

The integer rate used by the track loader comes from the first 16 mantissa bits shifted right by 0x400e - exponent; the remaining 48 mantissa bits are discarded. Negative rates and exponents above 0x400e are rejected. For example, mantissa prefix 0xac44 gives 44100 at exponent 0x400e, but 11025 at 0x400c. Preserve the complete extended value; the prefix alone is not a sample rate. The width reader uses the low byte and rejects zero, which does not establish native support for every other width.

MARK starts with a u16be count. Each marker contains a u16be ID, u32be frame position and Pascal name (one length byte followed by that many name bytes), padded so the name field occupies an even number of bytes. Repeated recognized IDs replace earlier positions; other IDs do not set the selected window. Chunk and record boundaries still need checking independently of that behavior.

Selected Window

Ordinary sample import initially uses start zero and end frames - 5. Native loading starts with zero window positions and can replace them from MARK. Both paths have a subsequent adjustment:

Resets a start above 99,999,999 to zero.
If end exceeds frames - 1, stores frames - 5 as the replacement end.
Resets start if it exceeds the comparison end. After step 2 that comparison still uses frames - 1, not the replacement end.

Thus this adjustment alone does not guarantee an ordered start/end pair. End values through frames - 1 are unchanged. Window-length calculations use end + 1 - start, but precise audible endpoints and native fetch margins remain unspecified; the adjustment is not an offline repair algorithm.

Native Audio Blocks

For an APPL chunk header beginning at file offset C:

Offset	Type/size	Meaning
`C + 0`	4 bytes	`APPL`.
`C + 4`	u32be	Chunk body size.
`C + 8`	4 bytes	`SU7M` for mono/left, `SU7R` for right.
`C + 12`	u32be	Declared per-channel audio byte count `N`, rounded to four bytes.
`C + 16`	u16be	Leading alignment byte count `P`.
`C + 18`	`P` bytes	Leading alignment bytes.
`C + 18 + P`	`N` bytes	Native audio, including the final four-byte-group padding.
Following audio	Remaining chunk body	Trailing sector alignment.

For the native 8-/16-bit layout, N = round_up(COMM.frames * bytes_per_sample, 4) for each channel, not for the interleaved stereo pair. Physical audio allocation rounds N up to 512 bytes. The native saved layout uses a total file length of channels * (512 + round_up(N, 512)). This is a native-save layout, not a rule for arbitrary AIFF files. Leading alignment is zero-filled; trailing alignment must not be assumed zero or substituted for missing audio.

Samples are signed. Convert consecutive native bytes A B C D to ordinary AIFF audio order as follows:

Sample width	Converted bytes	Operation
8 bits	`D C B A`	Reverse four one-byte samples.
16 bits	`C D A B`	Exchange two big-endian 16-bit samples.

Reorder the complete final padded group before restricting output to the declared frame count. Stereo conversion applies the same rule independently to the two channels, then interleaves their samples. An A-series 16-bit byte-swap decoder is not interchangeable with this ordering.

The physical frame count and selected playback window are distinct. End-marker handling and native fetch margins are not fully specified; there is no general rule to remove five frames from every file. Preserve explicit markers and padding when copying samples unchanged.

In the fixed native-save sequence, the first APPL header is at offset 126, its leading pad is 368 bytes, and audio starts at 512. Let S = round_up(N, 512). The right APPL header starts at 512 + S, has 494 leading pad bytes, and its audio starts at 1024 + S. Each APPL body size is 10 + P + S. These are native-save positions; chunk walking remains necessary for other layouts. Logical count, physical block extent and COMM frame count are separate declarations and must be checked for consistency; permissive loading does not prove a truncated or contradictory file complete.

Automatic sample-window analysis is a separate operation from interpreting stored markers. It searches mono/left amplitudes, using inclusive quiet magnitudes 384 for 16-bit and 1 for 8-bit samples, with one-frame margins. The forward search retains one sample before its first over-threshold match; the backward search retains one after its match. No match leaves the boundary unchanged, so all-quiet input does not become an empty sample. It is not a stereo-wide silence trim or a slice zero-crossing search. Its full boundary behavior does not define an offline repair rule; retain saved windows unless explicitly performing a separately specified analysis operation.

SSQ: Song Storage

SSQ uses big-endian fields but is not a Standard MIDI File despite its MThd tag. The framed song layout is:

Record	Framing and contents
`FLhd`	Tag followed by a u32be total file length, including this header.
Optional extension	Six bytes between `FLhd` and `MThd`; its complete meaning is unspecified.
`MThd`	Tag followed by a u32be event-track count, not a MIDI header-body length.
`Comn`	Tag, u32be body size `46`, then common song settings.
Forty `Trkp` records	Each has a tag, u32be body size `64`, and track parameters. This count is independent of the event-track count.
`Tgsn`	Tag and eight sample-scene records; there is no enclosing size word.
`Efsn`	Tag, u32be body size, then eight conditionally populated effect-scene records.
Event tracks	The declared number of `Tr` tags, each followed by a two-byte descriptor and its conditional event stream.

Trkp stores setup and sample properties separately from the SSP audio. Its body offsets 10..18 contain nine bytes of sample-name storage. The normal name setter copies eight bytes; the ninth byte is not a reliable independent identity. Do not require byte-for-byte equality of all nine bytes across Trkp, SONGCONT.DAT, and SSP NAME.

A Tgsn scene beginning with ff ff occupies only those two bytes. Otherwise the scene occupies 882 bytes: forty 22-byte track snapshots followed by MASTER and AUDIO IN mute bytes. The first two bytes belong to snapshot zero; they are not a separate header. An Efsn record has a one-byte state and, when populated, 770 payload bytes. State 1 selects the payload; scene zero also carries it when the extension selector is below 128. That selector is the last byte of the six-byte extension, or 255 when the extension is absent. Preserve the other extension bytes; this framing dependency does not establish their full semantic meaning.

An event-track descriptor with high byte 4 has no following event words. Other tracks use four-byte event words, not MIDI variable-length deltas or MTrk chunks. A word satisfying (word & 0xff00ffff) == 0x7f00ffff terminates the stream. Remaining event value subfields, scene domains and effect-state details are not exhaustively specified here; structural framing alone does not establish that an event can be edited or converted to MIDI without loss. The established portions are specified in the SU700 Song And Track Records and SU700 Effects Records.

The native extended header emits BE32 0x16 followed by BE16 100; these values do not establish a version or checksum field. A bare MThd layout is also recognized by the device loader, with the absent-extension selector. This does not change any application's advertised input capabilities.

Native song saving can round the final transfer to four bytes and include the resulting tail in the FLhd length. Tail bytes need not be zero. Event parsing ends after the declared track count; do not interpret alignment as another event or invent a checksum field. Preserve any tail on unrelated edits.

Preservation Boundaries

Preserve unrecognized chunk bodies, unused scene state, raw name suffixes, alignment bytes, and unspecified parameter fields on unrelated operations. In particular, sample-window endpoints, some common/effect fields, divided-media packaging, and complete event-value semantics remain incomplete. Those gaps prevent a general lossless semantic rewrite or fresh-device-authoring contract; they do not prevent byte-preserving file copies with complete references.