Frequently asked questions
Which code should I use for a psychoacoustic metric?
Choose by your own environment first: the language you work in and how the results will be used. The Languages page shows which metrics can be computed from each language and how each project can be called, also from another language. The Metrics page names the current edition of each of the 22 metrics, and each metric page lists every implementation of it, with the validation it states, the code it was ported from and the choices that change its numbers. Those widely used projects, SQAT (MATLAB) and MoSQITo (Python), come first in the lists, together with sottek-hearing-model (Python), a very good implementation, but they are not the only choice. Newer projects, not yet seen to be widely used, often check their results against MoSQITo or SQAT (9 of the 12 newly released ones do), and some are built for a particular use: MetaSona is a C library written for fast, real-time analysis, with a rolling analyser for audio that arrives in chunks; iso532-1-rs is a Rust engine with a streaming interface and a C interface; torch_amt brings the AMT loudness models to PyTorch, differentiable and able to run on GPU. pySQAT ports SQAT v1.3 to Python and checks each metric against that version; the graphical interface that SQAT added in v2.0 follows the layout of pySQAT's interface. Before relying on any of them, check the validation each project states and whether the fix you need is in a release or only on its main branch.
Which metrics can I compute in Python, MATLAB or C?
Metrics whose current edition has a released open-source implementation, by language: Python: 19 of 22 (8 only from newly released projects); MATLAB/Octave: 12 of 22; C/C++: 7 of 22 (7 only from newly released projects); Rust: 2 of 22 (2 only from newly released projects); Julia: 5 of 22 (5 only from newly released projects). The Languages page lists them, and explains how each project can be used from another language, for example a MATLAB toolbox from Python through the MATLAB Engine API.
Why does it matter which edition a tool implements?
Psychoacoustic standards change between editions. ECMA-418-2, for example, has had four editions since 2020 that changed the hearing model, roughness and loudness, and all three parts of ISO 532 are being revised. Two tools that both claim to implement a standard can therefore give different values for the same sound. Liu et al. (2026, Acoustics Australia, doi:10.1007/s40857-026-00393-3) compared four tools and found differences large enough to change the predictions of sound-quality models. Each metric page lists the editions and which tool follows which.
Which metrics have no open-source implementation yet?
No available open-source implementation of the current edition was found for Roughness, DIN 38455, Tonal components and tone adjustment (DIN 45681), and Audibility of tones in noise (ISO/TS 20065). The current editions of Moore–Glasberg loudness of stationary sounds (ISO 532-2, ANSI S3.4), Fluctuation strength from the Sottek Hearing Model (ECMA-418-2), Tone-to-noise ratio and prominence ratio (ECMA-418-1), Tonal audibility in environmental noise (ISO 1996-2), Tonal audibility of wind turbine noise (IEC 61400-11), Prominence of impulsive sounds (ISO/PAS 1996-3, NT ACOU 112), and Equal-loudness-level contours (ISO 226) have released implementations only from newly released projects, not yet seen to be widely used.
What do established, newly released, developing and legacy mean?
Every project is in one group. Established: Described in a publication, used by others, or written by the authors of the model, with more than a year of history. Newly released: First released less than about a year ago, and not yet seen to be widely used in the community. Developing: Public for more than a year, but without a publication or documented use by others: research, teaching or personal code. Legacy: Archived, or no commit for three years or more. Kept for reference. The code may follow an older edition and may not run with current software. Others: Tools that do not compute the metrics themselves: interfaces, front ends and wrappers that call one of the listed projects. Status unknown: Projects whose code could not be opened, for example because the repository needs a login. What they implement is unverified, so they are listed with what they claim and not under the metrics. Lists follow this order, so a project that is new, little used, no longer maintained or unverified is never suggested first. SQAT and MoSQITo (widely used), and sottek-hearing-model (a very good implementation) come first in every list, in bold, and they and the reference programs published with a standard are never listed as legacy. Newly released projects: MetaSona (First released in September 2026), ecma418-torch (First published on GitHub on 2026-10-11 (version 0.1.0 in its metadata); no release or PyPI package yet), iso532-1-rs (First version tagged in July 2026), Kirin Hypha (First public commit in April 2026; v1.0.0 was released in May 2026), Mosqito.NET (First published on GitHub in April 2026), NumpyLibforPsychoAcoustic (First published on GitHub in November 2025), phonometry (Its psychoacoustics module was first released in July 2026 (version 3.1.0)), PsychoacousticMetrics.jl (First registered in July 2026), rota-order (First released in October 2026; the README calls it pre-alpha), SoundPalette (Its psychoacoustic metrics were added in July 2026 (v0.5.0)), torch_amt (First released in February 2026), and ZwickerLoudness.jl (First registered in February 2026). Legacy projects: deeuu/loudness (last commit 2019-08), fluctuation-strength-TUe (last commit 2020-01), HAW loudness tool (last commit 2022-12), IoSR Matlab Toolbox (last commit 2017-08), MoSQITo-FDP (archived), PsychoacousticParametersMeasurer (last commit 2021-06), PsySound3 (last commit 2015-03), python-acoustics (archived), SUAVE (last commit 2022-12), Swift & Gee codes (last commit 2020-01), Zhen-Ni/epnl (last commit 2023-07), and zwickerloudness (last commit 2018-06). All groups are on the Projects page.
How are the entries checked?
From each project's own README, documentation, release notes, licence file and package metadata, with links to those sources. The list records what a project claims and does not run the code. Repository and package metadata are refreshed monthly, and a person reviews new findings.
Can I rely on a listed implementation in a report that an authority will check?
Being listed here is not a certification or an approval: LISQM records what each project states and has not run the code. For a report that an authority, a certification body or a client will check, use the edition and method that the regulation or contract names, check the implementation yourself with the test signals or reference data of that edition where it gives them, and state the version or commit you used. Each metric page lists the editions and what each project says about its validation.