add AUTH48 v2 changes

attachments.md

@@ -1,11 +1,11 @@
 # Attachments
 
-Matroska supports storage of related files and data in the `Attachments Element`
-(a `Top-Level Element`). `Attachment Elements` can be used to store related cover art,
+Matroska supports storage of related files and data in the `Attachments` element
+(a `Top-Level Element`). `Attachments` elements can be used to store related cover art,
 font files, transcripts, reports, error recovery files, pictures, text-based annotations,
 copies of specifications, or other ancillary files related to the `Segment`.
 
-`Matroska Readers` **MUST NOT** execute files stored as `Attachment Elements`.
+`Matroska Readers` **MUST NOT** execute files stored as `Attachments` elements.
 
 ## Cover Art
 
@@ -24,13 +24,13 @@ The dimension of the `normal cover` **SHOULD** be 600 pixels on the smallest sid
 the `small cover` **SHOULD** be 120 pixels on the smallest side (e.g., 192x120 or 120x160).
 
 Versions of cover art can be differentiated by the filename, which is stored in the
-`FileName Element`. The default filename of the `normal cover` in square or portrait mode
-is `cover.(jpg|png)`. When stored, the `normal cover` **SHOULD** be the first Attachment in
+`FileName` element. The default filename of the `normal cover` in square or portrait mode
+is `cover.(jpg|png)`. When stored, the `normal cover` **SHOULD** be the first `Attachments` element in
 storage order. The `small cover` **SHOULD** be prefixed with "small_", such as
 `small_cover.(jpg|png)`. The landscape variant **SHOULD** be suffixed with "\_land",
 such as `cover_land.(jpg|png)`. The filenames are case-sensitive.
 
-The following table provides examples of file names for cover art in Attachments.
+The following table provides examples of file names for cover art in `Attachments`.
 
 | File Name            | Image Orientation  | Pixel Length of Smallest Side |
 |----------------------|--------------------|-------------------------------|
@@ -49,21 +49,21 @@ consistent in various environments where the needed fonts might not be available
 Depending on the font format in question, each font file can contain multiple font variants.
 Each font variant has a name that will be referred to as Font Name from now on.
 This Font Name can be different from the Attachment's `FileName`, even when disregarding the extension.
-In order to select a font for display, a Matroska Player **SHOULD** consider both the Font Name
-and the base name of the Attachment's FileName, preferring the former when there are multiple matches.
+In order to select a font for display, a `Matroska Player` **SHOULD** consider both the Font Name
+and the base name of the Attachment's `FileName`, preferring the former when there are multiple matches.
 
 Subtitle codecs, such as SubStation Alpha (SSA) and Advanced SubStation Alpha (ASS), usually refer to a font by its Font Name, not
 by its filename.
-If none of the Attachments are a match for the Font Name, the Matroska Player **SHOULD**
+If none of the Attachments are a match for the Font Name, the `Matroska Player` **SHOULD**
 attempt to find a system font whose Font Name matches the one used in the subtitle track.
 
-Since loading fonts temporarily can take a while, a Matroska Player usually
+Since loading fonts temporarily can take a while, a `Matroska Player` usually
 loads or installs all the fonts found in attachments so they are ready to be used during playback.
 Failure to use the font attachment might result in incorrect rendering of the subtitles.
 
 If a selected subtitle track has some `AttachmentLink` elements, the player **MAY** restrict its font rendering to use only these fonts.
 
-A Matroska Player **SHOULD** handle the official font media types from [@!RFC8081] when the system can handle the type:
+A `Matroska Player` **SHOULD** handle the official font media types from [@!RFC8081] when the system can handle the type:
 
 * font/sfnt: Generic SFNT Font Type
 
