Bit-Perfect Checker

What it is

Bit-Perfect Checker proves whether a playback chain delivers a file bit-perfect, with every sample unchanged. The chain is the player, the operating system and its USB audio stack.

It has two parts: the BPC1 test files, and a USB audio device that checks every sample it receives. To the host, the device is an ordinary USB audio output, like a DAC. You play a test file to it with any player on any operating system that supports USB Audio Class 2, and the device gives a verdict per file.

A pass proves that every sample arrived unchanged. A fail almost always means a real change; rarely, a USB packet the device missed fails a file the host sent intact. It does not say what changed when a file did not.

Never play these files on speakers or headphones

The test files contain full-scale bursts. The sweep files are full-scale noise for their whole length. On speakers or headphones they are loud, and they can damage equipment and hearing. Play them only into the checker.

Downloads

The first release is not published yet; these links work once it is.

The test files come in four formats, one zip each. Start with WAV. A player can decode each format through a different path, so a file that passes as WAV may still fail as FLAC, AIFF or ALAC: test every format you play.

Each zip holds the PCM files at 16 and 24 bits at all ten rates from 44.1 to 768 kHz, DSD64 to DSD256 as DoP, and a folder negative/ with deliberately faulty files that must not check as bit-perfect. Each zip also has a README.txt and a SHA256SUMS of its audio files.

bpc1-v1.0-wav.zip about 402 MB
PCM WAV and DSD: DSF, DFF and DoP in WAV. Only this zip has DSF and DFF. The device takes PCM only, so play DSF and DFF files with the player’s DoP output. If a FLAC, AIFF or ALAC file does not play, the WAV file of the same name holds the same samples.
bpc1-v1.0-flac.zip about 311 MB
FLAC. The files at 705.6 and 768 kHz need a decoder based on libFLAC 1.4.0 or later, and may not play in older players.
bpc1-v1.0-aiff.zip about 495 MB
AIFF, for Apple devices.
bpc1-v1.0-alac.zip about 326 MB
ALAC (Apple Lossless, .m4a), for Apple devices: the Music app takes ALAC. A player that cannot decode ALAC at the highest rates may refuse those files.

Code-sweep files, optional

The regular files test the paths of a player and a device with a low-level payload. The sweep files carry every sample code of 16 and 24 bits at full scale, and prove that every code arrives unchanged. Play them like the regular files.

They are full-scale noise for their whole length, the 24-bit ones for up to 7 minutes. Never play them on speakers or headphones.

Checksums

SHA256SUMS lists the SHA-256 of every zip. All releases are on the releases page.

How to play

Connect the device to the host you want to test (see The device).
Select “Bit-Perfect Checker” as the audio output.
Set the player to bit-perfect output: exclusive mode, no volume control, no EQ and no resampling. Turn off ReplayGain, Sound Check, volume normalization, limiters and “prevent clipping” options. They change the samples, and the file fails.
Press the user button B1 on the board to start a new run.
Play the files, one after another or as a playlist.
Read the result on the LEDs.

The files reach full scale. A player or tool that measures levels may show clipping or peaks at 0 dBFS. That is expected, and harmless when the player passes the samples unchanged.

What the LEDs mean

Blue shows the USB connection and the stream.

Blue, fast blink: no host has set up the device yet.
Blue, slow blink: a host has set it up; waiting for a stream.
Blue, steady: a stream is playing.

Green and red show the whole run since B1 was pressed or the board was reset.

Red, steady: a file is NOT_BIT_PERFECT. The file was found, but it did not arrive bit-perfect.
Red, blinking: there is an UNKNOWN_SIGNAL result. Audio arrived that belongs to no test file, silence included. Resampling, dither, rounding or inversion can also turn a test file into an unknown signal.
Red and green blinking together: there is a DEVICE_OVERRUN result. The device could not judge a file. Play it again.
Green: every result is BIT_PERFECT.
Green and red off: nothing judged yet.

When several apply, the first in this list shows. All three LEDs on means that the firmware stopped on a fault.

Only BIT_PERFECT is a pass. Green cannot show that every file arrived, because a file that does not arrive gives no result: compare the number of BIT_PERFECT results in the serial log with the files you played (bpcport run --expect does this).

The serial log

The device also writes one result line per file: the verdict, the file’s kind, rate and depth, and the received rate, slot and bits in use. To read it, open the ST-LINK’s virtual COM port at 115200 8N1, or use bpcport.

If a run shows red blinking and the log’s stream stop line shows outside= above 0 with only silence around the files, the host pads its streams with silence. The allow_silence setting accepts silence outside the files. With it on, a file muted to silence gives no result.

Long runs

To find rare faults, play the files one after another continuously, for hours if needed. Or loop one file gaplessly, so that it arrives as one continuous stream. Every repetition gets its own result.

The device

Today the device is an STM32 NUCLEO-U5A5ZJ-Q development board with the project’s firmware. It has two USB ports. Connect both: the ST-LINK USB port gives power and the serial log, and the user USB-C port goes to the host under test.

There is no ready-made firmware binary yet. Build the firmware from source and flash it, as the firmware README describes. A ready-made binary will follow.

The bit-perfect-checker repository on GitHub: the generator, the reference software checker and the firmware.
The BPC1 signal format, the specification of the test files.
bpcport, the client for test automation. python3 -m bpcport run plays a file, reads the results from the serial log and sets its exit status by the verdicts. python3 -m bpcport monitor shows the log.