Audio sounds worse than before? Compare it to a known-good baseline

When audio sounds worse than before, memory is a weak measurement tool. “Worse” might mean quieter, thinner, distorted, mono, delayed, noisy, or simply different. Before changing settings, create a short reference that can be repeated. A baseline will not diagnose the cause on its own. It gives you a known starting condition, so the next comparison can rule something out.

Define the change before you test

Write one plain sentence about what changed. For example: “The same headphones now sound quieter in the browser,” or “the left channel disappears only through the USB interface.” Avoid a broad statement such as “my audio is bad.” It combines too many possible observations and makes it hard to decide what to hold constant.

Also record when you first noticed it and what changed near that time. That might be a new cable, an operating-system update, browser update, different port, wireless connection, or application setting. These are leads, not conclusions. The change may be related, or it may only have happened around the same time. The baseline exists to test one lead safely instead of treating timing as proof.

Build a simple known-good reference

For an ordinary listening path, your baseline is a documented local reference. Choose one short WaveLocus test that matches the complaint. Use the left/right audio test for a channel concern, the speaker test for general playback, or the frequency sweep when an audible change repeats in a particular part of the range. Use a comfortable low physical volume.

Record the complete path: source device, browser and version if available, output selected by the system, connection type, endpoint, optional adapter or interface, test used, dBFS setting when shown, and system volume position. If the test is about a headset during microphone use, include whether capture was active. This is not paperwork for its own sake. It stops a later comparison from silently changing the browser, endpoint, cable, and level at the same time.

Make one controlled before-and-after comparison

1. Run the reference once in the current path. Note the result in specific terms: centered or shifted, clean or distorted, stable or interrupted, and which side or range is affected.
2. Hold the reference still. Keep the same source device, browser, test, dBFS setting, output volume, and listening position. Do not compensate for the issue by changing several controls.
3. Change one available variable. If a second browser, output port, cable, wired endpoint, or safe adapter is already available, change one item. Do not buy hardware or use improvised wiring just to complete this step.
4. Run the identical reference again. A clean and failing pair is much more informative than several unrecorded experiments. State exactly what remained fixed and what changed.
5. Preserve the narrow result. “The same left/right reference fails through the dock but passes directly” is useful. “The dock is broken” is not yet supported.

Use the right kind of baseline

WaveLocus's audio baseline page saves numeric baselines only for eligible electrical-loopback measurements. It keeps the measurement and context in the browser. The comparison warns when reported input settings, sample rate, or method version differ, and it treats small changes within a stated measurement floor as not significant. It does not save a general “how this song sounded” score for every headphone or speaker path. For those paths, use the documented listening reference above.

Do not let a baseline become a false diagnosis

If the exact same reference changes when only one connection element changes, the difference is evidence about that comparison. It does not establish the component's internal fault. A dock may change routing, an interface may expose a different sample-rate path, a browser profile may differ, or an endpoint may have its own setting. A second controlled comparison can narrow the result further. Randomly reinstalling drivers, resetting every audio preference, or changing every cable at once destroys the useful evidence you just collected.

For electrical measurements, match the method before comparing numbers. WaveLocus withholds or labels values when the return is unsupported, the reported conditions differ, or a change is below the configured measurement floor. That restraint is deliberate. A small numeric delta does not automatically mean you will hear a difference, and an audible difference does not automatically identify a measured electrical cause.

Separate playback, capture, and room changes

A baseline for playback does not verify microphone capture. If starting a microphone changes a headset's sound, use the headset test and compare before capture with during capture. If a browser microphone is silent, use the microphone test separately. If speakers sound different after you move them or change rooms, the listening environment has changed too. A browser reference can document that you heard a change, but it cannot establish a calibrated room measurement.

Likewise, do not treat a fixed browser dBFS setting as a physical level baseline. It holds the generated digital source at the stated reference. Output volume, endpoint sensitivity, fit, distance, and room still affect the sound you hear. Read dBFS versus dB SPL before assigning a physical loudness number to a browser test.

When to stop and use another method

Stop if the sound is uncomfortable, distorted at a risky level, or the connection requires unfamiliar wiring. Do not connect output to input for loopback unless you understand the input level and any required attenuation. A browser baseline is not a hearing assessment, a safety certification, or a repair diagnosis. If a device is damaged, hot, or unstable, use the manufacturer's documented support path instead of continuing to test it.

Next step

Keep the best clean and failing pair, including the exact reference and one changed variable. Then open guided diagnosis to continue from that evidence. A good baseline does not need to prove everything. It only needs to make the next decision clearer.

Sources and method

This guide uses WaveLocus's local references, controlled swaps, and its eligibility-led electrical baseline workflow. The baseline method page explains the local storage and comparison limits, while the electrical loopback protocol defines the repeatable return-path method. MDN's IndexedDB API reference describes the browser storage mechanism used for local persisted data. The guide does not claim that a listening baseline identifies a hardware defect, calibrates loudness, or makes unlike measurement methods comparable.