Laserdisc PCM Capture Guide

[bronan]

The silence won't bother DTSParser as far as I'm aware. What OS are you using?

[pipefan413]

The silence won't bother DTSParser as far as I'm aware. What OS are you using?

Good to know! Windows 10 Pro x64.

Getting really frustrated at this point but can't think clearly enough to ascertain what the issue might be. I suspect it may well just be the sound card but I dunno how I'd verify that without buying a "known good" bit perfect device and comparing. Which is more money...

Trying to think if I could figure out a way of maybe using something like @little-endian's method, but when I tried doing it (with Bit Perfect Test.zip, no less, which I saved in modified form as "Bit Perfect Test Test" because I'm easily amused) the "audio" was just clipping from start to finish so obviously isn't going to be bit-perfect since it's clipping so not recording it all.

I replied in the other thread as well but for the sake of making clear in both threads what I'm now thinking:

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 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?

Another way (much more long-winded I expect) might be to try to find an existing bit-perfect rip for an LD I also own, then try to record the first bit of side 1, and compare the binary of those... just trying to reduce the number of unknowns to narrow down what the issue is here.

[schorman]

This is the first time I've tried recording using Reaper. My previous LD PCM rips were done using WaveStudio, it isn't as configurable and is meant to just do what the sound card tells it to do. I didn't see the same problem using WaveStudio but I've also not been able to pass your DTS CD test using that so wanted to try something more accurate.

I'm away from my computer just now, but when I get back I'll try recording from a laserdisc into Reaper to see if I can hear any kind of skipping or speedup, for some reason I didn't think of that earlier.

I'm using ASIO4ALL because Creative's ASIO driver sadly has a problem with this card at 44.1 kHz. I'll experiment with different protocols too. Any you recommend?

Thanks for the help.

I'm currently fighting with another Creative Sound Blaster card: the ZxR + DBPro. It would appear that it too is a bit iffy.

I initially tried it with the built in ASIO driver, which defaulted to 48 kHz, so I set Reaper to "request" 44.1 kHz" to see if it worked. It did, but it wasn't bit-perfect, so I figured there was resampling going on. So then I tried ASIO4ALL instead, which reported that the WDM driver could indeed capture anything from 32 to 96 kHz through the digital input on the DBPro, yet it still isn't bit-perfect even when the driver is ostensibly passing Reaper 44.1 kHz at 24-bit.

The thing that seems to be consistent through every test recording I've done though is that DTS Parser doesn't render anything. The output file is completely empty, 0 bytes.

Is there something really dumb I might be missing that could cause that? For instance, does it matter that there's silence at the start of the Reaper .wav file (i.e. after I hit record and before the player actually starts playing the CD)? Don't know if I should be deleting it in Reaper before putting it through DTS Parser or what.

I thought I had posted this before, but there's a tool that will replace the process of using dtsparser and then xvi32 to fix the frame headers.  It's called "Wav2dts".  It was developed by tebasuna over at doom9, and altered a bit by me to make it more usable with LaserDisc captures. 

It can basically be used as a drag and drop interface on windows.  Drag the Wav file you've recorded onto the .exe, and it will strip any padding from the beginning and end, convert to 16bit standard dts format, and correct all of the frame headers, in one step.



Here's the compiled version and source code:

https://mega.nz/#!DZUXTKRa!VJIvzhMSa4Fit...ecUZT4cOaU

Tried this in case the problem I described above was something to do with DTS Parser on my system, but I can't get the wav2dts.exe to run at all because it throws up an error saying it can't find "libgcc_s_dw2-1.dll":



Anybody have any ideas?

I guess I compiled it wrong. I'll have to try again.

[schorman]

Here is the newer compile. I don't know why, but the original flawed compile stayed on mega, even though I thought I had updated it.

https://mega.nz/file/LJ9n0DwL#P-VPSByrCw...5kV8guSbc0

[pipefan413]

Here is the newer compile.  I don't know why, but the original flawed compile stayed on mega, even though I thought I had updated it.

https://mega.nz/file/LJ9n0DwL#P-VPSByrCw...5kV8guSbc0

Thank you!

So from this I can confirm that DTS Parser is NOT working on my system for an unknown reason because this DOES work with one of the same files that crashed DTS Parser. For some reason.

