; XML file format for DAWs
Learning Center
Plans & pricing Sign in
Sign Out

XML file format for DAWs


  • pg 1
									XML file format for DAWs: Abstract, acknowledgements and contents   Yuli Levtov


XML file format for DAWs: Abstract, acknowledgements and contents   Yuli Levtov


XML file format for DAWs: Abstract, acknowledgements and contents   Yuli Levtov

       The audio industry offers users many different software packages to
record, edit and produce music and sound. It does not, however, offer users
an effective method of transferring an entire project, including detailed
metadata, from one such digital audio workstation (DAW) to another.
       This is a study into the design of an XML-based (extensible markup
language) file format for the DAW industry which draws upon research into
the industry leading DAWs, Pro Tools and Logic, along with two lesser known
applications – Ardour and Reaper. An equivalent interchange format in the
music notation industry, MusicXML, is also carefully analysed. The proposed
interchange format is able to transfer complex project information which, to
this day, has only been accommodated by proprietary file formats.
       The result of this study is an annotated and fully functioning XML
schema written in the RELAX NG (regular language for XML next generation)
format. After a brief insight into the social aspects of implementing such an
interchange format, the conclusions are drawn that an open-source
interchange format is perfectly viable, in theory, but that the market leaders
are, currently, too concerned with customer lock-in to adopt one.

       I would like to thank the following people for their contributions
towards my research. Roey Izhaki for generally guiding me through the
process and contributing lots of valuable ideas, Andy Farnell for some
important hints and tips, Taybin Rutkin for helping me with some tricky bits in
XML, Joe Bull, Michael Good and Daniel Spreadbury for taking the time to
talk to me about their industry experiences, and Paul Davis for running the
Ardour project, which, along with MusicXML, has been a constant source of

XML file format for DAWs: Abstract, acknowledgements and contents                                    Yuli Levtov

Table of Contents

  method ....................................... 1	
  Current industry overview ............................................................................1	
  Aims of this research ...................................................................................2	
  XML technology ...........................................................................................4	
               Quality control with schemas.........................................................4	
               Transforming XML using XSL (Extensible Stylesheet Language) .5	
  Existing technologies ...................................................................................6	
               OMFI (Open Media Framework Interchange)................................6	
               AAF (Advanced Authoring Format) ...............................................7	
               AES31 ...........................................................................................9	
  Examples in other industries......................................................................10	
  Lessons from MusicXML and their application to this study ......................11	
               ʻApply usability techniques to XML language designʼ..................11	
               ʻDevelop the format together with the softwareʼ ..........................13	
               ʻSupport a market leader earlyʼ....................................................13	

  analysis .................................... 15	
  Setting the scope and DAW analysis.........................................................15	
  Scope limitations........................................................................................18	
  Analysing source code and proprietary file formats ...................................19	
               Preliminary: Requesting information from the manufacturers .....20	
               Reverse engineering method ......................................................20	
               Logic analysis ..............................................................................20	
               Pro Tools analysis .......................................................................22	
               Ardour analysis............................................................................22	
               Reaper analysis...........................................................................31	
               Conclusions from source code analysis ......................................37	

  design....................................... 39	
  Design goals ..............................................................................................39	
  Design process ..........................................................................................39	
XML file format for DAWs: Abstract, acknowledgements and contents                                     Yuli Levtov

  Adapting the Ardour file format ..................................................................40	
               Playlist functionality .....................................................................40	
               Folder functionality ......................................................................43	
               MIDI .............................................................................................46	
  Other design considerations ......................................................................47	
               External file referencing...............................................................47	
               SysEx sections ............................................................................48	
               Optional sections and default values...........................................48	
               Choosing between attributes and elements ................................49	
               Value ranges and data types.......................................................49	

  results....................................... 51	
  Introduction ................................................................................................51	
  Example XML document............................................................................51	
  RELAX NG schema ...................................................................................51	

  Conclusions ..................................................................... 52	
  Evaluating the file format ...........................................................................52	
  Further work...............................................................................................53	
               True MIDI or MusicXML implementation .....................................53	
               Support a wider range of DAWs ..................................................54	
               Automated information lists .........................................................54	
               Build in support for more plug-in formats.....................................54	
               More accurate value representation ............................................54	
  Industry perspectives .................................................................................55	
  Closing comments .....................................................................................56	

  Appendices ..................................................................... 58	
  References ...................................................................... 62	
  contents............................................... 64	

XML file format for DAWs: Background, theory and method              Yuli Levtov

Current industry overview
       Fully featured music production suites including multi-channel mixing
desks, vintage dynamic processors and effects, and cutting edge digital
signal processors now sit in every home with a laptop computer. The rapid
advancement of the digital audio technology, the plummeting prices of the
hardware required to run it, and the lowering level of expertise required to
operate it has all resulted in a thriving market for audio recording, producing
and sequencing software. Highly developed and sophisticated DAWs are
available on the internet with prices ranging from thousands of pounds to
absolutely free and a professional sounding production is no longer exclusive
to a professional studio, with many highly regarded producers and mixers
openly admitting that they make many of their hit-records completely ʻin the
boxʼ i.e. without the use of any external hardware or digital signal processing.
       When multiple DAWs began appearing on the market and competing
with one another, each had its own proprietary method of storing information.
This is still the case today, with nothing in the way of sophisticated
interchange capabilities between DAWs from different manufacturers.
However it is now the case that information transfer speeds have risen to a
level which allows people to share entire projects via the internet.
Collaborations spanning the globe are commonplace and it is rarely the case
that every party will be using the same software. The begs the the question:
why is there no standard and effective file format for transferring data
between DAWs?
       Quite simply, and sadly, the answer to this lies in the fact that there is
no economic incentive for any of the big manufacturers to invest any time or
money on such a project. The dominant companies would rather concentrate
on further enhancing their own software and bringing in customers who will
use their products exclusively.

XML file format for DAWs: Background, theory and method              Yuli Levtov

       Despite this fact, the prospect of a truly perfect all-rounder DAW that
satisfies all the specialist needs of all demographics is nigh on impossible.
Certain DAWs will always have their specialties and aspects that cater to a
particular demographic better than all the rest and the audio workstation
market will always be thriving with competition. For example, Pro Tools 8 has
seen significant improvements in the area of MIDI sequencing and virtual
instruments – an area in which it was previously lacking – however Logic is
still much more popular when it comes to sequenced electronic music.
Similarly, Logic 9 has greatly improved its feature set in the area of audio
manipulation such as time-stretching and destructive editing, but Pro Tools
still dominates the industry of recording live instruments. There will always be
the demand for the ability to conveniently switch between various software
       The fact that there is no economic incentive for the manufacturers to
create such an interchange method does not mean that it would not present
them any benefits. “MIDI […] has undoubtedly been the most single
successful piece of cross-industry collaboration that has happened” (Davis
2009b) and is a good example of a standard that has been widely accepted
and implemented since soon after its invention. Although MIDI is relatively
basic, it continues to facilitate the effective communication between all sorts
of hardware and software, to this day.

Aims of this research
       This study will assess the possibility of a new XML-based interchange
file format for modern DAWs. By researching existing technologies in this
area as well as the coding protocols that would be used to create such a file
format, this study will form a balanced judgement as to if, why and how
something like this could exist in the audio engineering industry. The tangible
results of the research will include:
       -      an annotated suggestion for a structured definition of an
       efficient way to store the information required using XML schemas
       -      an example of a project file in the proposed file format

XML file format for DAWs: Background, theory and method            Yuli Levtov

      Hopefully, the information that is accumulated and presented as a
result of this research will make a compelling case to DAW manufacturers
and governing standards bodies and ideally these findings will play a part in
a movement towards the creation of a fully functioning interchange format
that the market leading DAWs will support within their software, either
natively or as an export format. This file format would contain project
information down to a level of detail which before now has only been seen by
the applicationsʼ own proprietary formats and furthermore, would store this
information in such a way that it could be opened reliably and predictably by
any other supported DAW.

      The simple rationale behind the creation of such a file format is the
desire to increase workflow for the users and to broaden the possibilities of
any given project, with the ability to use the best features from any DAW
without needing to worry about compatibility issues. The ability for people to
share project files with one another knowing that it will be opened by a
different program, or a different version of the same program, will mean that
people can specialise in chosen fields more, instead of having to learn how to
perform all tasks to a mediocre level in one program. It could help overcome
situations where amateur musicians want to take projects into commercial
studios, but cannot due to the studios only accepting Pro Tools projects, for
example. Or, in the other direction, this could allow musicians who record at
a studio and want to take their recordings home with them and continue with
production or mixing at home to do so. And in a slightly contradictory
direction to other reasons for this research, it could be said that such a
potential, for users to ultimately swap to another DAW with ease, will make
the market even more competitive and force the major companies to develop
better, truly all-rounder packages. A more competitive market with higher
customer expectations would result in a raised standard of quality for DAWs.

XML file format for DAWs: Background, theory and method             Yuli Levtov

XML technology
       XML (extensible markup language) is best described as ʻnot a markup
language; rather [as a] toolkit for creating, shaping, and using markup
languages.ʼ (Ray 2003) XML is used extensively for data management and
storage and has a few distinct aspects that make it suitable for an
interchange format of this variety. These include the following:
       -      It is human-readable making it easy to develop, read and edit.
       -      It is flexible, with each markup language having a unique set of
       used elements and attributes, defined by the developer.
       -      It is easily extensible. XML-based markup languages use a
       hierarchical structure, where tags are nested within each other so
       extra elements can be added to a markup language without disrupting
       the rest of the definition.
       -      XML is widespread, well known and well supported throughout
       the computer technology industry and there are many XML tools freely
       available on the internet, such as editors and validators.
       -      Being closely linked to HTML, XML has been accepted
       enthusiastically by the Internet community (Ray 2003) and can be
       confidently predicted to remain a significant and unwavering
       technology for many years to come.

