NEMA

1
NEMA
2
Overview

• Multiple NEMA servers existing in geographically
  distributed locations with access to different
  audio collections
• Distributed computation logic allowing a user to
  request a resource from their nearest NEMA server
  (e.g. a certain set of features computed from a
  specified file)
• NEMA server will then determine if it has the
  audio and either compute the features and return
  them or farm the job out to the NEMA server that
  does have the audio and have it compute them

3
User scenariosMIR Researcher

• Upload their own component
• E.g. feature extractor, classifier, search
  indexer etc.
• Execute it against a virtual collection
• Files held remotely, perhaps at multiple
  locations
• Retrieve features or experiment results for use
  in research papers etc.

4
User scenariosCollection building

• Search/query metadata for collections held on all
  NEMA servers
• Build virtual collections with files from one or
  more real collections on the various NEMA servers
• Alias the collection (give it a name, e.g. MIREX
  2009 Genre classification, Kris West Thesis
  experiments)
• Publish virtual collections so other users can
  reuse them and generate comparable results

5
User scenariosMIREX DIY

• Participants upload their submissions (as a
  component)
• Execute own submission and confirm correct
  operation or fix it
• Submit results to MIREX
• Once all runs complete MIREX team runs evaluation

6
User scenariosMusicologist

• Reuse components published by other NEMA users
• e.g. Feature extractor from runner, classifier
  from M2K, MIREX evaluation script from M2K
• Connect them together to build an experiment
• Run the experiment against a virtual collection
• Collect results to use in research/papers etc.
• No programming involved (other than connecting
  boxes)

7
Black boxes

• NEMA users can upload code and publish it as a
  component
• Components built in Java or C/C/Matlab/Python/LI
  SP/etc. using a standard Java wrapper
• Upload code and generate component through a web
  interface
• On execution, console output may be retrieved
  (for debugging, progress monitoring etc. etc.)
• Can then be used to build experiments (flows)
• Publish components to allow other users to reuse
  them

8
Inter-component communicationA Common File Format

• In order for heterogeneous components to
  communicate they will have to use a standardised
  file format
• For security only the standard file format will
  be storable and retrievable from the NEMA servers
• Can analyse content to make sure whole audio file
  isnt in there
• Will need to be sufficiently flexible to
  represent any MIR data/metadata
• ACE XML/Music Ontology RDF? Namespace issues?

9
Common experiment formats

• Provide example experiments (flows) which may be
  run or modified to build new experiments
• Examples
• Genre classification
• Key detection
• Search/Cover song ID
• Possible modifications
• Replace feature extractor/classifier/indexer
• Run on a different collection
• Change experiment setup (corss validation, artist
  filtering etc.)

10
Storing/Retrieving results

• Results and features (in the NEMA file format)
  should be stored on the NEMA servers
• If features/results computed by a particular
  component on particular files/collections are
  requested, these need not be re-computed (just
  returned stored version)
• Can be retrieved from a NEMA webservice

11
What else?

• User interfaces for visualising data
• E.g. Sonic visualizer displaying a transcription
  or chroma vectors
• Consume NEMA file format
• Request NEMA files from the NEMA webservice (if
  they dont exist can be computed on the fly)