Right, let's work this out then:

TEST 1: CD-R verification
I burned the test disc to CD-R, then ripped it back again to FLAC, converted that to .wav then used this newly compiled version of your custom dts2wav to convert it to .dts and it worked. So, that process is bit-perfect, and I know the disc is fine. (The same file refused to go through DTS Parser. Don't know why.) PASSED.

TEST 2: Creative ASIO driver
Same CD-R in LD player, recording through native ASIO driver at 44.1 kHz in Reaper, rendered as 16-bit .wav and run through dts2wav... and it didn't work. Reports "FileSize : 45944718 bytes" then hangs. FAILED.

TEST 3: ASIO4ALL driver
Same CD-R in LD player, recording through ASIO4ALL driver at 44.1 kHz in Reaper, rendered as 16-bit .wav and run through dts2wav. Again, hangs ("FileSize : 45924166 bytes"). FAILED.

So something definitely appears to be up with either the LD player, sound card, or I guess theoretically but extremely unlikely, the TOSLINK cable I'm using. Of those three, it seems most likely to be the sound card. Which would kinda suck because it cost me a fair bit of moolah.

It could theoretically also be that the disc is fine and I actually am getting bit-perfect capture in terms of what the LD player is sending over TOSLINK, but the LD player is not reading the burned disc accurately. So, maybe because it's a CD-R as opposed to a proper authored disc, it isn't reading it 100%. For some reason. That bit is harder to solve, but I guess as I mentioned I could try capturing a chunk of audio from an actual LaserDisc in my collection that I already have from somebody else's bit-perfect capture. I'm trying to figure out if I actually have any of my LDs as raw bit-perfect caps that haven't been synced, but can't think of any (obviously the files usually end up being synced so won't be entirely bit-perfect any more at that stage).

If there's anybody willing and able to help with this, I dunno the best way of doing this; maybe let me know and I'll have a look through what I believe you've got and what I believe I've got and see if there's anything we both have? If that's possible, then I can do a rip of the first minute or two or whatever (no point recording 2 hrs if it's not verified as working first) and you could potentially send me either side 1 or just the first few minutes for me to compare the binary contents of each file. One that people might have that occurs to me off top of head is 4102985... but I've got all sorts of mad nonsense, some NTSC, some PAL.

[schorman]

It's been years since I tried using a Creative Card to capture, but I remember that you used to have to find the check box to make sure it's syncing to the external spdif bitstream.

In the past, it seemed like Creative drivers always wanted to resample everything coming in, even on the digital inputs. Look for a Creative control panel to set it to sync to the external source. It's a very common problem.

[pipefan413]

It's been years since I tried using a Creative Card to capture, but I remember that you used to have to find the check box to make sure it's syncing to the external spdif bitstream.

In the past, it seemed like Creative drivers always wanted to resample everything coming in, even on the digital inputs. Look for a Creative control panel to set it to sync to the external source. It's a very common problem.

It doesn't appear such an option exists at all in the software for this card unfortunately.

There is a setting inside Audition when using MME rather than ASIO to select which lets me choose which master clock to use (defaulted to output but I changed to input SPDIF). Tried it but output still wouldn't parse as DTS.

[pipefan413]

I gave up on the sound card and just grabbed a USB interface instead. Lo and behold, I got @bronan's test kit to work (in *both* DTS Parser and @schorman's custom version of wav2dts), resulting in a decoded DTS file. So it would appear that I am finally in a position to do "bit-perfect" captures myself.

However, here's something that I've found that may or may not already be understood: over longer captures, the results are not always bit-perfect. So, capturing a whole film will result in some differences, most often at the very start or very end of the captured digital audio.

These inconsistencies between captures which range from extremely minor to somewhat significant, at least on a binary level (almost certainly not in an audible way). There were sometimes just a few samples at the very start and end which were either captured or missed altogether, as was the case with side 1 of RESERVOIR DOGS; other times, there would be individual bytes that were slightly different between captures of the same disc, as was the case for side 2 of both RESERVOIR DOGS and NEAR DARK. With NEAR DARK, there was a block of 2780 bytes that were 00 in my first cap of NEAR DARK side 1 but had data in the second cap, but conversely, there were 2956 bytes in cap 2 that weren't in cap 1. Even more noticeably, side 2 cap 3 of RESERVOIR DOGS contained an additional 17688 bytes of non-zero PCM audio data on the end of it compared to cap 1, but cap 1 had an extra 42 bytes at the start (side change). I find myself wondering if this was why @Chewtobacca ended up using a little bit of TAF's 48 kHz Bond capture even when a theoretically bit-perfect capture later appeared courtesy of @williarob and was used as the primary source. Perhaps there were some samples missed out of the audio at the end of side 1 / start of side 2 in the @williarob capture that were caught by TAF's cap, just as some of my own caps are more complete than others at the start or end of a side. (Incidentally, I'm disabling the auto-side-change feature of my player to do these so that I can keep the sides as separate files and compare them more easily; instead, I'm just playing side A and stopping, then playing side B and stopping, and repeating that for any further sides on additional discs.)

This inconsistency is obviously a tad frustrating but can be dealt with. To overcome it, I'm doing a minimum of 2 captures (more if there are differences between the first 2 that amount to more than a small patch at the start/end), with the hope being that 2/3 should hopefully be exact or very close matches such that I can combine the binary data to create a single perfect capture of each side and then use these to create resyncs to more modern video transfers. I'm guessing this might be why @schorman did 3 captures for the STAR WARS LD stuff, although I guess it could be that he had better luck and was just being thorough but all the files generally matched without any patching from previous/later captures of the same disc.

In NEAR DARK's case, incidentally, and in many others, it won't actually matter at all if there are a few frames missed from the start of the audio because the first audio heard is not from the film anyway, but rather from old LaserDisc-specific logos that don't appear in the newer video so won't make it into the resynced audio track at all.

Point being: I'm wondering how many "bit-perfect" captures have actually been bit-perfect in theory but not entirely in practice. That said, I highly doubt that it makes any real discernible difference, as has been discussed previously.

[zoidberg]

When you say inconsistencies at the beginning and end of sides are we talking about seconds' worth or literally the odd sample? If it's just a couple of samples I wouldn't sweat it. Generally capturing each side separately is best, occasionally a side 2 will start pretty abruptly and using auto side change sometimes clips the start of side 2 (and even the end of side 1 depending on where the end flag is encoded).

FWIW a LD player doesn't treat PCM and DTS any differently (although some players are aware a DTS disc is being played and a little symbol will light up on the display). So if you can success fully parse DTS from a capture your setup is bit-perfect

[pipefan413]

When you say inconsistencies at the beginning and end of sides are we talking about seconds' worth or literally the odd sample? If it's just a couple of samples I wouldn't sweat it. Generally capturing each side separately is best, occasionally a side 2 will start pretty abruptly and using auto side change sometimes clips the start of side 2 (and even the end of side 1 depending on where the end flag is encoded).

FWIW a LD player doesn't treat PCM and DTS any differently (although some players are aware a DTS disc is being played and a little symbol will light up on the display). So if you can success fully parse DTS from a capture your setup is bit-perfect

Oh, I'm not worried about it being a problem in any real sense; we're talking about milliseconds here, generally speaking, usually only samples (at one point the discrepancy was 8 bytes... this is stereo, so that's really 4 bytes, bit depth is 16 bits i.e. 2 bytes per sample, so 2 samples' worth). I think the largest discrepancy I've found thus far was 2956 bytes, so 2956 / 2 bytes / 2 channels = 739 samples, 739 / 44.1 = ~17 milliseconds (a bit less than half a video frame), and that was at the very end when the video had stopped, so is just "silence" in practice but not completely zero in digital terms. But... y'know, it's me, so I like to be picky about these things. I know it would irritate me if I didn't.

And yes, what you just said re. the side change is precisely it. I'd heard of players having issues with side changes occasionally and suspected that exactly that might happen if I left it on auto, so I'm instead just pressing the "side A" and "side B" buttons instead of "play", so I can record them one by one and try to ensure that it doesn't cut off any audio or indeed video at the side changes. Incidentally, I found that the NTSC Raiders of the Lost Ark had a moment of pure silence at a side change and I'm curious to cap my PAL copy to see if it does the same if I do this same method of capturing multiple times and aligning it.

I was able to do the DTS test eventually though unfortunately not with equipment I'd hoped to, but it's done now!