BitPerfect: PCM Bit-Perfect Tester

[bronan]

When archiving laserdiscs, we want to make sure we're copying exactly what is on the disc and not modifying it in any way. This cross-platform app is meant to help verify that your capture chain is setup correctly for "bit perfect" digital audio captures.

A bin/cue is included to burn to a CD, which is recorded through your capture setup. BitPerfect is then used to compare your recording to the reference and see if the samples in the stream are the same. There is also a noise generator included if you'd like a longer or shorter reference WAV, or you can just rip one of your music CDs and use a song. Just replace the reference.wav in the root directory with what you'd like to check against and you're ready to go.

Features:

- Easily test whether a digital recording is Bit Perfect or if 2 audio files are the same
- Snapshot feature analyzes WAV, FLAC, or RF64 (1.0 to 7.1 channels) for RMS, EBU R128 Loudness and Dynamic Range, Dual Mono, and 24-bit padding
- Noise Generator

https://i.imgur.com/MBa4iwz.png

Step 1: Burn the bin/cue to a CD-R (ImgBurn recommended)
Step 2: Play the CD-R on your LD player and record it through your capture setup. Leave a couple seconds of silence on either side of the recording when you export to ensure nothing is cut off (extra data before and after will not affect the test).
Step 3: Use the Tester to compare your recording with the reference WAV.

DOWNLOAD - Version 2.6

WIN - https://drive.google.com/file/d/1tow6bWf...sp=sharing
MAC - https://drive.google.com/file/d/18I65A7r...sp=sharing
LINUX - https://drive.google.com/file/d/1jTF021r...sp=sharing

TEST CD - https://drive.google.com/file/d/122cEchS...sp=sharing

CHANGE-LOG
2.6 - Fixed Dialog & Message boxes, many small tweaks and styling fixes, first cross-platform build since 2.0
2.5 - Updated from .NET 5.0 to 8.0, updated UI to Avalonia 11
2.4 - Added Spectrogram markers/labels, various graphing tweaks
2.3 - Fixed Snapshot opening some Mono files with channel flagged as Center instead of Left, fixed opening some RF64 files, increased Inspector textbox size
2.2 - Added Snapshot Inspector to view .snaps, changed RMS to calculate for entire signal instead of per channel, more optimizations and cleanup
2.1 - Added FLAC support, added Snapshots, added surround sound support, fixed Extensible Wave reading, added EBU R128 meter for Loudness and Dynamic Range, rewrote dual mono check to work on analog sources, speed ups for sample reading, added peak/RMS/avg sample for channels
2.0 - Ported to Avalonia for cross-platform support. Rewrote testing logic to calculate sample values for matching. Added Stream From Disk and 24-bit matching support
1.4 - Added ability to ignore a percentage of the beginning and end when matching, extra info on completion messages
1.3 - Added pre-made reference CD, moved noise generator to separate tab
1.2 - Added dual mono check
1.1 - Fixed WAV header parsing, expanded noise generator settings
1.0 - Refactoring and memory optimizations, option to verify WAV headers match
0.9 - Initial release

[bronan]

I'm going to be adding another test CD with a setup check I found on the end of a Laserdisc. It goes through all the channels with a voice and tones, so I figured it'd be useful to help make sure you have everything setup correctly (particularly for analog captures). If anyone has any other suggestions please let me know.

[little-endian]

Good approach and application wise easy to verify on the AVR/end-user's side, yes.

However, given a certain amount of paranoia, one should bear in mind that "DTS disguised as 16 bit PCM audio" usually comes in a 14-bit mapping, so only 14 out of 16 bit are actually used with the two most significant bits set to zero. Reason for the latter apparently was to prevent white noise to be played back at full scale, but instead at less harming ~ -12dBFS.

I don't clearly remember the concrete scenario, but I think to remember having had a case where the DTS was still okay, but still some bits being altered.

In order to make sure that really the entire bitstream is correct, a technically even better approach (admittedly definitely less sexy and a bit more geeky) is to create source data containing a test pattern or archive data.