@@ -78,7 +78,7 @@ A Matroska Player **SHOULD** handle the official font media types from [@!RFC808
 * font/woff2: WOFF 2.0
 
 Fonts in Matroska existed long before [@!RFC8081]. A few unofficial media types for fonts were used in existing files.
-Therefore, it is **RECOMMENDED** for a Matroska Player to support the following legacy media types for font attachments:
+Therefore, it is **RECOMMENDED** for a `Matroska Player` to support the following legacy media types for font attachments:
 
 * application/x-truetype-font: TrueType fonts, equivalent to `font/ttf` and sometimes `font/otf`
 
@@ -92,7 +92,7 @@ Therefore, it is **RECOMMENDED** for a Matroska Player to support the following
 
 
 There may also be some font attachments with the `application/octet-stream` media type.
-In that case, the Matroska Player **MAY** try to guess the font type by checking the file extension of the `AttachedFile\FileName` string.
+In that case, the `Matroska Player` **MAY** try to guess the font type by checking the file extension of the `AttachedFile\FileName` string.
 Common file extensions for fonts are:
 
 * `.ttf` for TrueType fonts, equivalent to `font/ttf`
@@ -103,7 +103,7 @@ Common file extensions for fonts are:
 
 The file extension check **MUST** be case-insensitive.
 
-Matroska Writers **SHOULD** use a valid font media type from [@!RFC8081] in the `AttachedFile\FileMediaType` of the font attachment.
+`Matroska Writers` **SHOULD** use a valid font media type from [@!RFC8081] in the `AttachedFile\FileMediaType` of the font attachment.
 They **MAY** use the media types found in older files when compatibility with older players is necessary.
 
 

block_additional_mappings/smpte-st12-1-timecode.md

@@ -2,11 +2,11 @@
 
 ### Timecode Description
 
-SMPTE ST 12-1 timecode values can be stored in the `BlockMore Element` to associate
+SMPTE ST 12-1 timecode values can be stored in the `BlockMore` element to associate
 the content of a Matroska Block with a particular timecode value.
 If the Block uses Lacing, the timecode value is associated with the first frame of the Lace.
 
-The Block Additional Mapping contains a full binary representation of a 64 bit SMPTE timecode
+The `Block Additional Mapping` contains a full binary representation of a 64 bit SMPTE timecode
 value stored in big-endian format and expressed exactly as defined in Section 8 and 9
 of SMPTE 12M [@!ST12]. For convenience, here are the bit assignments for a
 SMPTE ST 12-1 binary representation as described in [@?RFC5484, section 6.2]:
@@ -45,12 +45,12 @@ For example, a timecode value of "07:32:54;18" can be expressed as a 64 bit SMPT
 
 ### BlockAddIDType
 
-The BlockAddIDType value reserved for timecode is "121".
+The `BlockAddIDType` value reserved for timecode is "121".
 
 ### BlockAddIDName
 
-The BlockAddIDName value reserved for timecode is "SMPTE ST 12-1 timecode".
+The `BlockAddIDName` value reserved for timecode is "SMPTE ST 12-1 timecode".
 
 ### BlockAddIDExtraData
 
-BlockAddIDExtraData is unused within this block additional mapping.
+`BlockAddIDExtraData` is unused within this block additional mapping.

block_additional_mappings_intro.md

@@ -2,61 +2,61 @@
 
 Extra data or metadata can be added to each `Block` using `BlockAdditional` data.
 Each `BlockAdditional` contains a `BlockAddID` that identifies the kind of data it contains.
-When the `BlockAddID` is set to "1" the contents of the `BlockAdditional Element`
+When the `BlockAddID` is set to "1" the contents of the `BlockAdditional` element
 are define by the Codec Mappings defines; see (#codec-blockadditions).
 When the `BlockAddID` is set a value greater than "1", then the contents of the
-`BlockAdditional Element` are defined by the `BlockAdditionalMapping Element`, within
-the associated `Track Element`, where the `BlockAddID Element` of `BlockAdditional Element`
-equals the `BlockAddIDValue` of the associated Track's `BlockAdditionalMapping Element`.
-That `BlockAdditionalMapping Element` identifies a particular Block Additional Mapping by the `BlockAddIDType`.
+`BlockAdditional` element are defined by the `BlockAdditionalMapping` element, within
+the associated `Track` element, where the `BlockAddID` element of `BlockAdditional` element
+equals the `BlockAddIDValue` of the associated `Track`'s `BlockAdditionalMapping` element.
+That `BlockAdditionalMapping` element identifies a particular `Block Additional Mapping` by the `BlockAddIDType`.
 
-The following XML depicts a use of a Block Additional Mapping to associate a timecode value with a `Block`:
+The following XML depicts a use of a `Block Additional Mapping` to associate a timecode value with a `Block`:
 
 ```xml
-<Segment>
-  <!--Mandatory elements ommitted for readability-->
-  <Tracks>
-    <TrackEntry>
-      <TrackNumber>1</TrackNumber>
-      <TrackUID>568001708</TrackUID>
-      <TrackType>1</TrackType>
-      <BlockAdditionalMapping>
-        <BlockAddIDValue>2</BlockAddIDValue><!--arbitrary value
-          used in BlockAddID-->
-        <BlockAddIDName>timecode</BlockAddIDName>
-        <BlockAddIDType>12</BlockAddIDType>
-      </BlockAdditionalMapping>
-      <CodecID>V_FFV1</CodecID>
-      <Video>
-        <PixelWidth>1920</PixelWidth>
-        <PixelHeight>1080</PixelHeight>
-      </Video>
-    </TrackEntry>
-  </Tracks>
-  <Cluster>
-    <Timestamp>3000</Timestamp>
-    <BlockGroup>
-      <Block>{binary video frame}</Block>
-      <BlockAdditions>
-        <BlockMore>
-          <BlockAddID>2</BlockAddID><!--arbitrary value from
-            BlockAdditionalMapping-->
-          <BlockAdditional>01:00:00:00</BlockAdditional>
-        </BlockMore>
-      </BlockAdditions>
-    </BlockGroup>
-  </Cluster>
-</Segment>
+&lt;Segment&gt;
+  &lt;!--Mandatory elements ommitted for readability--&gt;
+  &lt;Tracks&gt;
+    &lt;TrackEntry&gt;
+      &lt;TrackNumber&gt;1&lt;/TrackNumber&gt;
+      &lt;TrackUID&gt;568001708&lt;/TrackUID&gt;
+      &lt;TrackType&gt;1&lt;/TrackType&gt;
+      &lt;BlockAdditionalMapping&gt;
+        &lt;BlockAddIDValue&gt;2&lt;/BlockAddIDValue&gt;&lt;!--arbitrary value
+          used in BlockAddID--&gt;
+        &lt;BlockAddIDName&gt;timecode&lt;/BlockAddIDName&gt;
+        &lt;BlockAddIDType&gt;12&lt;/BlockAddIDType&gt;
+      &lt;/BlockAdditionalMapping&gt;
+      &lt;CodecID&gt;V_FFV1&lt;/CodecID&gt;
+      &lt;Video&gt;
+        &lt;PixelWidth&gt;1920&lt;/PixelWidth&gt;
+        &lt;PixelHeight&gt;1080&lt;/PixelHeight&gt;
+      &lt;/Video&gt;
+    &lt;/TrackEntry&gt;
+  &lt;/Tracks&gt;
+  &lt;Cluster&gt;
+    &lt;Timestamp&gt;3000&lt;/Timestamp&gt;
+    &lt;BlockGroup&gt;
+      &lt;Block&gt;{binary video frame}&lt;/Block&gt;
+      &lt;BlockAdditions&gt;
+        &lt;BlockMore&gt;
+          &lt;BlockAddID&gt;2&lt;/BlockAddID&gt;&lt;!--arbitrary value from
+            BlockAdditionalMapping--&gt;
+          &lt;BlockAdditional&gt;01:00:00:00&lt;/BlockAdditional&gt;
+        &lt;/BlockMore&gt;
+      &lt;/BlockAdditions&gt;
+    &lt;/BlockGroup&gt;
+  &lt;/Cluster&gt;
+&lt;/Segment&gt;
 ```
 
-Block Additional Mappings detail how additional data **MAY** be stored in the `BlockMore Element`
-with a `BlockAdditionMapping Element`, within the `Track Element`, which identifies the `BlockAdditional` content.
-Block Additional Mappings define the `BlockAddIDType` value reserved to identify that
-type of data as well as providing an optional label stored within the `BlockAddIDName Element`.
-When the Block Additional Mapping is dependent on additional contextual information,
-then the Mapping **SHOULD** describe how such additional contextual information is stored within the `BlockAddIDExtraData Element`.
+`Block Additional Mappings` detail how additional data **MAY** be stored in the `BlockMore` element
+with a `BlockAdditionMapping` element, within the `Track` element, which identifies the `BlockAdditional` content.
+`Block Additional Mappings` define the `BlockAddIDType` value reserved to identify that
+type of data as well as providing an optional label stored within the `BlockAddIDName` element.
+When the `Block Additional Mapping` is dependent on additional contextual information,
+then the Mapping **SHOULD** describe how such additional contextual information is stored within the `BlockAddIDExtraData` element.
 
-The following Block Additional Mappings are defined.
+The following `Block Additional Mappings` are defined.
 
 ## Summary of Assigned BlockAddIDType Values
 

chapter_codecs.md

@@ -26,8 +26,8 @@ between the chapter codec values and the actual segment it targets.
 
 # Matroska Chapter Codecs and Nested Chapters
 
-When `Nested Chapters` contain chapters codecs -- via the `ChapProcess` Element --
-the enter/leave commands -- ChapProcessTime Element -- **MUST** be executed in a specific order,
+When `Nested Chapters` contain chapters codecs -- via the `ChapProcess` element --
+the enter/leave commands -- `ChapProcessTime` element -- **MUST** be executed in a specific order,
 if the Matroska Player supports the chapter codecs included in the chapters.
 
 When starting playback, the `Matroska Player` **MUST** start at the `ChapterTimeStart` of the first chapter of the ordered chapter.