<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [
<!ENTITY docname "draft-swhited-mka-stems-09">
]>
<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="04" day="12"/>
    <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 and Digital Audio
        Workstations 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 for live mixing of music.
        Historically stems have been stored as individual audio files, or using
        patent-encumbered or vendor specific, proprietary container formats.
      </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.
        A better model is to have the producer release the original 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 in a single file.
        The target consumer of these stem files are DJ applications meant for
        live remixing and performance, as well as Digital Audio Workstations
        (DAWs) used by producers who want their music to be remixed.
      </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>
      <name>Track Layout</name>
      <section anchor="s_audio_streams">
        <name>Audio Streams</name>
        <t>
          Each stem file may contain an arbitrary number of tracks containing
          audio and <bcp14>MUST</bcp14> include at least three audio tracks (the
          mixed audio and at least two stems).
          For stem files meant for live DJ use, it is <bcp14>RECOMMENDED</bcp14>
          that four or fewer stem tracks be used (as opposed to stem files meant
          for music production or non-live remixing where a DAW may utilize a
          significantly larger number of 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.
          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 <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 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 mastering and possibly
          excluding inter-stem effects at the producers discretion) 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>
          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.
          Instead they should retain the same 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 equivalent to the
          level of the final mix.
        </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>
        <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 (generally no more than one word),
          but no specific format or length requirement 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.
        </t>
        <t>
          For each stem track a tag
          (<xref target="RFC9559" sectionFormat="comma" section="5.1.8"/>)
          <bcp14>SHOULD</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>
    <section>
      <name>Mastering</name>
      <t>
        Because mastering happens post-mix and the stems are pre-mix audio the
        stem tracks <bcp14>SHOULD NOT</bcp14> have any mastering steps applied.
        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 mastering 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>
    </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 "Music production" are intended to be
        distributed for remixing in a non-live setting (ie. with a DAW or music
        tracker).
      </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, Music 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>
        </tbody>
      </table>
    </section>
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <t>
        This memo 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_COLOR</td>
            <td>UTF-8</td>
            <td>This document, <xref target="s_audio_streams"/></td>
          </tr>
        </tbody>
      </table>
    </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>
        Finally, thanks to the members of the IETF CELLAR working group,
        especially Steve Lhomme, for their feedback.
      </t>
    </section>
  </back>
</rfc>