For example, with my little test-CD with leading zeroes followed by a "ABCDEF" pattern (for offset compensation and synchronization) and a RAR header in text form, I instantly can see whether it is "bit perfect" or not right after recording by checking the data in any hex editor:





When cutting the "intro stuffing" away, I can also save the rest of the data beginning with the "Rar!"-header and check the archive against its embedded CRC32 in no time.

[bronan]

That's great, you should share it! Thinking about it more, I guess it should be possible to even write a little app to parse the data for you and check for the header..

[pipefan413]

Good approach and application wise easy to verify on the AVR/end-user's side, yes.

However, given a certain amount of paranoia, one should bear in mind that "DTS disguised as 16 bit PCM audio" usually comes in a 14-bit mapping, so only 14 out of 16 bit are actually used with the two most significant bits set to zero. Reason for the latter apparently was to prevent white noise to be played back at full scale, but instead at less harming ~ -12dBFS.

I don't clearly remember the concrete scenario, but I think to remember having had a case where the DTS was still okay, but still some bits being altered.

In order to make sure that really the entire bitstream is correct, a technically even better approach (admittedly definitely less sexy and a bit more geeky) is to create source data containing a test pattern or archive data.

For example, with my little test-CD with leading zeroes followed by a "ABCDEF" pattern (for offset compensation and synchronization) and a RAR header in text form, I instantly can see whether it is "bit perfect" or not right after recording by checking the data in any hex editor:





When cutting the "intro stuffing" away, I can also save the rest of the data beginning with the "Rar!"-header and check the archive against its embedded CRC32 in no time.

Having issues with the DTS Parser / dts2wav route so tried this approach (which I rather like). However, the file I tried to use is basically just a maxed out waveform so clips and because it clips, the data is changed. Yours looks like it isn't clipping when it's pretending to be audio. Was this just experimentation with different files to see which ones looked plausible as "audio" in a waveform?

I'm guessing process here is basically:

