Reference
The guides show how to measure something. This section answers the questions that come after: why is the formula this one, is the implementation actually right, is the printed source itself right, what is this symbol and where does it come from. Nothing here is a tutorial, so nothing here has to be read in order; these are pages to arrive at from a guide, from a report you are writing, or from a reviewer’s question.
Use it when you are defending a result rather than producing one. If a colleague asks which clause of ISO 3382-1 the reverberation time follows, the theory pages say so; if a client asks for evidence that the library computes it correctly, the conformance report shows the standard’s own expected value next to the computed one; if a printed expected value disagrees with the library, the errata registry says which of the two is wrong and why; if a symbol in a report needs a name, the glossary has its unit and its defining clause; and if a journal asks for the source of a model, the bibliography has the DOI.
If you are only looking for the signature of a function, you want the API reference instead: it is generated from the source docstrings and lives in its own section of the sidebar.
What to carry into your report
Section titled “What to carry into your report”The evidence exists; this is which of it belongs in the document you hand over. Record the exact version of phonometry that produced the numbers, and its version DOI, because the conformance report is regenerated on every pull request and only the pinned version’s report is evidence about your run. Name the standard and clause each reported quantity implements; the theory pages and the glossary each give both. Attach or link the conformance rows for those quantities, since they carry the normative expected value beside the computed one. Check the errata registry for the standards you cite: where a printed defect changed the reading the library implements, that entry is what explains a difference from another implementation’s number. And read the “What this guide covers” block of each guide you used for the clauses that are not implemented, which is the part a reviewer asks about first.
The standards, the mathematics and the design decisions behind the modules whose derivations are long enough to lift out of the guide, in six domain pages: signal analysis, perception and hearing, rooms and buildings, materials and surfaces, environment and transport, and vibration. Start here when a guide states a result and you want the derivation, the clause it implements, or the reason one formulation was chosen over another.
These six are partitioned by physics rather than by the ten guide areas, so a few subjects sit where a reader may not expect them: sound power determination and occupational exposure are under Environment and transport, and sound intensity under Signal analysis, because each is the same propagation and spectral mathematics the pages around it develop. The underwater theory lives inline with its guides, and the aircraft, wave-simulation, electroacoustics and noise-control derivations stay inside the guides themselves, where the geometry that motivates them already is.
The numerical evidence. Every check names a standard, a clause or table, the normative expected value, the value the library computes, the delta and a pass/fail verdict. It is regenerated and enforced by CI on every pull request, so it describes the code as it is now rather than as it was documented once. Read it when you need to show that a number is defensible, or to see exactly which parts of a standard are implemented and which are not.
Two things about it are worth knowing before you open it. Not every row is a comparison against a number printed in a standard: some standards publish no worked example, and those checks are anchored to the closed form of the normative text and pinned with a case synthesized to a known result, which is weaker evidence and is described as such in the row. And not every non-passing mark is a defect: the filter gallery deliberately includes architectures that cannot meet the IEC 61260-1 mask by construction, Chebyshev I and elliptic because they trade it for passband ripple and Bessel for group delay, and those rows are verdicted “By design”. Judge a row by its margin against the applicable limit rather than by the size of the delta, because the limits widen where the standard knows they must.
The other side of the same coin. Re-deriving every formula and worked example from the source document occasionally shows that the document is wrong: an example that contradicts its own normative clause, a misprinted constant, a cross-reference pointing at the wrong equation. Each confirmed case is recorded with the printed edition, the evidence, the reading the library implements and the test that pins it. Read it when a printed expected value and the library disagree, before assuming the library is at fault.
A curated selection of the books and papers the guides lean on, in one list grouped by domain, each entry with a verified DOI or official publisher link, half a sentence on what it supports, and the guide pages that cite it. It is a reading list for the field rather than the complete citation index: the authoritative list for any one page is that page’s own References section, generated from its frontmatter.
The acoustic quantities the guides compute most often, each with its symbol, a one-sentence definition, its unit, the standard and clause that defines it, and the guide that implements it. Read it when a symbol in a formula needs a name, or a name needs the clause it came from. A quantity that is not listed is still defined where it is computed: every guide states its quantities before its code.
What this section does not cover
Section titled “What this section does not cover”It is not evidence about your measurement, only about the library. The conformance report says that the implementation reproduces each standard’s own expected value; it says nothing about your microphone, your room or your operator, and an accredited measurement needs a traceable calibration chain and a type-approved instrument that no software can supply.
It is not a substitute for the standards. Nothing here reproduces normative text: the theory pages cite clause, table and equation numbers so that you can read the document itself, which is what a reviewer will ask you to do.
It is not the API. Signatures, argument types and return values are generated from the docstrings into the API reference, which is a different section of the sidebar.
And it is not exhaustive. The theory pages cover the areas whose mathematics several guides share, and say plainly which areas keep their theory inline instead; the errata registry lists only the defects this project has confirmed against a printed page; and the bibliography lists the sources the library implements rather than the literature of the field.