Removed Other encoding from GAME_IDENTIFIER and performed editing pass over descriptions and introduction summary

1 files changed, 62 insertions, 41 deletions

diff --git a/docs/latest/draft-tasd-spec.txt b/docs/latest/draft-tasd-spec.txt
index ef2f59e..03d279a 100644
--- a/docs/latest/draft-tasd-spec.txt
+++ b/docs/latest/draft-tasd-spec.txt
@@ -7,7 +7,7 @@ Independent TAS Console Replay Research Group                    V. Grey
                                                                  Bigbass
                                                                         
                                                                  rasteri
-                                                          8 October 2023
+                                                         13 October 2023
 
 
                 TASD File Format Specification Version 1
@@ -143,14 +143,15 @@ Table of Contents
    parsing the file, software can skip any packets whose key is unknown
    or unsupported.
 
-   Keys can be used multiple times or completely omitted as needed.
-   This reusability eliminates the need of a predefined delimiter to
-   separate pieces of data such as a list of TAS authors.
+   Packets of a given type can be used multiple times or completely
+   omitted as needed.  This reusability eliminates the need of a
+   predefined delimiter to separate pieces of data such as a list of TAS
+   authors.
 
    While files generated by emulator dump scripts should provide as much
-   information as possible, because keys are optional, the file can be
-   expanded later with any additional data as desired.  No intermediary
-   file format is necessary.
+   information as possible, because packets are optional, the file can
+   be expanded later with any additional data as desired.  No
+   intermediary file format is necessary.
 
 1.1.  Overview and Preliminaries
 
@@ -282,8 +283,8 @@ Table of Contents
 
    *  Ability to easily generate using lua scripting in emulators
 
