Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PCM Bit Perfect Tester
#1
Music 
I've been meaning to start on some tutorials for capturing and syncing laserdisc audio, but I figured this is a good place to start since this test is essential to a capture setup. 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 app is meant to help verify that your capture chain is setup correctly for "bit perfect" audio captures.

The app has 2 parts: a noise generator, and a bit tester. The random noise generator will generate a unique reference track (using every possible byte value for samples) of whatever length you choose to be burned to a CD-R. You then record that through your capture setup, and use the 2nd part of the app, the bit tester, to compare the two and see if they are the same. This new and improved version of the testing method was inspired by little-endian's post further down this page.

https://i.imgur.com/cVlUSZt.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 1.3
https://drive.google.com/file/d/1uketJqQ...sp=sharing

INSTALL
- .Net 4.6.1 Framework is required
https://www.microsoft.com/en-us/download...x?id=49982

CHANGE-LOG
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
Reply
#2
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.
Reply
Thanks given by:
#3
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:

[Image: spdif-wave.png]

[Image: spdif-hex.png]

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.
Reply
Thanks given by: bronan , pipefan413
#4
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..
Reply
Thanks given by:
#5
(2020-05-15, 06:53 PM)little-endian Wrote: 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:

[Image: spdif-wave.png]

[Image: spdif-hex.png]

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).
Reply
Thanks given by:
#6
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..
Reply
Thanks given by:
#7
(2020-09-14, 02:09 PM)bronan Wrote: 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?
Reply
Thanks given by:
#8
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.
Damn Fool Idealistic Crusader
Reply
Thanks given by:
#9
(2021-01-21, 10:08 PM)captainsolo Wrote: 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?
Reply
Thanks given by:
#10
(2020-09-14, 06:34 PM)pipefan413 Wrote: 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.

(2021-01-21, 10:08 PM)captainsolo Wrote: 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)?

(2021-01-21, 10:08 PM)captainsolo Wrote: and it went fine but dts parser finds nothing.

... and here "bsconvert" instead (part of ac3filter tools)?
Reply
Thanks given by:


Possibly Related Threads…
Thread Author Replies Views Last Post
  Bit-perfect LD-capture - What's necessary? Dr. Cooper 29 6,409 2020-09-12, 03:31 AM
Last Post: pipefan413
  Locations List of people willing to assist with bit-perfect LD audio capture jerryshadoe 36 19,584 2020-07-01, 04:26 AM
Last Post: BDgeek
  Bit perfect or bust? zoidberg 12 5,928 2017-01-24, 01:34 AM
Last Post: spoRv

Forum Jump:


Users browsing this thread: 1 Guest(s)