Document the settings that make a recording identical to what Spotify sent

[revtex]

Recording at 48 kHz from a stream that is 44.1 produces a file that looks completely healthy —
right format, right depth, plays perfectly — and whose top 2 kHz is empty, because Windows
resampled every track on the way through the virtual cable. Measured on a real recording: content
falls off a cliff at 22.05 kHz and is flat at the noise floor above it, with identical readings
for 22–23 kHz and 23–24 kHz.

That is one of four things on the path between Spotify and a finished recording that change the
audio by default, and not one of them is something Offstream can decide — they are settings in the
Sound control panel and in Spotify. So the README says which ones and why, instead of leaving
"lossless in, lossless out" as an assumption that happens to be false out of the box.

What the new section covers

What changes the audio	Set it to
The cable's sample rate, on both ends	44100 Hz — Spotify's lossless tier is 44.1, and mismatched ends make Windows convert between them
Bit depth	24-bit — Windows mixes in 32-bit float, so 24-bit integer is the largest depth that survives the trip unchanged; 32-bit and 16-bit are worse in opposite directions
Spotify's Normalize volume	Off — on by default, and it applies gain before the audio ever leaves Spotify
Volume, in four separate places	100% — any gain that is not exactly 1.0 makes the recording a scaled copy

Plus the two format facts that are not obvious from a picker where WAV and FLAC both read as
"lossless": FLAC is the only format here that can be exact. MP3, AAC and Opus re-encode by
definition, and Offstream's WAV profile is pcm_s16le, so WAV loses depth FLAC keeps.

A troubleshooting row points at the section from the symptom people will actually notice.

The check commands, and the one I threw away

Three commands. The middle one draws the spectrum rather than measuring a band, and that was a
correction, not a preference. The band measurement was written first and was wrong in the worst
possible way: highpass=f=22200 sits above Nyquist on a 44.1 kHz file, so ffmpeg rejects the
filter, passes the audio through unfiltered, and reports a healthy level — telling the reader that
their correctly configured recording had content above 22.2 kHz. It only failed on the files that
were right.

[Parsed_highpass_0] Invalid frequency and/or width!
[Parsed_volumedetect_2] max_volume: -21.1 dB      ← on a file with nothing up there at all

showspectrumpic cannot misfire, and where the audio stops is easier to read off a picture than
out of a decibel figure. Verified by generating both cases — a 44.1 kHz file and the same audio
resampled to 48 — and looking at the two spectrograms: the matched one fills the frame to the top
of its axis, the resampled one has a dead band above ~21.5 kHz with the axis running on to 22.8.

Verification

• All three documented commands run verbatim as written, on real output, in Windows PowerShell —
  including the backtick continuations.
• Docs only; no code changed, so no test run is meaningful here. CI still builds and runs both
  suites.