-   Consideration was also given to how usable the format would be for
-   the software that interacts with replay devices (examples: methods of
+   Consideration is also given to how usable the format would be for the
+   software that interacts with replay devices (examples: methods of
    ingestion/parsing, ease of ingestion/parsing in various languages).
 
 1.2.1.  Problems With Existing Formats
@@ -294,16 +295,16 @@ Table of Contents
    controllers worth of sequential data and a format commonly used for
    SNES console verifications (r16m) only encodes up to 8 standard
    controllers worth of sequential data.  There is no built in way to
-   store *RESET* press timing information or indicate additional
-   settings/information.  Non-standard controllers are also not
-   supported in commonly used formats.
+   store *RESET* timing information or indicate additional settings/
+   information.  Non-standard controllers are also not supported in
+   commonly used formats.
 
    For consoles not as popular as the NES and SNES, controller input
    formats would frequently be written in a way that is meant only to
-   work and not in a "standard" way.  While that process works, it's
-   less than ideal for redistribution of console replays so that others
-   (especially with differing TAS replay devices) can also verify the
-   same TAS.
+   work and not in a "standard" way.  While that process works for a
+   specific device, it's less than ideal for redistribution of console
+   replays so that others (especially with differing TAS replay devices)
+   can also verify the same TAS.
 
 2.  Structure
 
@@ -799,9 +800,9 @@ Table of Contents
    *Type*
       Function of the person who is being attributed.  *Author* is meant
       for a TAS movie author.  *Verifier* is meant for a person who
-      initially console verified the the TAS movie using the *TASD
-      file*.  *TASD File Creator* is meant for the person who initially
-      dumped the TAS movie controller inputs into the *TASD* file.
+      console verified the TAS movie(s) contained in the *TASD* file.
+      *TASD File Creator* is meant for the person who initially created
+      the *TASD* file, such as when dumping inputs from a TAS movie.
       *TASD File Editor* is meant for a person who edited the *TASD*
       file.
 
@@ -824,7 +825,7 @@ Table of Contents
          Category (String)                       [PLEN octets]
 
    *Category*
-      Name of the TAS movie run category (example: "Any %", "100%", "No
+      Name of the TAS movie run category (example: "any%", "100%", "No
       Warps").
 
    *PLEN*
@@ -843,7 +844,8 @@ Table of Contents
 
    *Name*
       Name of the emulator used to play the TAS movie while dumping
-      controller inputs (example: "FCEUX", "Bizhawk").
+      controller inputs (example: "FCEUX", "Bizhawk").  The emulator's
+      version or core name SHOULD NOT be included.
 
    *PLEN*
       Length of the packet payload.
@@ -969,7 +971,7 @@ Table of Contents
          Link (String)                           [PLEN octets]
 
    *Link*
-      URL that points to the TAS movie or submission (example:
+      URL that points to the TAS movie file (example:
       "https://tasvideos.org/4567M").
 
    *PLEN*
@@ -987,11 +989,13 @@ Table of Contents
          Frames (Signed Integer)                 [2 octets]
 
    *Frames*
-      Number of blank frames (inputs where no buttons are being pressed)
-      needed at the beginning of a TAS console replay of the TAS movie.
-      If *Frames* is a negative value, the value of *Frames* amount of
-      inputs of the TAS console replay of the TAS movie should be
-      removed.
+      Number of blank frames (of input where no buttons are being
+      pressed) needed at the beginning of a TAS replay.  If *Frames* is
+      a negative value, the value of *Frames* indicates the number of
+      frames that should be skipped from the TAS input data.  A negative
+      value is not applicable if there is no way to determine how much
+      input data should be skipped (e.g.  NES with INPUT_CHUNKs where
+      each input represents a single latch).
 
 4.3.1.17.  VERIFIED Packet
 
@@ -1082,7 +1086,7 @@ Table of Contents
 
    GAME_IDENTIFIER packets MUST be in the following format:
 
-           0          1          2         3...       3+NLEN...
+           0            1            2         3...        3+NLEN...
       +----------+--------------+----------+==========+================+
       | Type (A) | Encoding (A) | NLEN (N) | Name (S) | Identifier (A) |
       +----------+--------------+----------+==========+================+
@@ -1105,28 +1109,30 @@ Table of Contents
          [FF] - Other
       Encoding (Binary Data):                 [1 octet]
          [01] - Raw Binary
-         [02] - Case Insensitive Base 16 (Hex) - RFC 4648
-         [03] - Case Insensitive Base 32 - RFC 4648
-         [04] - Base 64 - RFC 4648
-         [FF] - Other
+         [02] - Base 16 (Case Insensitive)
+         [03] - Base 32 (Case Insensitive)
+         [04] - Base 64
       NLEN (Unsigned Integer)                 [1 octet]
       Name (String)                           [NLEN octets]
       Identifier (Binary Data)                [PLEN - 2 octets]
 
    *Type*
-      Hash, checksum, or identifier algorithm *Identifier* is using.
+      Hash, checksum, or identifier algorithm used to create the
+      *Identifier*.
 
    *Encoding*
-      Describes the data encoding of *Identifier*.
+      Describes the data encoding of *Identifier*. Raw binary indicates
+      no encoding is used.  Base16/32/64 all use the standard RFC 4648
+      encodings, without extensions.  Base 16 and Base 32 are case-
+      insensitive.
 
    *NLEN*
       Length of *Name*
 
    *Name*
-      Name of *Type* meant if the hash, checksum, or identifier
-      algorithm *Identifier* is using is not included in *Type*.  If
-      *Type* is [FF], *Name* SHOULD NOT be empty (0 octet length
-      string).
+      Name of the hash, checksum, or identifier algorithm used to create
+      the *Identifier*. If *Type* is not [FF], *Name* SHOULD be empty (0
+      octet length binary data).
 
    *Identifier*
       Game hash, checksum, or identifier data.
@@ -1406,7 +1412,7 @@ Table of Contents
    *Inputs*
       Controller input data for controller on *Port*. Input values are
       usually in native format (usually active-low).  Input formats for
-      specific controller types are described in (Section 5).
+      specific controller types are described in Section 5.
 
    *PLEN*
       Length of the packet payload.
@@ -1419,6 +1425,12 @@ Table of Contents
    are earlier in the *TASD* file and later inputs in the TAS movie
    console replay are later in the *TASD* file.
 
+   The input data contained in *Inputs* is divided up based on the
+   PORT_CONTROLLER type corresponding to the *Port* number.  Refer to
+   Section 5 for each available type and the number of bytes used for
+   each instance of controller input.  Keep in mind that the
+   PORT_CONTROLLER type can be changed using TRANSITION packets.
+
 4.3.5.2.  INPUT_MOMENT Packet
 
    INPUT_MOMENT packets MUST be in the following format:
@@ -1454,11 +1466,17 @@ Table of Contents
    *Inputs*
       Controller input data for controller on *Port*. Input values are
       usually in native format (usually active-low).  Input formats for
-      specific controller types are described in (Section 5).
+      specific controller types are described in Section 5.
 
    *PLEN*
       Length of the packet payload.
 
+   The input data contained in *Inputs* is divided up based on the
+   PORT_CONTROLLER type corresponding to the *Port* number.  Refer to
+   Section 5 for each available type and the number of bytes used for
+   each instance of controller input.  Keep in mind that the
+   PORT_CONTROLLER type can be changed using TRANSITION packets.
+
 4.3.5.3.  TRANSITION Packet
 
    TRANSITION packets MUST be in the following format:
@@ -1531,6 +1549,9 @@ Table of Contents
    *Count*
       Number of Lag Frames in a row starting from *Movie Frame*.
 
+   Emulators typically consider a "lag frame" to be any frame in which
+   the emulator believes the game does not poll/read controller inputs.
+
 4.3.5.5.  MOVIE_TRANSITION
 
    MOVIE_TRANSITION packets MUST be in the following format:
@@ -1614,7 +1635,7 @@ Table of Contents
 
    *Unspecified Data*
       Arbitrary data.  Can be used for any data.  Because this is
-      unspecified data, there there is no guarantee any software to
+      unspecified data, there is no guarantee any software used to
       control a TAS replay device will support data in this packet type.
 
    *PLEN*