Quality control with schemas
       By definition, an interchange format will be read and written by many
different applications or programmers from different manufacturers, and a
method of guaranteeing consistency among these different parties is crucial.
A schema or DTD (Document Type Definition) is a set of rules or guidelines
against which an XML document must adhere in order to be considered valid.
If the document structure or language not abide to these rules, the validating
software will return error messages. This increases the stability of the
interchange format by ensuring that any document that has been written to
adhere to the guidelines is, indeed, usable by all other implementing

XML file format for DAWs: Background, theory and method             Yuli Levtov

applications. As Erik Ray comments: ʻA schema can also be used to publish
a specification for a language in a succinct and unambiguous way.ʼ (2003)
       In the realm of XML there are two main types of guideline formats:
DTDs and schemas. DTDs have been around the longest and are therefore
the most widespread and supported (Ray 2003), however they are not written
in standard XML syntax and are therefore comparatively difficult to read. The
guideline for this file format has been written using a schema language called
RELAX NG, due to its suitability to the task of initial schema development. It
offers much more readability and ease of use than other languages without
sacrificing capabilities. Also, tools are readily available to translate RELAX
NG schemas into other schema languages, including DTD, if desired.

Transforming XML using XSL (Extensible Stylesheet Language)
       In order for DAWs to read from the interchange format, the information
will have to undergo a transformation so as to comply with the conventions of
the target applicationʼs storage system. Similarly, when applications come to
write their information to the interchange format, their proprietary format will
have to be transformed in order to meet the requirements of the standard.
These transformations can be performed by XSLTs (XSL Transformations).
XSLTs are also written in XML and can be used to perform all kinds of
transformations on XML documents, from minute alterations to complete
structural overhauls. As will be demonstrated, XSLTs are a crucial aspect of
such an interchange format and they often complete the tasks concerning the
translation of features that are not present in the importing DAW. Another
example of how XSLTs may be used is the simple fact that all DAWs store
values such as pan and gain between different ranges e.g. Pro Tools pan
values go between -100 and 100, whereas Logic pan values are between -64
and 63. Therefore these values must be normalised in order to be usable any
       It is important to note, however, that the writing of these stylesheets
would be the responsibility of the software manufacturers – not the
developers of the interchange format. This is because one must know all the

XML file format for DAWs: Background, theory and method              Yuli Levtov

details of the target applicationʼs proprietary format in order to write an XSLT
for it and it is these details which the large-scale manufacturers are so
protective over. So, while this study does what it can to highlight to the
manufacturers what needs to be included in the XSLT, it is the task of their
developers to actually write it.

Existing technologies
       There are a number of existing interchange formats made for a similar
purpose to the one that is proposed here, each having experienced various
degrees of success. The post-production industry, among others, has always
had the need for an accurate method of interchange between various media
systems, as all TV or film project go through at least two different applications
even before it reaches any audio engineers. Many of the existing
technologies have been created with this industry in mind, prioritising
sample-accurate positioning of media clips. However, none seem to execute
the level of functionality that would make such a format comprehensive
enough to effectively transfer entire audio projects from one DAW to another.

OMFI (Open Media Framework Interchange)
       Developed by Avid and originally intended for video editors
transferring EDL (edit decision list) data between various video editing suites,
or between video and post-production facilities, OMF is one of the most
widely used edit data exchange formats for media applications. It is
supported by many DAWs including Pro Tools, Cubase, Nuendo, Logic and
Digital Performer, making it popular with professionals and amateur users
alike. Although successful, in that it is relatively widely adopted by the
industry as a useful standard, it is by no means an interchange format
capable of transferring a whole project full of data used by a modern DAW.
Appendix A displays a demonstration of the kind of information that can be
transferred by an OMF file. The file has been exported out of Logic and then
re-imported back into Logic to guarantee that minimal information is being
lost due to transferring between different applications.

XML file format for DAWs: Background, theory and method                    Yuli Levtov

         As can be seen from the screenshots in Appendix A, there is a lot of
information lost during the export process. The most notable losses are mixer
settings such as pan and gain along with automation, despite the fact that
OMF specifications claims that this data is transferred. Stereo files are split
down to mono and, where regions are looped, each occurrence of a loop is
displayed as an individual region. This highlights another point of contention
with OMF and indeed most of the current media interchange formats: the fact
that all audio files must be bounced to an identical file format and packed into
a single zipped file, amounting to hundreds of megabytes. OMF uses binary
files and therefore deep analysis of the code to identify information structure
is beyond this study, however superficial analysis, as can be seen above,
can be helpful to identify points for improvement in an ideal interchange

AAF (Advanced Authoring Format)
         AAF is another format that is not intended exclusively for audio
applications, but for all types of digital media data, including video, graphics
text and more. AAF was born from a combined effort of many different large
scale media companies such as Microsoft, BBC, CNN, Avid and Pinnacle,
who together founded the AAF Association (now called the Advanced Media
Workflow Association1) and was regarded and developed as a direct
expansion on OMF, with 95% of the AAF Software Development Kit having
been written by Avid (AMWA 2008). The large corporate base gave the
format the advantage of guaranteed adoption by at least a few of the most
important applications in the industry, however its huge scope meant it could
never be specialised enough to satisfy the needs of the audio industry. Then
again, as an interchange format that was designed for the media industry as
a whole, it can be assumed that it was never meant to do so. Again, Pro

    AMWA website: http://www.aafassociation.org/ The AAF Association was renamed to the
Advanced Media Workflow Association so as to incorporate MXF-based technologies
(AMWA 2008)

XML file format for DAWs: Background, theory and method              Yuli Levtov

Tools and Logic, among many other DAWs, support AAF and can be used to
produce similar results to the ones shown from the demonstration of OMF,
above. As summarised by the AMWA:
       ‘The goal of the [AAF] Edit Protocol is to provide users with a
       mechanism for reliable interchange of program metadata,
       -      Edit Decision information, such as source and record time
              codes, source tracks, physical source names, frame- and
              sample-accurate clip definitions, clip- and time-based
              comments, clip names and track names.
       -      Visual Effects information, such as dissolves, SMPTE wipes,
              2D DVE spatial positioning and zooming effects, frame
              repeat effects, motion and speed change effects, flip and
              flop effects, as well as composite layering effects.
       -      Audio Data, such as clip- and track-based gain, stereo pan,
              fade in and out, symmetrical and asymmetrical crossfades
              and MIDI data.
       -      Predictable application behavior, including predictable
              fallback behavior when an application is not able to process
              elements of a file.’ (AMWA 2005)
       One significant distinction AAF makes from OMF is its separation of
what it calls ʻEssenceʼ and ʻMetadataʼ. In the case of the audio industry,
Essence is the collection of audio files used in a project. Metadata is the term
used to describe ʻdata about data, that is data about Essence.ʼ (Santos 2006)
Metadata for DAWs will typically include region information, start and end
points, and volume automation etc. In practical terms, the implication of such
a separation means that the audio files do not have to be copied to a single
location in order to be imported by another DAW so the AAF file size can be
kept small.
       Despite these features, AAF can be regarded as a rather unsuccessful
file format, with hardly any of the implementing DAWs supporting it fully and
Pro Tools actually having its own implementation of the format which “isn't
even compliant with the AAF standard.” (Davis 2009b)

XML file format for DAWs: Background, theory and method             Yuli Levtov

       Currently, however, AAF is one of the most widely used interchange
formats in the audio industry.

       A full explanation and history of the AES31 standard is beyond what is
required to appreciate its influence on this study. To summarise, however,
AES31 was instigated by the Audio Engineering Society in the late 1990s. It
was supposed to be a simple text based file format with aims which were
very similar to those of the format proposed, here. It was mostly unsuccessful
and development activity has since all but ceased. Unlike OMF and AAF,
AES31 is dedicated to the audio industry. It is divided into four main sections.
These are summarised best by Mel Lambert (2001):

       -     ‘AES31-1 is concerned with physical data transport,
             how files can be moved from one system to another — either
             via removable media or (later) a high-speed network.
             Basically, AES31-1 specifies a transport compatible with
             Microsoft's FAT32 structures, although, for copyright
             reasons, it doesn't actually name Microsoft or quote its
             proprietary specifications.
       -     AES31-2 focuses on audio file format, how the data in
             BWF or Broadcast Wave chunks should be arranged on the
             removable media or packaged for network transfer.
       -     AES31-3 describes a simple project structure, using a
             sample-accurate Audio Decision List, or ADL.
       -     The more complex AES31-4 object-oriented project
             structure could use an extensible object model capable of
             describing a much wider range of parameters for
             applications where the costs of significant additional
             complexity can be justified.’

       Generally speaking, the first three of these sections cover the same
ground as OMF and AAF. It is the fourth section that was supposed to be the

XML file format for DAWs: Background, theory and method               Yuli Levtov

fully featured, multi-faceted portion of the interchange format that transfers all
the extra information that had not yet been covered, such as automation and
mixer levels and so on. Due to reasons that are explained more in the last
section of this paper, it was never ratified.
         Since it was never completed, AES31 is not currently used in any
commercial software applications.

Examples in other industries
         Successful interchange formats exist in most industries of computer
technologies. JPG and PNG for images, PDF for documents, ZIP for archived
files, to name but a few.
         A relevant, useful example of a relatively new interchange file format
