Suppose you compare two versions of the same recording. One is the original; the other has been compressed into a smaller audio file. You think you can hear a difference, so you try a blind test. You identify the version correctly ten times out of sixteen.
That is better than half. Is it enough to show that you heard something?
This is an illustrative result, not a listening session anyone has reported. Under a simple guessing model, a score of ten or more out of sixteen occurs about 23% of the time. A result that looks encouraging can still be fairly ordinary for someone choosing without an audible clue.
The score needs a reference point. That is where an ABX test and a little probability become useful.
In an ABX comparison, A and B are two reference signals. X is one of those signals, selected at random and presented without revealing its identity. You can listen to the references and X, then decide whether X matches A or B. The process repeats with a newly assigned X. ABX procedure
The question is specific: can you identify which reference you are hearing?
It is different from asking which version you prefer. You could reliably identify a difference without preferring either version. You could also have a strong preference when the identities are visible but fail to identify the versions when they are hidden. The test does not ask you to defend that preference. It asks you to perform a matching task.
Nor does a file comparison, by itself, compare two pairs of headphones. Both files ordinarily travel through the same playback equipment. The claim being tested should describe what actually changed.
For the calculation, assume sixteen trials chosen in advance. X is assigned independently on every trial, with equal chances of being A or B. Under the guessing model, each answer has a one-half chance of being correct, and the listener receives no information that predicts X.
There are 65,536 possible sequences of correct and incorrect answers: two possibilities multiplied together sixteen times. Under these assumptions, they are equally likely.
Only one sequence gets every answer right. Many sequences get ten right. To evaluate a score of ten, we count all sequences with ten, eleven, twelve, thirteen, fourteen, fifteen, or sixteen correct answers. That asks how often guessing would produce this score or a better one.
The calculation uses the binomial distribution, which describes counts of successes across independent trials with a fixed success probability. Binomial model
| Illustrative score | Chance of this score or better under the guessing model |
|---|---|
| 10 out of 16 | 22.72% |
| 12 out of 16 | 3.84% |
| 13 out of 16 | 1.06% |
These are calculated probabilities, not results from a study. The total number of qualifying sequences for thirteen or more correct is 697. Dividing 697 by 65,536 gives approximately 0.0106, or 1.06%.
That percentage is not the probability that you were guessing. It describes how unusual the result would be if the guessing model applied. It also does not certify that the test was fair. A revealing click or timing difference could help someone identify X without hearing the feature they intended to compare.
Imagine that version B begins with a small delay. If A starts immediately and B does not, identifying the delay could produce an excellent score. It would not establish that the listener heard a compression artifact in the music.
This is another hypothetical example. It illustrates why a test needs controls as well as a hidden label. If the intended question concerns compression, the files should come from the same source recording and contain the same passage, with their beginnings aligned. Differences in editing, channel layout, or gain can create additional clues.
Formal audio-assessment guidance treats listening conditions, reference material, familiarisation, and level control as parts of the method. ITU-R BS.1116 uses a different assessment procedure from ABX, but it makes the broader point clearly: a listening result depends on how the comparison was constructed. ITU assessment guidance
For a personal test, write down what A and B contain before beginning. Keep the output device, software processing, and volume unchanged. If you are investigating a particular artifact, identify the passage where you expect to hear it during practice rather than searching for a new explanation after each scored trial.
Want to see how your own score compares with the table? Prepare two aligned versions of the same short recording, then try a sixteen-trial blind comparison on WaveLocus. Load the files as A and B, listen to the references, and decide which one matches X on each trial. Keep the completed score, including a result near chance, and use the table above to interpret it.
Before starting, check the level-matching option. RMS means root mean square. For audio samples, it is a measure related to their average squared amplitude. WaveLocus describes its matching as attenuating the file with the higher RMS value. That is a digital-level adjustment, not a guarantee that the two files sound equally loud. Its previews start at sample zero, but the files are not otherwise time-aligned. Remove any unequal leading silence during file preparation.
Those limits matter whichever tool you use. Check its method before treating the score as evidence. A desktop comparator is another option; foobar2000 provides an ABX component for comparing two tracks. foobar2000 ABX component
The probability table describes one planned session. It does not describe a collection of sessions from which only the best result is reported.
Suppose a hypothetical listener runs twenty independent sixteen-trial sessions while guessing. In each session, the chance of thirteen or more correct is approximately 1.06%. Across all twenty, the chance of getting at least one such score is about 19.3%.
We obtain that by calculating the chance that none of the twenty sessions reaches the score, then subtracting it from one. This assumes independent sessions under the same guessing model. It shows why the best-looking attempt can be misleading when the earlier attempts disappear.
Practising is reasonable. Keep practice separate from the scored session. Choose the number of trials beforehand, complete them, and retain the result. If you stop because you are uncomfortable or tired, record that the session was incomplete. Start at a comfortable, low volume; turning it up is not a substitute for a clearer test question.
A strong result from a well-controlled comparison supports a narrow statement: this listener distinguished these signals under these conditions. It does not establish that one version is better, that everyone can hear the difference, or that an upgrade is worth its price.
A result near chance also leaves questions open. The distinction might be too small for this passage, this setup, or this session. Failing to demonstrate it does not prove that the files are identical or say anything clinical about the listener’s hearing.
For an informative report, keep the score beside the file preparation, passage, equipment, level treatment, and planned trial count. Those details let someone judge what you actually tested. Sixteen answers are much more useful when the question they answered is clear.
]]>White noise is described as having equal power across frequency. That sounds like a recipe for balance. So why can it sound like a bright hiss, while pink noise has less of that sharp edge?
The missing detail is the size of the frequency interval being compared. White noise distributes power equally across equal-width frequency bands. Pink noise distributes power equally across octaves. Those are different definitions of equal. Noise definitions
We can see the difference with two frequency ranges and a small calculation.
Frequency measures how many cycles occur each second. Its unit is hertz, abbreviated Hz. An octave spans a doubling of frequency: 100 to 200 Hz is one octave, as is 1,000 to 2,000 Hz. Octave analysis
Their widths, however, are different:
| Frequency range | Frequency ratio | Width |
|---|---|---|
| 100–200 Hz | 2:1 | 100 Hz |
| 1,000–2,000 Hz | 2:1 | 1,000 Hz |
The second band is ten times wider. Both are octaves because an octave describes a ratio, not a fixed number of hertz.
To calculate white-noise power in these bands, use an illustrative model. Assume an ideal signal with a constant power density throughout both ranges. Assign it one arbitrary unit of power per hertz. These are teaching units, not measurements from a recording or speaker.
The 100–200 Hz band then contains 100 power units. The 1,000–2,000 Hz band contains 1,000. The wider band receives ten times as much power simply because it contains ten times as much frequency width.
The chosen density changes the numbers, but not the ratio. At two units per hertz, the totals would be 200 and 2,000. At half a unit, they would be 50 and 500.
This gives white noise more power in higher octave bands. It does not tell us that the second band sounds ten times louder. The calculation describes signal power, not a listener’s loudness judgment.
Pink noise reduces power density as frequency increases. In the ideal model, its density is proportional to one divided by frequency. At twice the frequency, the density is half as large. Across an octave, that reduction compensates for the increasing band width. The result is equal power per octave. Pink-noise spectrum
For a simple illustration, suppose an ideal pink-noise signal contains 100 arbitrary power units between 100 and 200 Hz. It would also contain 100 between 200 and 400 Hz, and 100 between 1,000 and 2,000 Hz, provided all those bands lie within its operating range.
White noise would not maintain those equal octave totals. Starting at 100 units in the first band, its next octave would contain 200, because 200–400 Hz is twice as wide.
These examples explain the spectral difference behind the opening question. Relative to its lower octaves, white noise puts more power into higher octaves. Pink noise does not have that increasing octave-power pattern. That makes a brighter, more hiss-like character for white noise a reasonable expectation, rather than a contradiction of its definition. White and pink octave spectra
The expectation is not a promise about what every listener will hear. The calculation alone cannot account for the playback equipment or establish perceived loudness.
A spectrum needs a definition of what its vertical axis measures.
A power-density graph reports power per unit of frequency. White noise is flat in that representation. An octave-band graph adds the power within each octave. Pink noise is flat in that representation, while white noise rises toward higher octave bands. MathWorks demonstrates both views using generated noise. Spectrum comparison
Changing the frequency axis to a logarithmic scale is not, by itself, the same operation as adding power within octave bands. To interpret a plot, check whether it shows power density or total band power.
The question “Which noise has a flat spectrum?” therefore needs a second question: flat according to which measurement?
How does the difference sound through your headphones or speakers? Compare white and pink noise on WaveLocus using the short exercise below. Listen for a change in the hiss or tonal balance, then describe what you actually hear. A subtle difference, or no clear difference, is worth recording too.
Keep playback quiet and stop if it is uncomfortable. Loudness and exposure duration both matter for hearing risk. CDC guidance
This is an informal listening exercise. The same digital-level setting does not establish equal perceived loudness, and it is not a calibrated sound-pressure reading. Keeping a seed also does not make different noise colors identical signals. Record a possible level difference separately from a difference in tonal character.
The exercise can help you connect a spectral definition to an audible difference in your setup. It cannot establish that one noise type is universally more pleasant or that your equipment has an accurate frequency response.
For this question, the useful habit is to make “equal” precise. Equal-width bands and equal-ratio bands ask different things of a signal. Once that distinction is visible, the contrast between white and pink noise becomes something we can calculate and investigate, rather than a collection of color names to memorise.
]]>A microphone test website may pick up your voice even when your meeting app doesn’t. Each can use a different microphone or have different microphone permissions. The test page asks your browser for microphone access and draws a wave or bar when sound arrives. Your meeting app maintains its own device selection and permissions. A passing test site, therefore, can’t confirm that the app is using the same microphone.
Zoom desktop app. Open Settings, then Audio. Click Test speaker to hear a tone. Click Test microphone to record your voice and hear it played back. An input-level bar moves when Zoom picks up sound. Zoom also offers a test meeting.
Google Meet. On the pre-join screen, the mic, speaker and camera each have a dropdown. Click the microphone and speak, and Google says a moving bar means the mic works. Click the speaker, then Test speakers, to hear a test sound.
Two practical points:
If your meeting app doesn’t pick up your voice, run a browser-based microphone test, such as WaveLocus’s microphone test or OnlineMicTest. You only need one. Allow microphone access, then speak at your normal distance from the microphone. Look for a line or bar that changes as you speak. If the test lets you choose a microphone, select the same one you chose in your meeting app. A response shows that the browser is receiving sound; it doesn’t confirm that the meeting app is receiving it or that your voice sounds clear.
These microphone and speaker checks don’t show what another participant will hear during a real call. Your connection, the meeting app’s audio processing, and the other person’s speakers or headphones can affect the result. A short test call with another person gives you a better check of the full conversation, though it cannot guarantee every future call will sound the same.
Sources: Zoom: Testing your audio settings · Google Meet: Before a meeting · MDN: getUserMedia() · OnlineMicTest
]]>