About

This page exists because a library that asks you to trust its numbers owes you the name of the person behind them, the method those numbers come from, and a way to tell me when one of them is wrong.

Who maintains phonometry

I am José Manuel Requena Plens. I wrote phonometry (originally released as PyOctaveBand) and I maintain it: the implementations, the test suite, this documentation site and the releases. There is no company behind it and no team, so if something on this site is wrong, it is mine to fix.

You can verify who I am through any of these:

• ORCID: 0000-0003-1250-6212
• Google Scholar: scholar.google.com/citations?user=9b0kPaUAAAAJ
• ResearchGate: Jose Requena Plens
• GitHub: @jmrplens
• Personal site: jmrp.io

The same identity is also published on MathWorks File Exchange, LinkedIn, Mastodon and Keyoxide, where the OpenPGP key that signs my work is listed.

My background is in acoustics and in signal processing, and it is on the record rather than self-described: I trained as a Telecommunications Engineer specialised in Sound and Image at the Universidad de Alicante (2011-2018), took the MSc in Acoustics Engineering at the Universitat Politècnica de València (2018-2019), and worked as an acoustics researcher at the UPV from 2020 to 2023, publishing there on acoustic metasurfaces, sound diffusers and acoustic field prediction; the papers are listed under the Google Scholar and ORCID profiles above. Today I work in industrial R&D as a firmware and software engineer.

The library grew out of the measurement side of that work: I kept needing octave-band levels and sound level meter quantities that I could defend against a tolerance table, so I built them once, properly, instead of re-deriving them for each project.

How I build the library

The method is the whole point of the project, and it is deliberately narrow:

1. I implement each metric from the text of its governing standard, clause by clause, rather than from a secondary description of it or from another implementation. When a formula is ambiguous, the ambiguity is resolved from the document itself or from the physics, and the reading I chose is written down.
2. I transcribe the standard’s own reference values into the test suite. Where a standard publishes a worked example, a tolerance table or a set of nominal responses (the IEC 61672-1 Table 3 weighting values, its Table 4 tone-burst responses, the IEC 61260-1 Table 1 filter limits, the ISO 226 Annex B contours, and so on), those numbers become the expected values of real tests.
3. CI enforces them on every change. A regression that moves a computed value outside the standard’s acceptance limit fails the build, so the claim cannot quietly stop being true between releases.

Not every standard publishes a numerical example. Where one does not, the implementation is anchored to the closed-form expressions in the normative text and pinned with a case synthesized to a known result, which is a weaker guarantee than a transcribed worked example. Those checks say so in the conformance report, in the expected-value cell itself rather than as a separate flag you could filter on: the phrase to look for is “closed form” or “analytic”. I would rather say that plainly than round it up, and I would rather you knew which kind of evidence you are holding: a closed-form check proves the implementation agrees with the equations as written and cannot catch a misreading of the clause those equations came from. That is why the errata registry exists beside it.

The numbers are public: that report lists, per check, the standard and clause, the normative expected value, the value the library actually computes, the delta and a pass or fail verdict; it is regenerated by CI on every pull request, so it cannot drift from the code. Why phonometry walks through the method on a single worked case (time weighting under IEC 61672-1:2013) if you want to see it applied end to end before trusting it in general.

Reporting an error

Please report it. A wrong number that nobody tells me about stays wrong.

Open an issue at github.com/jmrplens/phonometry/issues. The most useful report gives me the standard and clause you are checking against, the expected value, the value phonometry produced, and a short snippet that reproduces it. If you cannot share the signal, the parameters alone are usually enough for me to rebuild a case.

If an issue tracker is not an option for you, write to me directly at mail@jmrp.io; the issue is still the better channel, because the report and the fix stay public next to the code they concern.

That includes errors you find in the standards themselves. Re-deriving formulas and recomputing worked examples from the source documents occasionally turns up defects in the sources: misprints, worked examples that contradict their own normative clauses, ambiguous wording. I do not silently work around those. Each confirmed case is recorded in the errata registry with the location, the evidence, the reading the library implements, and whether it has been reported to the issuing body. It is maintained as docs/ERRATA.md in the repository and transplanted into the site at build time, so the two cannot disagree. The registry covers standards (ISO, IEC, EN), guidance documents and technical reports, textbooks and journal papers alike. If you disagree with one of those readings, that is exactly the kind of issue I want to receive.

Cite this software

If phonometry contributed to published work, please cite it. The archived record and its DOI are on Zenodo:

doi.org/10.5281/zenodo.21215280

That is the concept DOI: it always resolves to the most recent archived release, and each release also has its own version DOI on the same record. Cite the version you actually ran.

APA:

Requena-Plens, J. M. (2026). phonometry: acoustic measurement toolkit for Python (formerly PyOctaveBand) (Version 3.3.0) [Computer software]. https://doi.org/10.5281/zenodo.21215280

BibTeX:

@software{requenaplens_phonometry,
  author  = {Requena-Plens, Jos{\'e} M.},
  title   = {phonometry: acoustic measurement toolkit for Python
             (formerly PyOctaveBand)},
  year    = {2026},
  version = {3.3.0},
  doi     = {10.5281/zenodo.21215280},
  url     = {https://jmrplens.github.io/phonometry/},
  license = {MIT}
}

Both entries are derived from CITATION.cff in the repository, which is the authoritative metadata and the file GitHub and Zenodo read. If you use a reference manager, import that file rather than copying the block above, and adjust the version and year to the release you used.

Licence

phonometry is released under the MIT licence, so you can use it in commercial and academic work, modify it and redistribute it, as long as the copyright notice and the licence text travel with it. The software is provided without warranty: it is verified against the standards it implements, as described above, but it is not a calibrated instrument and it carries no accreditation. Deciding whether a result is fit for your purpose remains yours.

Concretely, for the laboratories and consultancies this is mostly written for: the library computes and documents, it does not measure, so traceability stays with the hardware chain — a calibrator and a microphone with valid certificates, and type-approved instrumentation wherever the measurement has legal effect. Accreditation bodies expect calculation software to be validated for its intended use, with the record retained, and the artefact for that is the conformance report of the exact version that ran: pin the version, archive its report with the measurement data, and keep the errata registry alongside, since it documents every place where the implemented reading differs from a printed source. And the uncertainty machinery propagates what you give it: the calibrator tolerance and the pre/post drift are still yours to enter.

The standards themselves are copyrighted by their issuing bodies and are not redistributed here. This documentation cites clauses and reference values as needed to explain and verify the implementations; it is not a substitute for buying the documents.

Where to go from here

If you have read this far and want to start using it, Getting Started installs the library and runs a first calibrated analysis, What do you need to measure? finds the page for a particular job, and All guides is the map of the whole library grouped by topic. If you arrived to check a number rather than to install anything, the conformance report and the errata registry are the two pages that answer that.