can be found in the industry of music notation software. Many parallels can
be drawn between the music notation industry and that of DAWs. Both have
a handful of powerful market leaders, each with their own strengths and
weaknesses and their own proprietary file formats. Both industries have seen
attempts at devising a file format that stores relevant data in a common way
and many of these attempts have fallen by the wayside.
         MusicXML (developed by Recordare2) is an open-source interchange
format for notation software, specialising in post-17th century western music.
Having been developed since 2000 (version 1.0 shipped in 2004, but was
actually working with commercial software since 2001 (Good 2006)), it has
become the most widely accepted interchange standard for the industry and
is currently adopted by over 60 different symbolic music applications,
including the two market leaders, Sibelius and Finale. MusicXML has
provided many clues and guidelines towards this research, as it achieves an
equivalent result to what this file format is intended to work towards. The
MusicXML format has been studied in depth by analysis of its source code,
review of all of its published documentation and also talking with its creator,

    Recordare website: http://www.recordare.com/

XML file format for DAWs: Background, theory and method                    Yuli Levtov

Michael Good3. Perhaps most importantly, however, MusicXML has
supported the fact that the ultimate aim of this research is theoretically and
socially possible. As mentioned above, DAW industry has its similarities with
the music notation industry and the MusicXML format has succeeded despite
the strictly limited success of others. The next section of this study is devoted
to analysing MusicXML and the reasons why it has become a successful
interchange format, with a view to applying some similar techniques to the file
format that is proposed, here.

Lessons from MusicXML and their application to this study
          As part of MusicXMLʼs documentation, its creator, Michael Good,
published a paper that discusses the lessons he and his team learnt from the
creation of their XML interchange format. The paper is divided into the
following headings:
          -      ʻApply usability techniques to XML language design.
          -      Develop the format together with the software.
          -      Support a market leader early.
          -      Market to other software developers.
          -      Give format developers good support.
          -      Avoid overheadʼ (Good 2006)
          The last three from this list were undoubtedly important to the success
of MusicXML, however are not strictly relevant to this research at this time,
so how they would apply to this project has not been included here.

ʻApply usability techniques to XML language designʼ
          In order for an established software application to implement a new
technology into their system, it is important that the language and structure of
the interchange format ʻfeels rightʼ to their developers. Good further sub-
divides this need into specific ways in which a new specification can improve
its chances of appealing to industry applications:
Set an appropriate scope

3                                                                    th
    A phone conversation was held between myself and Michael Good on 16 October 2009

XML file format for DAWs: Background, theory and method             Yuli Levtov

       Recordare limited the range of material that their format would cover to
ʻcommon Western music notation form the 17th century onwards.ʼ This choice
was justified by the fact that this still covers a wide enough range of material
to make this format comprehensive and useful to a wide range of users.
       The scope of this interchange format is of great importance. The
SMDL (Standard Music Description Language) format for symbolic music
notation attempted to graphically represent ʻall musicʼ and Good regards its
demise to be related to this unachievable breadth of scope. Conclusions
regarding the suitable capabilities of the proposed file format are covered in
detail, below.
Use appropriate terminology in the format language
       Instead of using computer terms that may be more meaningful to
general programmers, who do not necessarily know anything about music
notation or score reading, MusicXML uses musical terms in the source code
as much as possible. This concept can be mapped directly onto the
proposed file format by using standard DAW terminology, wherever possible.
ʻClarity over concisionʼ
       This simply means design considerations such as the full spelling of
terms, where appropriate, and the use of elements over attributes in the XML
code (this concept is covered further, later). Like the previous point, this
measure is designed to make the actual XML easier to understand by
musicians and easier to write by programmers. Again, this principle can be
incorporated directly into this research.
Logical representation of document structure
       The structure of a MusicXML document ʻclosely matches the structure
of many leading symbolic music formats, both in commercial and academic
applications.ʼ (Good 2006) This is a natural step to making the interchange
format seem more native and natural to application developers. To meet this
recommendation, the proposed document structure would need to be built
upon logical concepts found within the commercial DAWs. Hierarchies such
as Audio trackplaylistregions will need to be carefully scrutinised and
compared against many different DAWs to see which arrangement could be

XML file format for DAWs: Background, theory and method              Yuli Levtov

considered the most neutral and universal, yet comprehensive and useful.
This summarises one of the largest angles of this research.

ʻDevelop the format together with the softwareʼ
      In the development of MusicXML, Michael Good and his team
implemented a process called ʻiterative designʼ. Generally speaking, this
technique involves the creation of a prototype product, the evaluation and
testing of this product by an impartial 3rd party such as a focus group, and
then the refinement of the product based on the results from the testing. The
refined product is then tested by the 3rd party again and the cycle continues
until a suitable result is reached. For MusicXML, this involved creating
software to run tests on development stage versions of their file format and
then improving it on the basis of the test results. This is undoubtedly a good
idea in any design project, but true iterative design, with dedicated 3rd party
focus groups is sadly outside the scope of this study. As is discussed later,
however, the use of XML validators can provide a very useful source of
feedback that can aid the format design process.

ʻSupport a market leader earlyʼ
      As has been shown to be the case with the DAW industry, the music
notation market has also seen various attempts at interchange formats over
the years. SMDL and NIFF (Notation Interchange File Format) were the most
accomplished, with SMDL even acquiring approval from the International
Standards Organization, yet neither were said to achieve their goals of
becoming a standard interchange format for symbolic music notation
software (Good 2006). The main reasons for this was that neither format was
implemented by any industry software, despite industry support during
development. This issue is one of Michael Goodʼs key points as to how to
make a successful interchange format:
      ‘Make sure that the format can exchange data in both directions
      with at least one market leader in your application area. Do this as
      early as possible in your development process. Do not expect the
      market leaders to do this for you.’ (2006)

XML file format for DAWs: Background, theory and method             Yuli Levtov

       For MusicXML, as Michael Good has expressed on numerous
occasions, this meant that gaining support from either Finale or Sibelius was
of the utmost importance:
       ‘When Recordare started the MusicXML project, a key milestone
       was that we be able to read and write MusicXML files from either
       Finale or Sibelius within a set period of time. If we did not
       accomplish that goal, we would give up and I would move on to
       other things.’ (2006)
       Two of the most dominant DAWs in the industry today are Pro Tools
and Logic. If this file format is to become of interest to anyone, it would need
to support at least these two market leaders. It would seem, however, that
the DAW market is divided among a larger number of applications than the
notation industry. Other very popular DAWs include Nuendo, Digital
Performer, Cubase and Sonar to name a few and, in order to guarantee that
this format does not quickly become irrelevant, it is important that it offers
support to at least 4 mainstream DAWs. Relating closely to the aspect of
scope, it is crucial that the format focuses on the information that all the
applications have in common and be as unbiased in language and structure
as possible – there is no benefit to an interchange format covering a myriad
of advanced features that only one DAW is actually capable of representing.

XML file format for DAWs: Defining the file format: analysis                        Yuli Levtov

Setting the scope and DAW analysis
          As was learnt from MusicXML, the first task became to set the scope
of the file format. Ideally, the file format will contain all of the following
information in an unbiased, unambiguous way4:
          -      region information/location (Edit Decision List style)
          -      track names
          -      mixer settings (volume, pan, mute etc.)
          -      I/O settings (routing, sends, busses etc.)
          -      MIDI events/regions
          -      video track(s)
          -      automation
          -      region fades and crossfades
          -      GUI information (track layout etc.)
          -      Plug-in information
          -      Playlist contents
          -      Transport and operational data (tempo/key map, markers etc.)
          This is the scope of the actual information that is to be included in the
interchange format. It is important to note that, while an interchange format,
by definition, will naturally focus on the information that all systems have in
common, a truly useful and sophisticated interchange format will also include
information that is not necessarily standard across the range of programs,
and store it in such a way that it becomes readable by a larger number of
applications. These fundamental differentiators are features such as Playlist
functionality, which is included by most but not all DAWs – Logic being a
major application that does not. Conversely, Logic is one of the few
applications that supports Folder functionality – Cubase being another.
Bridging the gap between these applications is an important aspect of such a

    A mind-map version of this list can be seen in the appendices (Appendix   C).

XML file format for DAWs: Defining the file format: analysis        Yuli Levtov

file format, yet it must be realised that this may not always be possible –
there will always be certain features in one application that simply have no
equivalent in another.
       The scope of the variety of programs that will be able to use it must
also be considered. It is outside the range of this project to analyse all the
DAWs that could potentially end up using a file format such as this or even all
the operating systems on which the applications run. Therefore a small
selection of programs that best represent a large proportion of the industry in
terms of capabilities has to be made. As alluded to, above, application
platform must be considered. Apple Macs account for a very large proportion
of the professional and hobbyist audio industry, however Windows and Linux
have significant user bases also. Most audio applications run on at least
Windows and Mac OS X, however there are many that are exclusive to one
operating system. Research into Linux exclusive or Windows exclusive
DAWs is also slightly outside the scope of this paper, however as will be
seen, below, some applications have been chosen for analysis due to their
multi-platform natures.
       As is evident from the example regarding DAW-specific functionalities,
above, Pro Tools and Logic should be considered to be justified choices to
include in the analysis. This choice is further justified by the fact that they
cover very different areas of the industry in terms of end-users. Pro Tools has
a long history and reputation for being an excellent tool for recording audio
and is an industry standard which can be found in most commercial recording
studios. Logic, on the other hand, is much more geared towards sequenced
music and is favoured by many electronic artists. By choosing the best from
both worlds, a much fuller feature set is being covered.
       So as to cover a wide range of end-users, as well as a wide range of
features, it is also important to look at some less wide-spread programs for
various reasons. These include the following:
       -       Developers of newer programs have the advantage of yearsʼ
       worth of previous examples of DAW capabilities and would have,
       theoretically, cherry-picked the best ones to include in their

