<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [
<!ENTITY docname "draft-swhited-mka-stems-12">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="&docname;" ipr="trust200902" obsoletes="" updates="" xml:lang="en" version="3" submissionType="independent">
  <front>
    <title abbrev="MKA Stem">Matroska Stem Files</title>
    <seriesInfo name="Internet-Draft" value="&docname;"/>
    <author fullname="Sam Whited" initials="ssw" role="editor" surname="Whited">
      <organization>Independent</organization>
      <address>
        <email>sam@samwhited.com</email>
        <uri>https://blog.samwhited.com</uri>
      </address>
    </author>
    <date year="2026" month="08" day="14"/>
    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>audio</keyword>
    <keyword>matroska</keyword>
    <keyword>stems</keyword>
    <keyword>djing</keyword>
    <abstract>
      <t>
        This document defines a multi-track profile of the Matroska container
        format for distributing stems.
        It is intended to be used by DJ applications, Digital Audio
        Workstations, and multi-track recorders while remaining backwards
        compatible with existing media players.
      </t>
    </abstract>
  </front>
  <middle>
    <section>
      <name>Introduction</name>
      <t>
        Stems are recordings of individual instruments, or clusters of
        instruments, used by DJs and music producers when mixing music.
        Historically stems have been stored as individual audio files, or using
        patent-encumbered, proprietary container formats.
      </t>
      <t>
        In the context of Digital Audio Workstations (DAWs), trackers, and
        multi-track recorders, the term "stems" is used to mean the audio data
        for an individual track before or after printing the result of effects,
        EQ, compression, or other plugins that have been applied to the track.
        It is often desirable to save the stems alongside the final mix for
        archival purposes, or as an intermediary step after printing effects and
        automation before importing them into a different DAW to continue work
        on the final production.
      </t>
      <t>
        Many DJs also perform live remixing of music using stems, however, when
        performing live it is normally beneficial to keep track of fewer
        instruments at one time.
        Most DJ software limits the number of stems to 4, meaning that stems in
        the DJ context are often a mixdown of similar elements in the final
        track (ie. "stem" in the context of DJing is the output of a bus or a
        submix of the "stems" from the DAW context).
        For example, a DJ may have stems for bass that is actually a sub-mix of
        the bass guitar and a bass-like sythesizer, a drum track that is a mix
        of the 5 individual mics used to record the drum kit as well as a mix of
        the hand drums used later in the song, a vocals stem with a single vocal
        mic, and a Melodies stem with a mix of the various primary instruments
        that carry the melody and harmonies.
      </t>
      <t>
        A common feature of modern software used by DJs is "dynamic" or "live"
        stem separation where the DJ software attempts to algorithmically
        separate the audio signals in a track to allow the DJ to mute, solo, or
        apply effects to individual instruments.
        The results of such dynamic separation vary but are, generally speaking,
        noticeably different from the original stems used by the producer and
        frequently contain distortions and other artifacts that sound
        undesirable.
        For DJing, a better model is to have the producer release a collection
        of prepared stems along with the original track.
        This allows the final mix to sound closer to the producers original
        vision for the track, even while it is being remixed and re-interpreted
        by a DJ or another artist.
      </t>
      <t>
        This specification documents a profile for the Matroska container
        format <xref target="RFC9559"/> that allows it to store the final mix
        for a track alongside the lossless or lossy stems used to mix the
        track, as well as separate stems meant for DJing, all in a single file.
        The target consumer of these stem files are DJ applications meant for
        live remixing and performance, as well as DAWs used by producers who
        want their music to be remixed or archived.
      </t>
      <section anchor="requirements">
        <name>Requirements Language</name>
        <t>
          The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
          "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
          "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
          "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>",
          "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
          "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
          described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
          when, and only when, they appear in all capitals, as shown here.
        </t>
      </section>
    </section>
    <section anchor="s_stem_version">
      <name>Versioning</name>
      <t>
          Files that meet the criteria of this document <bcp14>MUST</bcp14>
          have a global UTF-8 tag with the name "<tt>STEM_VERSION</tt>" with the
          value "<tt>1.0</tt>".
          The presence of this tag indicates that this is a stem file and the
          value indicates compatibility with this document.
          The value may or may not be changed in the future if new versions of
          this format are created.
      </t>
    </section>
    <section>
      <name>Track Layout</name>
      <section anchor="s_audio_streams">
        <name>Audio Streams</name>
        <t>
          Each stem file may contain an arbitrary number of audio tracks and
          stem files meant for use by DAWs <bcp14>MUST</bcp14> include at least
          two audio tracks (the mixed audio and at least one stem).
          Stem files meant for DJ use <bcp14>MUST</bcp14> include at least three
          audio tracks (the mixed audio and at least two stems).
          Stem files meant for DJ use <bcp14>SHOULD</bcp14> contain four or
          fewer stem tracks.
        </t>
        <t>
          For ease of decoding each track <bcp14>SHOULD</bcp14> be encoded using
          the same codec with the same parameters including bitrate, and sample
          rate.
        </t>
        <t>
          Stems are often recorded with a single channel and only the final mix
          is in stereo.
          For stem files that are meant to be re-mixed by a DAW this is fine,
          but DJs may want to maintain a similar balance and channel layout to
          the original track.
          Stems meant for DJ use <bcp14>MAY</bcp14> have a different channel
           count or layout than the main audio track, however it is
          <bcp14>RECOMMENDED</bcp14> that all stem tracks meant for DJ use
          maintain the same channel count and layout as the main track and have
          the same channel balance as their component parts in the final mix.
          For example, if the final mix is a stereo track that contains a fiddle
          that is 75% in the right channel and only 25% in the left channel,
          the stem track for the fiddle would also be in stereo with the stem
          mostly appearing from the right channel as in the final mix.
        </t>
        <t>
          The first track containing audio data <bcp14>MUST</bcp14> be the final
          post-mix audio in the default language (the mixdown track).
          All mixdown tracks regardless of language <bcp14>MUST</bcp14> have the
          Matroska "<tt>Default</tt>" flag set to "<tt>1</tt>"
          (<xref target="RFC9559" sectionFormat="comma" section="18.1"/>,
          <xref target="RFC9559" sectionFormat="bare" section="5.1.4.1.5"/>).
          This helps preserve backwards compatibility in media players which do
          not support this format which typically play the first audio stream
          found or may select based on the default flag.
          In addition, the "<tt>Enabled</tt>" flag for any mixdown tracks
          <bcp14>MUST</bcp14> be set to "<tt>1</tt>"
          (<xref target="RFC9559" sectionFormat="comma" section="5.1.4.1.4"/>).
        </t>
        <t>
          The remaining audio tracks will be individual stems and
          <bcp14>MUST</bcp14> have the same effective length as the mixdown
          track such that playing each stem track from the beginning would
          result in roughly the same audio (excluding the final stages of
          mastering) as the final mix present in the mixdown track.
          For example, if the original track is three minutes long and the
          stem file includes a percussion track but the percussion does not
          start until minute two, the percussion stem would still be three
          minutes long but would contain a minute of silence at the
          start of the track, or would have a block timestamp
          (<xref target="RFC9559" sectionFormat="comma" section="10"/>)
          that sets the effective start time to one minute.
        </t>
        <t>
          In addition, for stems meant for DJ use <bcp14>SHOULD</bcp14> have
          the same number of samples as the final mix to make seeking and
          syncing various combinations of stems easier on the DJ software.
        </t>
        <t>
          Each stem track <bcp14>MUST</bcp14> have the Matroska
          "<tt>Default</tt>" flag set to "<tt>0</tt>" and <bcp14>MUST</bcp14>
          have the "<tt>Enabled</tt>" flag set to "<tt>0</tt>".
        </t>
        <t>
          When creating the file the stem tracks <bcp14>SHOULD NOT</bcp14> have
          any intra-stem gain normalization applied to bring the stems up to the
          same perceived volume relative to each other.
          Instead, stem tracks meant for DJing should retain the same relative
          levels as they would have in the final mix present in the
          mixdown track so that if all stems were played at unity gain
          the overall level would be roughly equivalent to the level of the
          final mix.
          Steam tracks meant for archival and production use
          <bcp14>SHOULD</bcp14> be exported from the DAW or recorder as-is with
          no additional changes and <bcp14>MAY</bcp14> be exported before or
          after printing effects and the result of plugins.
        </t>
        <t>
          On playback, DJ software <bcp14>MAY</bcp14> choose to normalize the
          gain on any combination of stems currently being played to make it
          equivalent to the mixdown track or any other tracks being mixed in
          even if some stems are muted or have their individual gains adjusted.
          However, the exact mixing behavior of DJ applications is outside the
          scope of this specification.
        </t>
      </section>
      <section anchor="s_stem_metadata">
        <name>Stem Metadata</name>
        <section anchor="s_stem_use">
          <name>Use</name>
          <t>
            For each stem track a binary tag
            (<xref target="RFC9559" sectionFormat="comma" section="5.1.8"/>)
            <bcp14>MUST</bcp14> be set with its target set to the stem track
            and a tag name of "<tt>STEM_USE</tt>".
            The value of this tag is an unsigned 64-bit integer and
            <bcp14>MUST</bcp14> be one of the following values:
          </t>
          <table>
            <name>Defined Stem Uses</name>
            <thead>
              <tr>
                <th>Value</th>
                <th>Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td>0x00</td>
                <td>
                  Stems meant for live playback by DJs that may contain a mix of
                  various instruments and sounds.
                </td>
              </tr>
              <tr>
                <td>0x01</td>
                <td>
                  Stems output from multi-track recorders or DAWs containing
                  individual tracks that have been output before any effects,
                  EQs, or other plugins.
                </td>
              </tr>
              <tr>
                <td>0x02</td>
                <td>
                  Stems output from multi-track recorders or DAWs containing
                  individual tracks that have been output after printing any
                  effects, EQs, or other plugins.
                </td>
              </tr>
            </tbody>
          </table>
        </section>
        <section anchor="s_stem_color">
          <name>Color</name>
          <t>
            For each stem track a tag <bcp14>MAY</bcp14> also be set with its
            target set to the stem track and a tag name of
            "<tt>STEM_COLOR</tt>".
            The tag value must be a string in RGB hex format set to a color
            representing the stem (ie. "<tt>#145374</tt>").
          </t>
        </section>
        <section anchor="s_stem_name">
          <name>Name</name>
          <t>
            Each stem track <bcp14>MUST</bcp14> set the value of the track
            <tt>"Name"</tt> element
            (<xref target="RFC9559" sectionFormat="comma" section="5.1.4.1.18"/>)
            to a short, human-meaningful, track name for the stem that describes
            its contents, for example "Percussion" or "Vocals".
            These names are intended for display in playback applications and
            therefore should remain concise, but no specific format is defined.
            The track <tt>Name</tt> element <bcp14>MAY</bcp14> also be
            duplicated or overridden as a tag, in which case the order of
            precedence from
            <xref target="RFC9559" sectionFormat="of" section="24.1"/>
            <bcp14>SHOULD</bcp14> be respected.
            The maximum length of the name string (whether in the "Name" field
            or a tag) <bcp14>MUST NOT</bcp14> be longer than 20 bytes.
          </t>
        </section>
        <section anchor="s_stem_type">
          <name>Type</name>
          <t>
            The free-text "<tt>Name</tt>" field provides a label that is
            backwards compatible with existing software that supports Matroska,
            but does not necessarily provide enough information for DJ software
            implementing this format.
            Some software uses pre-defined stems (ie. always has "Vocal",
            "Melody", "Bass", and "Drum" stems), but the name is free-text and
            may not exactly match the name of the specific stem in that
            software.
            Or the software may want to display icons that represent each stem,
            or display translations in a language that is not already embedded
            in the files "<tt>Name</tt>" tags.
            For example, in most tracks with words there might be a stem with
            its name set to "Vocals" but another track may call it "Singer" or a
            traditional called folk dance track might name it "Caller".
            Software for stem playback might want to show a Microphone icon next
            to each of these tracks.
            To help map stems to individual icons or controller buttons, a
            binary tag with the name "<tt>STEM_TYPE</tt>" and a target of the
            stem track <bcp14>MAY</bcp14> be added to the file.
            The value of this tag is an unsigned 64-bit integer from the
            Matroska Stem Types Registry.
            The following initial values are defined:
          </t>
          <table>
            <name>Defined Stem Types</name>
            <thead>
              <tr>
                <th>ID</th>
                <th>Recommended Name</th>
                <th>Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td>0x00</td>
                <td>Other</td>
                <td>
                  Stems that contain a mix of other sounds that are not covered
                  by the other stems in the file.
                </td>
              </tr>
              <tr>
                <td>0x01</td>
                <td>Vocals</td>
                <td>Stems that contain sung vocals.</td>
              </tr>
              <tr>
                <td>0x02</td>
                <td>Spoken Word</td>
                <td>
                  Stems that contain spoken vocals including traditional dance
                  calls, or spoken words over a tune.
                </td>
              </tr>
              <tr>
                <td>0x03</td>
                <td>Melody</td>
                <td>Stem that contains the melody (regardless of instrument).</td>
              </tr>
              <tr>
                <td>0x04</td>
                <td>Bass</td>
                <td>Stems that include bass elements (regardless of instrument).</td>
              </tr>
              <tr>
                <td>0x05</td>
                <td>Percussion</td>
                <td>Stems containing percussive elements.</td>
              </tr>
              <tr>
                <td>0x06</td>
                <td>Synth</td>
                <td>Stems containing synthesizers.</td>
              </tr>
              <tr>
                <td>0x07</td>
                <td>Piano</td>
                <td>Stems containing piano or keyboard tracks.</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
    </section>
    <section>
      <name>Mastering</name>
      <t>
        Because the final stages of mastering happens post-mix and the stems are
        pre-mix audio the stem tracks <bcp14>SHOULD NOT</bcp14> have the final
        post-mix mastering steps applied (including any final compression or
        limiter steps).
        This means that a DJ playing the track using the stem tracks instead of
        the mixdown track will result in different audio from the final mix.
        This is deemed an acceptable trade off since the final sound of the DJs
        version of a track is likely to be significantly different from what the
        original track producer had created either way.
        Even without the final mastering steps this method still gives the
        producer more control over the final sound than if the DJ were
        to use an auto stem separation algorithm.
      </t>
      <t>
        Other mastering steps <bcp14>MAY</bcp14> be applied to the stems
        as well as to the final mix at the mastering engineers discretion.
      </t>
    </section>
    <section>
      <name>Format Support</name>
      <t>
        The Matroska container format can store many types of audio, not all of
        which are suitable for DJing or music production.
        To ensure compatibility between playback and encoding applications the
        following formats <bcp14>SHOULD</bcp14> be supported depending on the
        use case of the software as shown in the following table.
        Formats with the use case "Live remixing" are intended largely for
        playback applications meant for live performance (ie. DJ software).
        Formats with the use case "Production" are intended to be distributed
        for remixing in a non-live setting (ie. with a DAW or music tracker).
        Files with the use case "Recording" are meant to be written by
        multi-track recorders and later read by DAWs and <bcp14>MAY</bcp14> only
        support one of the recommended formats (ie. support for various forms
        of PCM audio is not required for a field recorder which likely only has
        hardware for integer or float PCM data, not both).
      </t>
      <table>
        <name>Audio codec support</name>
        <thead>
          <tr>
            <th>Codec</th>
            <th>Use Case</th>
            <th>Codec ID</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>FLAC <xref target="RFC9639"/></td>
            <td>Live remixing, Production</td>
            <td>A_FLAC <xref target="RFC9639" sectionFormat="comma" section="10.2"/></td>
          </tr>
          <tr>
            <td>Opus <xref target="RFC6716"/></td>
            <td>Live remixing</td>
            <td>A_OPUS <xref target="I-D.ietf-cellar-codec" sectionFormat="comma" section="3.4.32"/></td>
          </tr>
          <tr>
            <td>PCM, 32-bit float</td>
            <td>Production, Recording</td>
            <td>A_PCM/FLOAT/IEEE <xref target="I-D.ietf-cellar-codec" sectionFormat="comma" section="3.4.33"/></td>
          </tr>
          <tr>
            <td>PCM, integer little endian</td>
            <td>Production, Recording</td>
            <td>A_PCM/INT/LIT <xref target="I-D.ietf-cellar-codec" sectionFormat="comma" section="3.4.35"/></td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <section>
        <name>Matroska Tag Names Registry</name>
        <t>
          This document modifies the "Matroska Tag Names" registry defined in
          <xref target="I-D.ietf-cellar-tags" sectionFormat="of" section="6.1"/>
          to add the following values:
        </t>
        <table>
          <name>Additions to the "Matroska Tag Names" Registry</name>
          <thead>
            <tr>
              <th>Tag Name</th>
              <th>Tag Type</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>STEM_VERSION</td>
              <td>UTF-8</td>
              <td>This document, <xref target="s_stem_version"/></td>
            </tr>
            <tr>
              <td>STEM_COLOR</td>
              <td>UTF-8</td>
              <td>This document, <xref target="s_stem_metadata"/></td>
            </tr>
            <tr>
              <td>STEM_TYPE</td>
              <td>binary</td>
              <td>This document, <xref target="s_stem_metadata"/></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="s_stem_types_registry">
        <name>Stem Types Registry</name>
        <t>
          IANA will create a new registry called the "Stem Types Registry" which
          will store a list of specific stem types which may be mapped to
          localizable strings, icons, etc. by stem file playback software.
          This registry is not meant to be an exhaustive list of possible stem
          types.
          Instead, it is meant to contain commonly used general stem names to
          provide playback software a hint at how a specific stem might be
          displayed.
        </t>
        <t>
          To register a new Stem Type in the registry a unique unsigned 64-bit
          integer ID, a recommended name, and an optional reference to a
          document describing the stem type are required.
        </t>
        <t>
          The initial values of the Stem Types Registry are as follows:
        </t>
        <table>
          <name>Initial Contents of the "Stem Types" Registry</name>
          <thead>
            <tr>
              <th>ID</th>
              <th>Recommended Name</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td>0x00</td>
              <td>Other</td>
              <td>This document, <xref target="s_stem_metadata"/></td>
            </tr>
            <tr>
              <td>0x01</td>
              <td>Vocals</td>
              <td>This document, <xref target="s_stem_metadata"/></td>
            </tr>
            <tr>
              <td>0x02</td>
              <td>Spoken Word</td>
              <td>This document, <xref target="s_stem_metadata"/></td>
            </tr>
            <tr>
              <td>0x03</td>
              <td>Melody</td>
              <td>This document, <xref target="s_stem_metadata"/></td>
            </tr>
            <tr>
              <td>0x04</td>
              <td>Bass</td>
              <td>This document, <xref target="s_stem_metadata"/></td>
            </tr>
            <tr>
              <td>0x05</td>
              <td>Percussion</td>
              <td>This document, <xref target="s_stem_metadata"/></td>
            </tr>
            <tr>
              <td>0x06</td>
              <td>Synth</td>
              <td>This document, <xref target="s_stem_metadata"/></td>
            </tr>
            <tr>
              <td>0x07</td>
              <td>Piano</td>
              <td>This document, <xref target="s_stem_metadata"/></td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section anchor="Security">
      <name>Security Considerations</name>
      <t>
        This document inherits security considerations from both
        <xref target="RFC8794"/> and <xref target="RFC9559"/>.
        It does not have additional security considerations.
      </t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9559.xml"/>
    </references>
    <references>
      <name>Informative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6716.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8794.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9639.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-cellar-codec.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-cellar-tags.xml"/>
    </references>
    <section anchor="Acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>
        Thanks to the members of <tt>#matroska</tt> on the <tt>libera.chat</tt>
        IRC network, and to mosu and JanC in particular, for patiently
        explaining the basics of the format to me and for all their feedback.
      </t>
      <t>
        Thanks also to the members of the Ardour forums for their feedback
        on DAWs and mastering.
      </t>
      <t>
        Thanks to the developers of Mixxx and the members of the Mixxx forums
        for pointing out the potential pain points for DJ software.
      </t>
      <t>
        Finally, thanks to the members of the IETF CELLAR working group,
        especially Steve Lhomme, for their feedback.
      </t>
    </section>
  </back>
</rfc>