1. Take an archive (.rar, .zip, whatever) and import it into something like Audacity but telling Audacity that it's 16-bit signed PCM at 44.1 kHz (which just makes it construct a .wav header)
2. Export as .wav (I verified this was the same as the source file but with a header stuck on it)
3. Burn .wav to CD as audio (I haven't actually done this since the 90s I think so I used Windows Media Player which may be a mistake)
4. Record playback from LD player through TOSLINK and export back out and inspect

I suspect something is definitely wrong with my capture chain, probably the hardware or the drivers, but it's not even just that that's going wrong for me (stuff that has nothing to do with it, for instance, like dts2wav.exe refusing to work at all regardless of what I feed to it). Also, I tried ripping the burned audio CD again and then inspecting it to take the capture thing out of the equation but even that wasn't a bit perfect match to source (which could just be Windows Media Player being a dick, idk).

[bronan]

What kind of CD-Rs are you using? You should also try burning as slow as your burner will allow. You'd be surprised how easy it is for burned CDs to be incorrect..

[pipefan413]

What kind of CD-Rs are you using? You should also try burning as slow as your burner will allow. You'd be surprised how easy it is for burned CDs to be incorrect..

The CD-Rs are Verbatim ones, which I've been using for years and don't actually remember ever having a single dud. But it's possible, I'm sure. The thing is, I always verify against the image and I've burned it twice, both are supposedly bit perfect burns. I'm concerned that it might just be that I can't get bit perfect caps with this sound card. Which would suck because it cost me a fair bit and I'm skint.

I'm wondering if I should just bite the bullet and grab something like an ESI Maya44 EX (which I am guessing will probably do bit perfect and also has 4 analogue inputs, which is useful for something else I want to do) but I'm also trying to figure out a capture solution for video and I only have so many PCIe slots, hahah. I could import the ESI U24 XL but it'd be even more money because of location and it would only solve 1/2 problems (bit perfect capture but not 4 inputs) so that's probably not ideal; I guess the issue would be if I do buy the Maya44 EX and it turns out to NOT be bit-perfect.

EDIT: Just thought of something that could either be obvious or obviously stupid. This won't confirm that the LD player is bit-perfect (although it should really be) though I guess it rules out a problem with the CD burning and all that. But the Creative card has TOSLINK *output* as well as input. So... surely to test that it at least can capture bit-perfectly, I could just run digital audio out of the TOSLINK output and then record it coming back to the DBPro TOSLINK input, then compare the binary of the recorded file, right? I suppose if I can get to that point, then I know the audio hardware's configured properly, which means it is at least *capable* of bit-perfect capture. The problem then would be confirming that the LD player is. But... theoretically, it should be anyway, right?

I'm wondering if it's something to do with the CD burning thing, even though ImgBurn insists what's on the disc is identical to what's in the cue file. I guess I could try burning it with a different drive but that other one is a Blu-ray drive so might be even worse than a DVD one for a CD-R. But the thing is, if I burn the test audio (.cue) to disc, then *rip* it back off the disc, I can't decode *that* file with DTS Parser either. Even though it hasn't gone through any sort of resampling / sound card stuff at all. Buuuut... the rip may not be bit-perfect even if it's burned bit-perfect, I guess, so that doesn't *necessarily* mean it's the sound card.

I don't suppose you might be able to help me rule something out by linking / sending me the DTS in .wav form (as in, one that is already ready to run through DTS Parser)? I could then run it through DTS Parser immediately to check that works (in case DTS Parser is the issue somehow). If that works, I'll record it after sending out and back in (the sound card, without involving the LD player or CD-R). If *that* works, then I know it's either the disc burning bit, or the LD player itself, somehow. Make sense?

[captainsolo]

I’m having the same trouble. I used the u24 in reaper and it went fine but dts parser finds nothing. The wav itself is solid noise and appears as a single block waveform on audacity.

[pipefan413]

I’m having the same trouble. I used the u24 in reaper and it went fine but dts parser finds nothing. The wav itself is solid noise and appears as a single block waveform on audacity.

When I was having issues I wasn't using the U24 but with the U24 my issue disappeared; seems that some part of the signal isn't being recorded at the very start. So something must be going wrong with either your U24 settings or REAPER settings.

1. Make sure the sample rate is definitely set to 44100, the "mode" set to "professional", and the "copyright" set to "non-copyright" in the ESI settings. Otherwise it'll be altering it before it even gets to REAPER.

2. In REAPER, make sure you aren't saving it as WAVEX (make sure you pick "Force WAV"), and that you're outputting it to 16-bit rather than 24-bit. I personally don't force a sample rate in REAPER either because that might just obfuscate: you could have the ESI set to 44100, USB disconnects for some reason and reconnects which resets it to 48000 Hz, but because REAPER is set to force 44100 Hz you don't notice but the capture is no longer bit perfect, if you see what I mean.

It could equally just be the player, if the laser for some reason isn't picking up the PCM track correctly off the disc (alignment issue? IDK). Or, as @bronan mentioned, the actual disc hasn't burned 100% (maybe try different media?) - I tested that and ruled it out which was part of working out that my capture card literally cannot be bit perfect. I've since got 2 different solutions that both work and compared them against each other to find them identical, so the weak link in my chain is now the players themselves, which occasionally waver a bit (basically just read errors / dropouts from time to time that cause a tiny part of the signal to not quite be 100% bit identical between playback events). But I have 3 players so if one doesn't work I've got fallback options. Maybe test in another player if your settings are 100% right, if that's an option?

[little-endian]

I'm wondering if it's something to do with the CD burning thing[...]

That I consider to be highly unlikely. The data rather becomes corrupted due to dithering, level changes, resampling or other non-obivous alterations during the S/PDIF capturing.

I used the u24 in reaper

How about Audacity for recording instead (in order to prevent dithering, in 24-Bit PCM during capturing and saved as 16-Bit PCM, truncating the less significant 8 Bits per sample)?

and it went fine but dts parser finds nothing.

... and here "bsconvert" instead (part of ac3filter tools)?