XML file format for DAWs: Defining the file format: analysis          Yuli Levtov

          applications. This serves as an indicator of what features are actually
          valued by users and therefore what features should be included in an
          interchange format.
          -       Smaller scale applications tend to use more accessible,
          readable file formats. This is because they are less protective over
          their proprietary formats, with many applications even being open-
          source. This readability is very useful when it comes to analysing file
          format code.
          -       New applications are more likely to implement an interchange
          format such as the one being proposed here. A young application
          manufacturer is always keen to enhance interchange functionality as it
          increases workflow for its customers and increases the chances of
          people using its product, whereas long-established application
          manufacturers would rarely justify the time and money it takes to
          implement the supporting of a new file format. Therefore for practical
          reasons, if this file format were to succeed, it would need to appeal
          and be relevant to these newer applications just as much as the
          industry leaders.
          Of the younger DAWs that exist on the market, Ardour and Reaper
have been chosen for analysis.
          Ardour is a multichannel DAW that runs on Linux and Mac OS X and
is completely open-source. It has an extensive feature set and has proved
very popular with many audio enthusiasts, both novice and professional, and
is actually being used in a handful of commercial recording studios (Davis
2009a). Currently at version 2.8.3 and sold for a price chosen by the
consumer5, Ardour includes many features that one would only expect to see
in much more expensive systems. It also has capabilities that many of its
larger competitors donʼt have, such as an ʻanywhere-to-anywhereʼ routing
system that allows any signal to be sent to anywhere else in the session. The
development of Ardour 3.0 is addressing MIDI capabilities, as the current

    97% of users download the application for free (Davis 2009a)

XML file format for DAWs: Defining the file format: analysis          Yuli Levtov

version is strictly audio. Crucially, however, Ardour stores its files as XML
and so provides many clues as to an efficient method of information storage.
It is also worth noting that Ardour is the only DAW that has been chosen for
analysis that runs natively on Linux as well as Mac OS X (it was actually
originally made and developed for Linux).
       Reaper (Rapid Environment for Audio Production, Engineering, and
Recording) is another relatively young, successful audio workstation made by
the software company, Cockos. Also modestly priced, with licenses ranging
from $60 to $225, Reaper, like Ardour, offers a feature set that rivals many
larger commercial systems and many additional features that make it stand
out from the crowd for reasons other than its competitive pricing. It offers full
MIDI capabilities as well as audio recording, production and mixing. Reaper
also features a completely flexible routing system, such that ʻAny track can
function as a track, bus, or bus folder.ʼ (Reaper 2005) The fact that both
Ardour and Reaper feature this kind of functionality makes it a good example
of the features that new DAWs feel are important to many users and
therefore should definitely be considered for inclusion in a new interchange
file format.

Scope limitations
       It is important to state a few things that this format will not attempt to
cover in terms of DAW systems, at least at this research stage.
       Ableton Live is a hugely popular DAW that has gained a reputation as
the system of choice by many electronic artists for live performance and its
popularity as a sequencing and recording tool is rising, as well. However, this
system is slightly outside the range of this study due to its heavy bias
towards live performance. The Session view, which is arguably the backbone
of the system, allows users to stack audio or MIDI clips onto tracks vertically
and is totally unique to this proprietary system. However, given Liveʼs
functionality when accessed from the Arrangement view, which behaves
much like a traditional DAW, it could prove very useful to have an
interchange format with which Live users can make an arrangement of a

XML file format for DAWs: Defining the file format: analysis            Yuli Levtov

piece of music and then export it to another system for additional production
or mastering. So, although this proposed format could certainly have its uses
for Live users eventually, its integration into this research wonʼt be prioritised.
       Propellerheadsʼ Reason is another DAW that has many similar
features to programs such as Logic, Pro Tools and Cubase, but also has a
significantly different approach that prevents the incorporation of its
capabilities directly into this research. Reasonʼs Rack view is a very unique
workflow method and is heavily based on modularity, with a user defining
exactly what pieces of virtual hardware to place where, in what order and
exactly how they are interconnected. As in Ableton Live, however, Reason
does feature a more traditional Arrange page layout, so would certainly find a
use for this interchange format, in the future. Propellerheads have also
recently released an application called Record, which is much more of a
conventional DAW. Record would certainly be one of the key targets for an
interchange format like this and its manufacturers would perhaps be quite
interested in it as a way to entice unfamiliar customers to try their new
product. Recordʼs feature set does not appear to include any new DAW
conventions, such as Playlist or Folder functionality, that have not already
been covered by the other mainstream applications studied in this paper and,
therefore, does not warrant individual inspection at this stage.

Analysing source code and proprietary file formats
       The first angle from which the analysis of storage systems for different
DAWs was approached was to analyse the source code of their proprietary
file formats. If the hierarchical system of information storage could be
deduced from the existing file formats, some information regarding the most
efficient and neutral method of storage for the proposed file format could be
       Although the information and research is presented linearly, below,
this research was carried out in parallel with other research such as writing
parts of sample code in XML, correspondence with industry personnel and
researching other interchange formats.

XML file format for DAWs: Defining the file format: analysis          Yuli Levtov

Preliminary: Requesting information from the manufacturers
       This project would have been made much easier if some help from the
product manufacturers such as Digidesign and Apple could be acquired.
Before the project was even started proper, an e-mail was sent to all the
product manufacturers explaining the project and politely requesting some
correspondence with a developer or representative from their team (see
Appendix B). No replies from these requests were received.

Reverse engineering method
       Seeing as no access to the inner workings of the major DAW
applications could be gained from the software manufacturers, attempts at
extracting this information was attempted using a method called reverse
engineering. This is best summarised by Arleigh Crawford:
       ‘Software reverse engineering is done to retrieve the source code
       of a program because the source code was lost, to study how the
       program performs certain operations, to improve the performance
       of a program, to fix a bug (correct an error in the program when the
       source code is not available), to identify malicious content in a
       program such as a virus or to adapt a program written for use with
       one microprocessor for use with another.’ (2007)
       For the purpose of this research, reverse engineering took the form of
making very simple projects in the various applications and then analysing
the save file data. Then altering the project file in the smallest possible
increment, and then looking for differences in the save data between the first
project and the altered one. This cycle is then repeated until all the desired
data is deduced.

Logic analysis
       Logic stores its projects as .lso (Logic song) files and is expandable in
Mac OS X Finder. An .lso contains two files. One called ʻdisplayStateʼ and
another called ʻdocumentDataʼ. Although both are classed as Documents, the
first file is an Apple property list written in XML. This contains only the most
superficial display settings for the project such as screenset and transport

XML file format for DAWs: Defining the file format: analysis          Yuli Levtov

bar information. ʻdocumentDataʼ is a binary file and contains all the project
information. It is, however, completely undecipherable. Most of the file format
is   written in binary code and attempts              to reverse engineer the
ʻdocumentDataʼ file resulted in the amount of information in the file growing
hugely with even the smallest change to the project. Certain names that were
input into the project such as the title of a track could be seen in the code and
this name could even be changed in the file format via a text editor, with the
change being displayed in the Logic project. This however turned out to be a
dead end, as it was later discovered that the only elements of plaintext in the
Logic save file actually corresponded to undo data. This explained the
disproportionate growth in file length in response to small changes in the
project. Without wasting any more time on this clearly fruitless method of
analysis, research moved onto a more logical approach.
       By simply using Logic in the same way an end-user would, a fair
amount of information can be extracted about how the program must
structure its data in the save file. Figure 1 shows the kind of information that
could be extracted from this simple approach of analysis. Admittedly it is not
very detailed or specialised knowledge, however aspects like the nesting of
audio and MIDI regions within folders have to be carefully considered when
writing this information into a universal DAW file format. At this stage of the
research, this kind of information was all that was required to start outlining
the capabilities that need to be handled. Logic was returned to and studied in
more detail once the actual writing of the file format had begun.

                        Figure 1 - Logic structure mind map

XML file format for DAWs: Defining the file format: analysis         Yuli Levtov

Pro Tools analysis
       Pro Tools project information is stored in a .ptf (Pro Tools file). After
the failure of reverse engineering Logic files, it was no surprise to find the
same result with Pro Tools. Digidesignʼs file format was even more
scrambled and unreadable than that of Logic, with the code purely in binary
featuring no plaintext at all. Again, the best way to deduce the storage
methods of this DAW was to simply access all sections of the GUI and make
observations of the likely way in which information is structured and saved.
For both Pro Tools and Logic this method also proved the easiest to make a
complete list of common parameters that could be transferred between the
two. Parameters such as time stretching algorithms and settings for each
algorithm are now remarkably similar in both programs, for instance. Figure 2
displays some of the deductions made from looking at the Pro Tools GUI.

                      Figure 2 - Pro Tools structure mind map

Ardour analysis
       Next in line to be studied was Ardour. Due to the application being
completely open-source, it proved much more helpful in terms of being able
to read its storage format. Written entirely in XML, seeing exactly how the
Ardour file format is structured was very straight forward, especially when
compared with similar efforts on Logic and Pro Tools. What follows is an
annotated analysis of a typical .ardour file. The samples from the file have
been abridged so as to contain no more examples of each element or
attribute than necessary to demonstrate the principles at use.

XML file format for DAWs: Defining the file format: analysis                          Yuli Levtov

Annotated .ardour file
             The root element of the XML document is called <Session>. This
elements has attributes which identify the version of the program that has
made the save file, along with the project title, sample-rate and an id-counter.

             <Config> holds various pieces of information regarding session
configuration such as the last used edit mode, whether or not auto-input is
active or not etc. This is useful for operational settings of individual DAWs. 	

                            Audio files are defined as Sources. Stereo audio files are split down
