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 and is labelled as such in the report. I would rather say that plainly than round it up.

The numbers are public. The conformance 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. 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 (Version 3.2.0) [Computer software]. https://doi.org/10.5281/zenodo.21215280

BibTeX:

@software{requenaplens_phonometry,
  author  = {Requena Plens, Jose Manuel},
  title   = {phonometry: acoustic measurement toolkit for Python
             (formerly PyOctaveBand)},
  year    = {2026},
  version = {3.2.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.

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.