Thinking back to a discussion on S/Pdiff errors .................
DanglingDiamonds_001_16Bit_441000_Rev001 for SPDIF testing
Here is a 5 min wav file I use for SPDIF testing.
This is a software-generated waveform, which is difficult to pass
through an audio chain unmolested unless no processing is applied. This
is precisely what you want when transferring via spdif from one machine
The diamonds are on a ½ scale pedestal which will not survive any low
end roll-off .
The diamonds are +/- pulses on alternating samples, which will not
survive (intact) high-end roll-off or sample rate conversions.
Whichever channel (left / right) is currently silent should show the
power meter dropping below 140 db (set up for a wide range meter in
audacity) and this will not happen unless all bits in the channel are zero.
The pulse blocks following the dangling diamonds should have flat tops
and bottoms, which align with full-scale, half-scale or (–) full-scale.
I used this waveform fed into a PC to discover that a working hardware
solution failed when the operating system was changed from XP to win7
and win10 (exact same hardware). Turns out win10 refused to allow 44100
on the spdif input and assumed all SPDIF was at 48Khz then force a
sample rate conversion.
The file is here as a wave file you can play from one machine to another
or alternatively burn to a CD and play from the coax out.
The file is also here zipped up (much smaller). Because so many of the
audio samples have the same value there is a high compression rate in a
zip or rar file.
To see how sensitive this waveform is to processing, you can try
applying equalization or sample rate conversion and witness how the
waveform goes downhill quickly.
This is much quicker than transferring data, saving it and doing a file