to mono and each channel is given its own id and flag values but note that
this does not mean that stereo files are represented as split-mono files in the
session. This is the code for a stereo .wav file called ʻHH1.wavʼ. The flags
attribute holds various pieces of information that do not warrant attributes of
their own. This could be seen as an equivalent to SysEx data. In the
interchange format, other applications would ignore anything in this attribute,
but have their own such section in which they can store their own SysEx

             Regions are predefined and then there ID values referenced in the
playlists, when necessary. Regions use the ID numbers of the <Source>
elements (above) to identify which audio file this region is pointing to.
<ancestral-­‐start> refers to the point in the audio file which this region
begins at (value in samples from the original audio file start) and

XML file format for DAWs: Defining the file format: analysis                  Yuli Levtov

<ancestral-­‐length> indicates how much of the audio file this region
concerns. This is also where fade information is stored.

        What may be called 'channels' in other DAWs are called DiskStreams
in Ardour. These are also predefined so that the id values can be referenced
from the <Playlist> elements. Speed refers to the speed at which this
DiskStream plays (value as a ratio).	
        Locations may be called 'markers' in other systems. 	

                       Tracks are described as Routes. <Route> elements contain certain
track information such as mute and solo settings and refer back to the
<DiskStream> ID numbers to identify which channel the track is linked to.
The order-­‐keys attribute refers to the GUI positioning of the Route in the
arrange page (editor) and the mixer page (signal).	

XML file format for DAWs: Defining the file format: analysis                                          Yuli Levtov

          <IO> elements contain all information regarding input and output
connections within the project for its parent <Route>	
   <Panner> element is found here, along with any
automation information.	

          <Automation> displays the actual automation settings for the parent
IO element. Nodes are described as events and are listed in groups of two -
an ʻxʼ (timeline position in sample) and a ʻyʼ (value of parameter in arbitrary
units) value for each. The range of possible values for the y-axis of each
automation lane is defined by the min_yval	
  max_yval attributes.

          <controllable> elements give ID numbers to any element that can
be remotely controlled from other parts of the project.	

          <Redirect> elements are used wherever a signal is being redirected
to another destination. They contain standard <IO> elements and are used
typically for aux/bus sends and plug-ins.	

XML file format for DAWs: Defining the file format: analysis                                              Yuli Levtov

     As mentioned above, <Redirect> elements are used to route the
signal to or from an <Insert>. The <Insert> elements have attributes to
determine what type of plug-in it is (e.g. Audio Unit, LADSPA, VST etc.), a
unique name, and a count of how many there are in the signal chain. Each
type of plug-in has its own element (<audiounit>	
  in this case) which holds
its proprietary system information.	

XML file format for DAWs: Defining the file format: analysis                                   Yuli Levtov


          <PortAutomation> refers                         to any       automation     concerning any
parameters of the parent Insert.	

XML file format for DAWs: Defining the file format: analysis                            Yuli Levtov


                         The <EditGroups>	
  element holds the	
  <RouteGroup> elements that
are used to describe information about any edit groups in the session.	

          <MixGroups> is the same as above but with mix groups rather than
edit groups.	

               <Playlists> lists active playlists that do have audio on them. Active
playlists with no audio are not listed and are therefore not present when the
project is reopened. The <Playlist> element lists the regions that are on
that playlist. The <Region> elements here contain the same information as
the declarations of the regions, above, and also hold further information such
as the start time, length and position along the timeline (all in samples). The
<extra> section here holds information regarding to how the region is
displayed in the GUI.	

XML file format for DAWs: Defining the file format: analysis                            Yuli Levtov


                         <UnusedPlaylists> lists the playlists which are not currently active.	

                         The metronome function has its own dedicated element called
<Click> which holds a standard <IO> element, describing its gain and pan
settings etc.	

XML file format for DAWs: Defining the file format: analysis                          Yuli Levtov


        <TempoMap> lists any tempo and time signature changes throughout
the project, giving each one a start position, relevant attributes like BPM or
beats-per-bar and an attribute to determine whether or not it can be moved
from the GUI.	

                       This element contains information about any control surfaces that
may be used in the project.	

                       The <ClockModes> element in the <extra> element lists the mode
that each different clock in the project operates in. The choices are SMPTE
timecode, BBT (bar & beat), and MinSec. <RulerVisibility>	
which of the rulers at the top of the edit page are currently visible.	

XML file format for DAWs: Defining the file format: analysis          Yuli Levtov

       This clear storage hierarchy was incredibly helpful in devising an initial
base for the proposed file format. Ardour is a very comprehensive DAW and
therefore covers most of the features that are required by a wide range of
systems. As is shown below, when this format is adapted and made more
suitable for multiple programs, it is a relatively simple task to implement
further functionality. Significant elements that are missing from this format are
capabilities such as MIDI and video channels.

Reaper analysis
       Reaper projects are stored as .RPP files and, like Ardour, are
completely human-readable. Written in its own style of simple tags with
space delimited labels and values .RPP files seem very straightforward to
write and read, with names of parameters and source files written out in
abbreviated, plain text. The advantage of writing a file format in a proprietary
style as Reaper has done is that it does not have to adhere to any rules or
conventions that standard, regulated languages do, so it can be relatively
concise, very literal and contain only the information that is necessary for that
particular project. This same point can just as easily be seen as a
disadvantage, as the format is less inherently defined, with most elements of
information appearing in the save file when, and only when, they are needed.
Although this method may be suitable for a single application, an interchange
format would benefit much more from the regulations set out by a defined
standard coding language such as XML and the necessity to strictly adhere
to them.
       One feature of .RRP files worth noting is the limited scope of values
that are stored. This is to say that where the Ardour file format would have
most probably featured an element or attribute with a choice of values,
written out in full, that indicate the setting of the parameter, Reaper tends to
have an attribute accompanied by a numeric value, with each value

XML file format for DAWs: Defining the file format: analysis                       Yuli Levtov

indicating a different combination of parameter settings. This makes the file
quite concise, but immediate human comprehension is sacrificed. The
simplistic nature of the Reaper file format did not warrant as deep an analysis
as the Ardour file format, however it did contribute some extra information
and another angle regarding the storage of project information. Some key
points are shown, below.

Annotated .RPP file
          Much like the .ardour file, the top element in .RRP files is a header tag
containing project information such as the last used edit mode, cursor
position and loop position. The second line is an example of the .RPP system
of attaching numbers to each possible value relating to an attribute. Here,
   has three possible values: ʻdisabledʼ, ʻenabledʼ and ʻenabled: all
tracksʼ6. These are represented by 0, 1 and 2 respectively, so this is showing
that Ripple mode is currently disabled in this project. As mentioned above,
this method has its advantages and disadvantages. A number value is much
less ambiguous than a text value so this system could be said to be more
reliable and definite. On the other hand, for an interchange format with an
extensive number of variables and possible values for each attribute, a
numbering system would quickly get unmanageable, with long reference
tables being required stating exactly which numeric value corresponds to
which parameter value. This concept is discussed again, later.

    Ripple mode is Reaperʼs equivalent to the Shuffle editing mode in Pro Tools

XML file format for DAWs: Defining the file format: analysis                                    Yuli Levtov

         The metronome settings are contained in a dedicated tag. Reaper has
a feature allowing users to load their own samples into the inbuilt metronome
to use as the primary and secondary click beats.
         Tracks are defined in the order that they appear in the main
arrange/edit window. A TRACK tag contains all information regarding that
track, such as automation, regions, plug-ins and routing. The REC line is a
good example of how the numeric value system can be very ambiguous. A
table of numeric values and their meanings, such as the one exemplified in
Figure 3, must exist for each attribute in the project.

