#Plugins sonic visualiser manual
Because RDF about audio can link to the original audio file location and also provide audio recording metadata, the Sonic Visualiser user can export an entire session to an RDF document complete with automatic and manual annotations, audio location, and metadata. Sonic Visualiser can import RDF descriptions of audio features, and also load both audio and annotation data from non-local HTTP URLs as well as from local storage. (Indeed, Sonic Visualiser is actually a set of modular libraries for building visualisation and analysis applications as well as an application in its own right Sonic Annotator is a simpler application of the same libraries.) This provides quite a lot of power. During OMRAS2 we added the ability to query Vamp plugin metadata (section 4.2 below) and to import and export annotation data using the Audio Features ontology, providing compatibility in both plugin and data formats with Sonic Annotator. Sonic Visualiser uses the Vamp plugin format (section 3.1) for automated analysis. Sonic Visualiser is written in C++ using the Qt toolkit, with RDF handled using Redland 22 libraries. Development began prior to the start of the OMRAS2 project as a means to assist researchers by providing a flexible visualisation tool and a platform for testing and dissemination of implementations of audio feature extraction methods. It can display one or more audio files in waveform or spectral views, perform automated analysis using Vamp plugins (section 3.1), and import, export, and edit annotations such as point timings (for events like beats), notes, measure- ment curves, and so on while Sonic Annotator (discussed in section 3.2) is a tool for batch analysis of audio collections, Sonic Visualiser is an interactive tool, allowing the addition and display of annotations from human subjects alongside or on top of the audio and automated analysis. Sonic Visualiser (figure 3) is an application for visualisation, annotation, and automated analysis of audio recordings. Development of the Opaque Feature File ontology is incomplete at the time of writing, but this or a similar system will be a valuable foundation for work using a mixture of RDF description with more compact data formats.
This work aims to provide a common mechanism for describing in RDF the location and context of data files that are not in RDF, typically the results of some extraction or transformation process on audio data this would allow the dense numerical data to be represented separately from the rest, while still remaining fully linked, thus restor- ing human-readability to the rest of the data and allowing storage of the numerical data in a more compact form. The Opaque Feature File project 20 represents one attempt to improve representation of dense data. Although there is no effective way to represent large quanti- ties of numerical data directly in RDF, for many applications the textual representation in Listing 5 is adequate, with the major penalties being disk space requirements and the loss of human-readability. This represents the “dark side” of the often advantageous situation of expressing data and metadata in the same format. In practice this would be prohibitively costly even by the standards of the earlier examples, requiring two statements for every value. An improvement in principle might be to use an RDF collection 19 to express a sequence of typed numerical values. The only potential advantage of this encoding is that it keeps the data and information about its provenance together in a single document. Other information that is normally useful when handling numerical data is also miss- ing, such as the floating point precision. the af:value literal has no useful RDF type and is effectively opaque: no generic timeline-mapping or visualisation application, for example, would be able to use it without further information about its format. Fragment of the output from Sonic Annotator of a spectrogram. Despite its length, this example fails to convey any of the useful “self-describing” information found in the earlier note example. Listing 5 shows the start of an output feature from a spectrogram plugin.
In this case the problem cannot be avoided in the ontology.) There is no very effective way to represent numerical data in quantity directly in RDF a textual representation of a large sequence of numbers is overwhelming for humans to absorb and inefficient for computers to parse, transmit and store. (It is also possible to attach a language tag to textual literals, with equally awkward consequences: is not the same literal as "note", and SPARQL provides no way to match a literal but ignore its language. to ensure that types are enforced manually.
0 kommentar(er)