XML file format for DAWs: Defining the file format: analysis                                    Yuli Levtov

 Attribute name            Tag name            value            Parameter value
 Record arm settings       value)	
   Not record armed
   Record armed
 Recording input           'REC'	
 source                    value)	
   Mono:Analog 1
   Mono:Analog 2
   Mono:Analog 3
   Stereo:Analog 3 / Analog 4
   Stereo:Analog 4 / Analog 5
   MIDI Input:Sync Port:Channel 2
   MIDI Input:Sync Port:Channel 3
 Input monitoring          'REC'	
 settings                  value)	
   No input monitoring
   Monitor Input
   Monitor Input (Tape Auto Style)
 Record source             value)	
   Record: input
                                                                   Record: disable (input monitoring
   Record: output (MIDI)
   Record: output (mono)
                                                                   Record: output (mono, latency
   Record: MIDI overdub in existing items
   Record: MIDI replace in existing items

                Figure 3 - Table of numeric value descriptions for Reaper

         The list of plug-ins or virtual instruments present on a track follow the
declaration of the track properties. (The plug-in manufacturerʼs own
proprietary binary code has been shortened for the purpose of illustration.)

XML file format for DAWs: Defining the file format: analysis                            Yuli Levtov

        Any regions, whether they are audio, video, MIDI or ʻempty eventsʼ, a
feature unique to Reaper which is used to identify punch-in and out points,
are called ITEMs. These tags contain information regarding common
attributes for any region such as timeline position, fade information, and
volume automation. This is the code for an audio file called “robot tribe.mp3”.
        The SOURCE tag identifies the source of the region that is being
described in the ITEM tag. This is the tag for an MP3 file. The SECTION
values identify which part from within the original audio file the region begins
and ends, and the nested SOURCE tag identifies what format the file is, along
with its destination on the usersʼ hard-drive.

XML file format for DAWs: Defining the file format: analysis                                                       Yuli Levtov

           Reaper has full MIDI recording and editing capabilities. This is the
SOURCE tag representing a MIDI region with a few MIDI events. These are
stored in a proprietary method using hexadecimal values to represent all the
standard information. This method is considered for the interchange format in
more detail during the development stage, below.

           The Reaper file format is more concise than that of Ardour in some
ways, yet more verbose in others. Tags containing information only appear if
there is something to store – there are never empty tags floating around in an
.RPP file, thus bringing the file length down. On the other hand, where Ardour
predefines elements such as audio files and then references them by using
ID numbers, Reaper will write out the name and path of the audio file in full
every time it needs to use it, thus making the file, arguably, less efficient. The

XML file format for DAWs: Defining the file format: analysis        Yuli Levtov

MIDI storage method of Reaper is helpful in devising something similar in the
interchange format, yet it could be debated whether or not it would be simpler
to actually export MIDI files and have the file format reference them as it
would an audio or video file or using a predefined MIDI-as-XML format. This
will be considered during the design process.

Conclusions from source code analysis
       As can be seen, the Ardour file format was by far the most useful in
terms of gathering an idea of a data storage method for DAWs. If referring
back to Michael Goodʼs criteria as to what constitutes sensible XML language
design with regards to interchange formats, the Ardour format fulfils many of
these objectives. Namely, Ardour largely uses terminology that is familiar to
the DAW as a whole – not just its own application (ʻUse appropriate
terminology in the format languageʼ) – most terms are written out in full
without needless abbreviations (ʻClarity over concisionʼ), and the structure of
the format echoes the predicted structure of other DAWs (ʻLogical
representation of document structureʼ). Given this fact, it seems a very
sensible decision to base this file format on that of Ardour. There are many
areas in which adjustments will have to be made to make the format more
versatile, however the underlying structure and terminology is an excellent
starting point for an XML based standard.
       As has already been mentioned, Folder functionality is a fundamental
aspect of Logicʼs operation, however it does not have an equivalent in Pro
Tools, Ardour or Reaper. As Ardour does not support Folder functionality, this
is one of the main areas which has been seen as a priority for the
development of this file format.
       Other functionality that needs to be addressed in order to broaden the
Ardour file format include:
       -       Video capabilities
       -       More sophisticated fade and cross fade options
       -       Mix/edit group settings
       -       MIDI functionality

XML file format for DAWs: Defining the file format: analysis       Yuli Levtov

       It is important to note that these issues are by no means criticisms of
the Ardour application, which is most definitely a project that promotes
openness in audio file formats, as opposed to the protective behavior of the
current market leading manufacturers. These are merely ways in which the
groundwork laid out by Ardour can be harnessed and built upon to create
something the benefits the whole industry.

XML file format for DAWs: Defining the file format: design           Yuli Levtov

       As mentioned above, small bits of code were being researched and
developed while analysis of the file formats was still taking place, however,
with the Ardour file format fully analysed, it was time to begin adapting it to
suit a wider range of applications.

Design goals
       The main aim of the design stage of this research is to create a fully
functioning schema using the RELAX NG language. This document acts as
the official specification for the proposed interchange format and is the
document against which any implementing applications test their output XML
files. Additional to the schema, an example of an XML document that
adheres to rules of the schema is also provided. The example document
shows the file format ʻin actionʼ and is easier to understand than the schema.
Lastly, as per MusicXML documentation, a table listing every attribute and
element used in the file format, including a short description for each, is also

Design process
       As this standard is based on the Ardour file format, first, a schema
was designed to validate the .ardour XML document. This process provided a
fully functional schema which could be developed and altered, where
necessary. Once the Ardour schema was complete, design of the
interchange standard began in earnest. Initial alterations were made to the
XML document and the schema in parallel. Some alterations were made to
the XML document first and subsequently mirrored in the schema, while
some alterations occurred the other way around.
       At a certain point in the design process, the development became too
complicated to continue working on the heavily-modified XML document in its
entirety and so was broken into parts. Some of these parts are analysed in

XML file format for DAWs: Defining the file format: design             Yuli Levtov

detail, below. By the time the first draft of the schema was complete and
validated using Jingi, the example XML document had been broken into
many parts and were no longer cohesive, so a completely fresh XML
document was written to demonstrate the schemaʼs capabilities. This was
written from the perspective of an application that was exporting a session to
the interchange standard (Logic 9.0.0 in this case). This is available on the
accompanying CD.

Adapting the Ardour file format

Playlist functionality
       It was important to accommodate applications that do not feature true
Playlist functionality in this standard. This meant that the Ardour file format
would have to be adapted slightly so that tracks on playlists could be
presented in such a manner that would make more sense to applications
such as Logic. The following is a detailed analysis of the Ardour method of
playlist storage and the ways in which it has been changed to accommodate
both Logic and other DAWs without this feature.
Ardour method
       <DiskStreams> define the tracks and specify which playlist is
currently active.

       <IO> in <Route> displays IO settings for each channel that is shown
on the 'Arrange' page. This includes <Panner> etc. and references the
original AudioDiskstream.

XML file format for DAWs: Defining the file format: design            Yuli Levtov


        <Playlist> elements specify what Regions etc. are on each playlist,
and which AudioDiskstream they stem from.

        And <UnusedPlaylists> lists all playlists that are not currently active

Logic compatible method
   can remain the same as each channel must still be
defined. In Logic, this is a loose equivalent of ʻCore Audio Channelsʼ, that can
only have one audio stream playing at any one time, much like a playlist.
        <Routes> can also remain unchanged as, in Logic, there can be
multiple instances of the same Core Audio Channel/AudioDiskstream and
they all share parameters such as gain, muting etc.

  can stay the same in terms of content, but a change in
terminology to 'ActivePlaylists' would make matters clearer. This element
would contain all the playlists that are 'active' in terms of DAWs that feature

XML file format for DAWs: Defining the file format: design              Yuli Levtov

true playlist functionality. For Logic, this will signify which playlists are on top
out of those which share the same AudioDiskstream

          <UnusedPlaylists> can also stay the same in terms of content,
except a name change to 'InactivePlaylists' would clarify the fact that, in
DAWs that don't support true playlist functionality, these are the playlists that
are below the 'ActivePlaylist' and therefore contain audio that is not intended
to be heard. To ensure that these regions do not play, the regions that are
not in the <ActivePlaylist> element must be muted by default (or at least
on start up).

XSLT considerations
             It seems that only cosmetic changes need to be made to the actual
structure of the file format in order to make the standard more relevant to
DAWs without the Playlist features. More work, however, would come in the
XSLT that the applications use to
convert the interchange format to
their proprietary file formats during
import. For the Logic XSLT, this
would come in the form of changing
the Core Audio Channel (see Figure            Figure 4 - Changing the Core Audio
                                                        Channel in Logic
4) for any tracks referenced in the
   element and muting any regions that are on those

XML file format for DAWs: Defining the file format: design                    Yuli Levtov

Folder functionality
       The other significant feature that must be included in the interchange
format is that of Folders. In Logic and Cubase, folders can be positioned on
either audio tracks or special folder tracks and look much like normal regions.
Folders can contain audio regions, MIDI regions, and even other folders.
Ardour method
       Figure 5 and the code, below,
shows the Ardour method of storing
playlists, with the elements <Playlists>
and <UnusedPlaylists> being on the
top layer of the session.

                                                    Figure 5 - Ardour playlist hierarchy

Logic compatible method
       In order to accommodate the use of
folders, the structure has to be significantly
rearranged.     Including     the    alteration    of
terminology       from      <Playlists>	
and    <InactivePlaylists>, Figure 6 and
the code, below, describe these changes.

       The top element to hold all the folders             Figure 6 - New playlist hierarchy
and playlist is now <Folders>.

XML file format for DAWs: Defining the file format: design             Yuli Levtov

        This is followed by the <TopFolder> element which must be present
in all projects. For DAWs that do not support folder functionality, this is the
layer on which all regions and playlists exist. The <TopFolder> element must
have an ID number which the folders nested inside it can reference. The
<TopFolder> element and all other <Folder> elements must also have a
layer attribute, to identify which layer of the session that folder resides on
(layer 0 is the top layer, layer -1 is the one below that, layer -2 is the one
below that etc.), so the <TopFolder> element will always be layer 0.
        As in the analysis for playlists, above, <ActivePlaylists> and
   contain <Playlist>	
   elements, and they in turn
contain <AudioRegions> and <MIDIRegions>. The <Playlist>	
now feature an attribute called parent_folder_id. This attribute identifies
which folder the playlist resides in (in this case, it can be seen to reside in the
<TopFolder>). The <editor-­‐order-­‐position>	
   element determines the
position of that playlist or folder track on the arrange page.
   elements can now also contain <Folder> elements.
Folders can contain Playlists containing audio and MIDI regions, as well as
other folders. Here, the parent_folder_id references the <TopFolder>
element as its parent folder. The <position> and <length>	
   elements are
used just as the are in audio or MIDI regions to state where on the timeline
the folder begins and how long it lasts.

XML file format for DAWs: Defining the file format: design                Yuli Levtov

       ʻFolder tracksʼ are tracks that cannot output audio and are used just to
contain folders.

       DAWs with true playlist functionality will simply have the top playlist in
the   <ActivePlaylists>          element,     and     lower   playlists     in   the
<InactivePlaylists> element. DAWs without folder functionality will just
not have any <Folder> elements present in their save files.
XSLT considerations
       A problem arises trying to convert files using <Folder> elements into
something that other DAWs can represent. This could be rectified by the
import-XSLT sheets of the DAWs referencing the playlist IDs, and placing
each playlist from identical DiskStreams onto a lower playlist of that
DiskStream, thus creating a stack.

XML file format for DAWs: Defining the file format: design                      Yuli Levtov

         Rather than use a proprietary method for storing MIDI files, such as
Reaperʼs, it would be far more efficient to simply reference a schema for
MIDI-XML files which already exist. Such schemas have been defined by the
MIDI Manufacturers Association7 as well as the creators of MusicXML8. For
the purpose of illustration, a web-based MIDI-to-XML converter9 has been
used to represent a typical MIDI file into the code, below. It has been edited
to make it more appropriate for this file format.

    ʻMIDI Names, Device Types, & Events in XMLʼ hosts all the DTDS necessary represent
MIDI events. http://www.midi.org/dtds/midi_xml.php
    All of the MusicXML DTDs can be found at http://www.recordare.com/dtds/
    MIDI2XML converter found at http://staff.dasdeck.de/valentin/midi/mid2xml.php

XML file format for DAWs: Defining the file format: design              Yuli Levtov


       In order to make this possible, the schema containing the MIDIXML
declarations of the relevant MIDI attributes and elements has been externally
referenced in the main schema.

       The MIDIXML.rng schema is a derivative work of the MIDIXML.dtd
and all the required Recordare licensing materials can be found in both the
example XML document and the finished schema, on the accompanying CD.

Other design considerations

External file referencing
       The method for locating the external media files used in a project must
be considered. As a project stored in an interchange is quite likely to be
moved to another machine, it would be sensible to copy all the project media
files to a single location during export. This location could then be stated
once in the XML, negating the need to reference the entire file path every the
source media file is referenced. This is similar to the Ardour method of file

XML file format for DAWs: Defining the file format: design               Yuli Levtov

SysEx sections
        Although an interchange format will concern itself more with
information that all implementing applications have in common, a great deal
of value is added by allowing applications to store extra sections of their own
data, which is only relevant to their system, directly in the file format. For this
purpose a SysEx (system exclusive) data section has been included in all of
the main parent elements. As can be seen below, the SysEx element has
attributes to denote the application name and version number that wrote this
particular bit of data. This makes it easy for applications importing these files
to identify whether this piece of SysEx data needs to be imported or needs to
be ignored. Any element that allows the inclusion of SysEx data can have
any number of <SysEx> elements, so there is no limit to how many
applications can store SysEx data in a single project.

Optional sections and default values
        Not all applications have the relevant features to fill out all of the fields
in the interchange format. Therefore, most of the elements and attributes in
the schema have <optional> tags around them, meaning that those
sections of the file format do not have to be present in order for the document
to be deemed as valid by the schema. This has implications for how an
importing application, which has a fuller feature set than the source
application, handles the absence of data. As a method of fallback, default
values can be entered into the missing data fields, if needed. This could be
performed at the export stage, so that when an application doesnʼt fill out an
element or attribute, a default value is automatically entered. Alternatively
default values could be entered at the import stage by the importing
application, as and when needed i.e. the absence of an element or attribute
will imply its default value. The second method is preferable due to the fact
that file size can be kept to a minimum by only inputting values where
necessary, instead of entering all default values for every file regardless of its

XML file format for DAWs: Defining the file format: design              Yuli Levtov

origins. In general, only the most important pieces of information have been
made compulsory.

Choosing between attributes and elements
       A common question that is raised whenever designing an XML
document is whether to store certain pieces of information as attributes or as
elements. The Ardour file format leans heavily towards the use of attributes
for most of its information. This is understandable for a format that is
intended for use with just one application, however an interchange format
would benefit from the clarity and flexibility offered by using multiple
elements. Michael Good, agrees with this viewpoint and says that ʻ[it] is the
rare cases where attributes were ill-advisedly chosen over elements that
have tended to cause problems during the growth and evolution of the
format.ʼ (2006) Needless to say, there are situations where attributes are
more suited to the task rather than elements and the design of this file format
has tried to adhere to the principal of ʻdata goes in elements, metadata in
attributesʼ (Ogbuji 2004). For this standard, that has meant that information
concerning exactly what something is, like the name of an audio file or its ID
number, has been written as an attribute and information regarding how
something behaves is stored as an element. If there has ever been any doubt
as to which of these two categories an item of information belongs to,
elements have always been favoured, but there have been situations where
exceptions to the rule have also been made. A full list of the schemaʼs
elements and attributes can be found on the accompanying CD.

Value ranges and data types
       All applications use different ranges to represent parameters that are
stored in this format. In the interest of simplicity, ʻfloatʼ data types with ranges
between 0 and1 have been used to represent most generic parameter
values, as opposed to proprietary parameters such as those belonging to
plug-ins, or those which have their minimum and maximum values stated as
part of the element. With values such as pan, ʻ0ʼ would represent hard left
panning, ʻ1ʼ hard right panning, with ʻ0.5ʼ representing central panning. One

XML file format for DAWs: Defining the file format: design          Yuli Levtov

issue worth considering, however, is what ʻ1ʼ and ʻ0ʼ represent for parameters
such as gain, which has different ranges from system to system. Of the
formats being used for evaluation in this research, the largest maximum gain
setting is +24dB from Reaper. The smallest minimum gain setting is –inf from
all the DAWs. The values one increment above –inf range from -71.7dB in
Reaper, to -185.9dB in Ardour (-95dB in Logic and -139dB in Pro Tools).
Research into the most accurate method of representing this range of values
is beyond the scope of this research, so a crude method of simply dividing 1
by the number of values inbetween the highest and the lowest number, which
is not –inf, has been used, here. This means that ʻ1ʼ represents +24dB and
ʻ0.00001ʼ represents -185.9db, with ʻ0ʼ representing –inf. Using this scale,
each increment is equivalent to 4.764173416 x 10-3 and a value of precisely
ʻ0.885659838ʼ represents 0dB. Admittedly, this method is rudimentary and
could be improved, as currently it can only represent a limited range of
values, however it does serve to represent at least all the DAWs used in this
         One small point on the subject of data typing includes the change from
the Ardour method of representing Boolean values as either ʻyesʼ or ʻnoʼ, to
the XML-recognized values of ʻtrueʼ or ʻfalseʼ. Also ID numbers must be
prefixed with an underscore (_) so as to make the most of the XML ID and
IDREF data types.

XML file format for DAWs: Defining the file format: results                          Yuli Levtov

           As already mentioned, the research and development processes
presented in this paper have culminated in two main documents; the RELAX
NG schema and the example XML document. These are both on the
accompanying CD.

Example XML document
           It should be noted that the example document is a snapshot of what a
true XML document written in this interchange format would look like and
therefore does not make use of every single element or attribute possible.
This is not to say that it is incomplete and it is still valid according to the

RELAX NG schema
           The RELAX NG schema is presented in its entirety and is valid against
the languageʼs own schema.

     This is with the exception of the MIDI events, the inclusion of which is noted in the ʻFurther
Workʼ section, below.

XML file format for DAWs: Conclusions                                Yuli Levtov

Evaluating the file format
       The file format defined in this research successfully details a structure
for storing DAW information, which, as shown, can be used by a number of
applications. It has been designed in such a way which conveys many
common parameters in an unambiguous fashion, yet is also, due to the
nature of XML, easily extensible and sufficiently flexible to survive the
alterations that may be necessary to bring it to a level which can be adopted
by the audio industry. As the Further Work section, below, outlines, there are
ways in which the proposed standard could be improved, however at this
stage, the schema is sufficiently developed to provide an insight into the
viability of an XML-based interchange format.
       As a method of evaluation, comparing the outcome of this research to
Michael Goodʼs recommendations for designing a successful interchange
format yields positive results:
       The scope that was set at the start of the project. and then reviewed
after some initial research, has remained fairly constant and the number of
DAWs chosen for analysis proved to be appropriate. One might contest just
how much knowledge was gained through studying Reaperʼs file format,
however it definitely offered some alternative options to the methods that
were eventually chosen, which always leads to a more informed decision.
Tackling the problem of representing Folders across all systems has proven
the most difficult task and whether or not the benefits of having this feature
outweigh the complications it has caused the format structure is debatable
and could be seen as a point worth reviewing in future versions of the
proposed standard.
       Appropriate terminology has been implemented throughout the
schema, without any significant bias towards any one application with
regards to how DAW project information is labelled.

XML file format for DAWs: Conclusions                                  Yuli Levtov

        As can be seen when comparing the Ardour and proposed file
formats, a very large proportion of the information that was once stored in
attributes is now stored in elements. This has made the file format much
more suited towards multi-application interchange and honours the rule of
ʻclarity over concisionʼ.
        Most importantly, however, is the question of whether or not the
proposed format represents a typical document structure logically. To a
certain extent, it could definitely be said to do so, as the hierarchical
arrangement of regions within playlists within tracks etc. seems to be, almost,
universal, and this fact has been echoed in the results of this research. On
the other hand, using a structure directly based on Folders will no doubt
make programmers of the applications whom this does not directly benefit
question its relevance and perhaps impede the formatʼs potential adoption.
This is to say that the relatively few occasions in which folders are used in a
project, they make simply cause problems with other applications, rather than
solve them. It is difficult to prove either way, as much of this concept relies on
the transformations performed by the importing applicationsʼ handling of the
data, however it is valuable to raise it as a possible point of contention.

Further work
        There are a number of directions in which this interchange format
could be expanded and developed further. A few of these are suggested

True MIDI or MusicXML implementation
        In its current form, the file format references a MusicXML DTD for
MIDIXML which has been converted to a RELAX NG schema using Trangii,
which, in turn, references an external DTD containing the details for MIDI
events. In order to incorporate the efforts of MusicXML into this file format, so
that score information could also be stored, a mechanism could be devised to
store the score and MIDI information from a project separate from the rest of
the information, so that the exporting application creates a project XML file

XML file format for DAWs: Conclusions                                Yuli Levtov

and a MusicXML file. These files would then be zipped. This would be a
much more efficient way of harnessing the technology that MusicXML has

Support a wider range of DAWs
       This is an obvious step for the file format to take. As mentioned in the
analysis section, there is a large number of DAWs in the market that would
be very suitable for this file format, however their unique features would have
to be explored and analysed in a similar way to how Logic, Pro Tools, Ardour
and Reaper have been.

Automated information lists
       As this file format stores information on which plug-ins, virtual
instruments and presets have been used in a project, and on which tracks
they appear, an XSLT script could be written to create a text document
containing this information. This could also include useful information such as
the version number of a plug-in, to avoid incompatibility issues. This would be
very useful when transferring projects between studios.

Build in support for more plug-in formats
       In the proposed format, only LADSPA and Audio Units plug-in formats
are mentioned. This could easily be expanded to support many other plug-in
formats, as they are mainly based on binary data which is input by the plug-in
itself – the XML only displays the information such as plug-in format, name,
preset etc.

More accurate value representation
       As already highlighted, values such as gain are difficult to represent in
an unbiased way and the method used in the file format is effective, but
crude and linear. Research could be performed into a more accurate method
of representing values for which the ranges vary from DAW to DAW.

XML file format for DAWs: Conclusions                                        Yuli Levtov

             It is becoming more and more commonplace to see DAWs with the
ability to stack passes of a recorded section into what are commonly called
ʻtakesʼ. Incorporation of this type of information is worth research if the format
is to be developed.

Industry perspectives
             As Michael Good duly points out, ʻgetting an XML format adopted as
an interchange standard is a social and technical processʼ (2006). No matter
how technically perfect a proposed file format is, it still needs to be adopted
by the industry in order to be useful to anyone. A comprehensive insight into
whether or not a file format like the one defined here would appeal to or ever
be adopted by software developers like Digidesign, Apple or Steinberg would
span a whole paper of its own, however, throughout the process of this
research, a few interesting opinions surfaced regarding the topic.
             Daniel Spreadbury, from the R&D department of Sibelius, offers an
interesting view point that as software matures and the user experience
becomes more important, based on confidence with the software, features
and compatibility and so on, application lock-in becomes less important11.
This could be to say that users in the audio industry are becoming more
mobile and more willing to switch to other applications if they discover that
competitorsʼ tools are more suited to their individual workflows. The fact that
users cannot take a Pro Tools session over to a set-up running a different
DAW does not make people less likely to ever switch applications. Although
Daniel says he can understand why this kind of interchange format hasnʼt
been accomplished in the DAW industry, he does admit that open file formats
are becoming increasingly important.
             Joe Bull (creator of SADiE, a popular PC-based DAW) was a key
proponent of the AES31 project and also feels that such an interchange

     Based on a phone conversation between myself and Daniel Spreadbury, which took place
on 22        October 2009

XML file format for DAWs: Conclusions                                        Yuli Levtov

format is “vital to the industry”12. However, he concedes that until Pro Tools
(“the elephant in the room” as he describes it) loses its market prominence,
such a format cannot prevail. From his direct experience with Digidesign
during the days of AES31, he recalled that, due to their concerns about
losing market dominance, they did not even attend any of the AES31
meetings. On a more positive note, Joe also highlights the gradual changes
in the industry which have occurred in the industry, such as the market
dominance Solid State Logic had back in the 1970s, when virtually all hit-
records were made on their mixing desks. They had a stronghold that could
be said to resemble that of Pro Tools, today, yet SSL is now just one of the
many successful console manufacturers.
          One industry sector that I feel would definitely support the idea of open
file interchange is that of the Linux audio community. In an interview with the
Open Source Musician Podcast, Paul Davis (lead developer of Ardour) hinted
at an “ecosystem” of programs based on Ardourʼs back-end code, which all
have a common file format. (2009b) On the subject of DAWs eventually being
able to easily swap projects back and forth, Paul goes on to say that
“[…]Ardour is an example of the type of technology that is going to promote
that type of interaction rather than impede it.” (2009b) Ardour and Reaper are
perfect candidates for a ʻtrial runʼ of this type of file format and due to the
open nature and positive attitude of the Ardour development community, I
believe that this could serve as a very powerful method of showing the
industry leaders that an XML-interchange format is valuable.

Closing comments
          ‘Standards adoption is a technical and social process, and careful
          attention must be paid to both to meet with success.’ (Good 2006)
          This study has focused on the technical aspect of a new standard.
With the knowledge accumulated and used over the course of this research, I
feel that a useful contribution to the audio engineering community has been

12                                                                                         nd
     Quoted from a phone conversation between myself and Joe Bull which took place on 22
November 2009

XML file format for DAWs: Conclusions                               Yuli Levtov

made. If users or manufacturers want to look at an example of an XML-based
DAW interchange format, this research can provide a good starting point, as
well as presenting a list of considerations and possible improvements. The
resulting schema shows that this type of open-source file format can be very
effective at DAW project interchange and that XML technology is an excellent
candidate for the tool on which to base such a standard.
       From the number of previous attempts at such a format and the
opinions of users and software developers alike, there seems to be a united
desire for a universal interchange format, however until the “commercial self-
interest”, as Paul Davis describes it, (2009b) of the industry leaders
subsides, all that can be done is to develop the format so that it is ready for
implementation when the time comes. Clearly, the industry will adapt to allow
interchange formats to take their place, but it may take another decade or so
for that to happen.

XML file format for DAWs: Appendices   Yuli Levtov

Appendix A – OMF export results

 XML file format for DAWs: Appendices                             Yuli Levtov

Appendix B - Letter to software manufacturers

 To Whom It May Concern:
 For my major research dissertation at SAE Institute, London, I will define an
 open-standard XML-based project file format that all major DAWs can save and
 open. It will tackle existing issues with the OMF format, and continue the
 concept further to include transferable information such as mixer information,
 plug-in settings and automation data.

 In order to make this project successful I could use feedback from your
 company regarding my research. More specifically, I am looking for a quick
 reply to some questions sent by e-mail.

 Your help is critical for my research and I would highly appreciate your

 Many thanks for your time.

 Yours sincerely,
 Yuli Levtov

XML file format for DAWs: Appendices         Yuli Levtov

Appendix C - File format coverage mind map

XML file format for DAWs: Appendices   Yuli Levtov

XML file format for DAWs: References                                 Yuli Levtov

AMWA (2005) Advanced Authoring Format (AAF) Edit Protocol. [Online]
       Available at:
       v1.1.pdf (Accessed 13 October 2009).

AMWA (2008) AMWA. Available at:
       PT2008lr.pdf (Accessed 13 October 2009).

Crawford, A. (2007) SearchCIO-Midmarket. Available at: http://searchcio-
       (Accessed: 15 October 2009).

Davis, P. (2009a) Interview with Paul Davis. Interviewed by Leo Laporte and
       Jono Bacon for Floss Weekly Podcast [Podcast] 12 September 2009.
       Available at: http://twit.tv/floss86 (Accessed: 03 October 2009).

Davis, P. (2009b) Interview with Paul Davis. Interviewed by Daniel Worth for
       Open Source Musician Podcast [Podcast] 27 September 2009.
       Available at: http://opensourcemusician.libsyn.com/ (Accessed: 03
       October 2009).

Franklin, R. (2002) Mix Online. Available at:
       (Accessed: 01 October 2009).

Good, M. (2006) Lessons from the Adoption of MusicXML as an Interchange
       Standard. Available at: http://www.recordare.com/xml.html. (Accessed:
       10 September 2009).

Lambert, M. (2001) Mix Online. Available at:
       (Accessed: 01 October 2009)

XML file format for DAWs: References                              Yuli Levtov

Ogbuji, U (2004) IBM. Available at:
      (Accessed: 10 October 2009)

Ray, E.T. (2003) Learning XML. 2nd edn. Sabastpol: OʼReilly Media, Inc.

Reaper (2005) Feature Highlights: Recording and Routing. Available at:
      http://www.reaper.fm/aboutaudio.php (Accessed: 29 August 2009).

Santos, E. (2006) AAF, MXF, XML... Putting It All Together. [Online]
      Available at: http://www.mog-

XML file format for DAWs: Endnotes and CD contents                           Yuli Levtov


             Jing is an XML tool used to validate XML documents against
schemas. In this project it has been used to perform validation checks on the
original .ardour files against the RELAX NG schema created around it, the
proposed interchange format schema, itself, against the schema for RELAX
NG documents, and also the example XML document against the finished
interchange format schema. Available at:
             Trang is another XML tool. It converts XML schemas from one format
to another. It has been used in this project to convert the MIDIXML DTD into
an RELAX NG schema that has been externally referenced in the proposed
interchange schema. Available at:

Accompanying CD contents
        The main results of this research, along with supplementary materials
are on the accompanying CD.
Folder                    File name                      Description
DAWML 0.1                 DAWML 0.1.rng                  RELAX NG schema for DAWML
DAWML 0.1                 dawml-index.xls                Index of attributes and elements
DAWML 0.1                 midixml.dtd                    DTD for MIDIXML
DAWML 0.1                 midixml.rng                    RELAX NG schema for MIDIXML
Supplementary material    Ardour mind map.bmp            Mind map of Ardour file format
Supplementary material    DAWML coverage.bmp             Mind map of DAWML file format
Supplementary material    DAWML mind map.bmp             Mind map of DAWML file format
(N/A)                     Sample DAWML project.xml       Example project file stored in
(N/A)                     XML file format for DAWs.pdf   PDF copy of written dissertation
(N/A)                     DAWML 0.1.pdf                  RELAX NG schema in PDF form

Word count: 13,294


To top